From mailnull@www1.ietf.org  Tue Jun  3 08:40:22 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00320
	for <lemonade-archive@odin.ietf.org>; Tue, 3 Jun 2003 08:40:22 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h53CdsI09841
	for lemonade-archive@odin.ietf.org; Tue, 3 Jun 2003 08:39:54 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53CdsB09838
	for <lemonade-web-archive@optimus.ietf.org>; Tue, 3 Jun 2003 08:39:54 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00207
	for <lemonade-web-archive@ietf.org>; Tue, 3 Jun 2003 08:39:51 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19NB3E-0004vO-00
	for lemonade-web-archive@ietf.org; Tue, 03 Jun 2003 08:38:04 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19NB3D-0004vK-00
	for lemonade-web-archive@ietf.org; Tue, 03 Jun 2003 08:38:03 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53CdCB09762;
	Tue, 3 Jun 2003 08:39:12 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53CcwB09740
	for <lemonade@optimus.ietf.org>; Tue, 3 Jun 2003 08:38:58 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00118
	for <lemonade@ietf.org>; Tue, 3 Jun 2003 08:38:55 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19NB2K-0004u6-00
	for lemonade@ietf.org; Tue, 03 Jun 2003 08:37:08 -0400
Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19NB2J-0004tq-00
	for lemonade@ietf.org; Tue, 03 Jun 2003 08:37:07 -0400
Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83])
	by ihemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h53CcMt17437
	for <lemonade@ietf.org>; Tue, 3 Jun 2003 07:38:23 -0500 (CDT)
Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19)
	id <L2XLPCZX>; Tue, 3 Jun 2003 07:38:22 -0500
Message-ID: <54E40201497DF142B06B27255953F79705951BC8@il0015exch007u.ih.lucent.com>
From: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
To: lemonade@ietf.org
Date: Tue, 3 Jun 2003 07:38:20 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [lemonade] Revisions to the Requirements document
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

I am working to update the lemonade requirements document.  As I started to review these requirements, I have a few high-level questions / suggestions I'd appreciate some feedback on.
- The current requirements document reflects the "unified messaging" theme. The latest charter has refocused on diverse endpoints, with an emphasis on mobile clients. Do we drop references to UM in the requirements as part of a refocus on something more akin to an Internet mail based MM1 interface alternative? 
- There are several work-efforts on re-injecting M-IMAP into the 3GPP2 MMS standards. Should we work to make an explicit effort to stick lemonade protocols in that space instead? I imagine an effort like the FAX WG where the IETF process is accelerated by the needs for liaison with an organization with a live heartbeat. 
- Do we need the existing level of "tutorial" in the document? I am tempted to mark large sections for deletion rather than update to sing with the newly focused charter.. 
Comments? 
Greg V.

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



From mailnull@www1.ietf.org  Wed Jun  4 12:16:09 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29426
	for <lemonade-archive@odin.ietf.org>; Wed, 4 Jun 2003 12:16:09 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h54GFhb31057
	for lemonade-archive@odin.ietf.org; Wed, 4 Jun 2003 12:15:43 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54GFhB31054
	for <lemonade-web-archive@optimus.ietf.org>; Wed, 4 Jun 2003 12:15:43 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29405
	for <lemonade-web-archive@ietf.org>; Wed, 4 Jun 2003 12:15:39 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Natb-000587-00
	for lemonade-web-archive@ietf.org; Wed, 04 Jun 2003 12:13:51 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Nata-000583-00
	for lemonade-web-archive@ietf.org; Wed, 04 Jun 2003 12:13:50 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54GFNB31032;
	Wed, 4 Jun 2003 12:15:23 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54GEtB30947
	for <lemonade@optimus.ietf.org>; Wed, 4 Jun 2003 12:14:55 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29376
	for <lemonade@ietf.org>; Wed, 4 Jun 2003 12:14:51 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Nasp-00057K-00
	for lemonade@ietf.org; Wed, 04 Jun 2003 12:13:03 -0400
Received: from oe-im1pub.managedmail.com ([206.46.164.52] helo=oe-im1.bizmailsrvcs.net)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Naso-00056R-00
	for lemonade@ietf.org; Wed, 04 Jun 2003 12:13:02 -0400
Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26])
          by oe-im1.bizmailsrvcs.net
          (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP
          id <20030604161422.HFBV2597.oe-im1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>;
          Wed, 4 Jun 2003 11:14:22 -0500
Received: from RoselinskyM ([206.35.147.89]) by oe-ismta1.bizmailsrvcs.net
          (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with SMTP
          id <20030604161418.KKJM6261.oe-ismta1.bizmailsrvcs.net@RoselinskyM>;
          Wed, 4 Jun 2003 11:14:18 -0500
From: "Milt Roselinsky" <milt.roselinsky@openwave.com>
To: "Vaudreuil, Greg M \(Greg\)" <gregv@lucent.com>, <lemonade@ietf.org>
Subject: RE: [lemonade] Revisions to the Requirements document
Date: Wed, 4 Jun 2003 09:14:18 -0700
Message-ID: <LKEFIMGGONBOPJOEOFLOMEMBFIAA.milt.roselinsky@openwave.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <54E40201497DF142B06B27255953F79705951BC8@il0015exch007u.ih.lucent.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Content-Transfer-Encoding: 7bit
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi Greg,

It was my understanding that the LEMONADE requirements document
would be updated as a result of discussions on Openwave's presentation
and I-D.  I'd be happy to help with that.

Comments below.

Best regards,
Milt

> -----Original Message-----
> From: lemonade-admin@ietf.org [mailto:lemonade-admin@ietf.org]On Behalf
> Of Vaudreuil, Greg M (Greg)
> Sent: Tuesday, June 03, 2003 5:38 AM
> To: lemonade@ietf.org
> Subject: [lemonade] Revisions to the Requirements document
> 
> 
> I am working to update the lemonade requirements document.  As I 
> started to review these requirements, I have a few high-level 
> questions / suggestions I'd appreciate some feedback on.
> - The current requirements document reflects the "unified 
> messaging" theme. The latest charter has refocused on diverse 
> endpoints, with an emphasis on mobile clients. Do we drop 
> references to UM in the requirements as part of a refocus on 
> something more akin to an Internet mail based MM1 interface alternative? 

I support breaking the requirements into more focused documents.

> - There are several work-efforts on re-injecting M-IMAP into the 
> 3GPP2 MMS standards. Should we work to make an explicit effort to 
> stick lemonade protocols in that space instead? I imagine an 
> effort like the FAX WG where the IETF process is accelerated by 
> the needs for liaison with an organization with a live heartbeat. 

I'm puzzled by this statement.  As discussed in San Francisco, the
M-IMAP effort in 3GPP2 has resulted in an approved MM1 specification.
While 3GPP2 tsgx-mms may move forward with future versions of that spec, 
the current round of drafting and review on M-IMAP is completed.

> - Do we need the existing level of "tutorial" in the document? I 
> am tempted to mark large sections for deletion rather than update 
> to sing with the newly focused charter.. 
> Comments? 
> Greg V.
> 
> _______________________________________________
> 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 mailnull@www1.ietf.org  Wed Jun  4 19:07:49 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16722
	for <lemonade-archive@odin.ietf.org>; Wed, 4 Jun 2003 19:07:49 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h54N7Rg29069
	for lemonade-archive@odin.ietf.org; Wed, 4 Jun 2003 19:07:27 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54N7QB29057
	for <lemonade-web-archive@optimus.ietf.org>; Wed, 4 Jun 2003 19:07:26 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16715
	for <lemonade-web-archive@ietf.org>; Wed, 4 Jun 2003 19:07:18 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19NhJy-00013q-00
	for lemonade-web-archive@ietf.org; Wed, 04 Jun 2003 19:05:30 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19NhJx-00013n-00
	for lemonade-web-archive@ietf.org; Wed, 04 Jun 2003 19:05:29 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54N79B28548;
	Wed, 4 Jun 2003 19:07:11 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54N6eB28199
	for <lemonade@optimus.ietf.org>; Wed, 4 Jun 2003 19:06:40 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16712
	for <lemonade@ietf.org>; Wed, 4 Jun 2003 19:06:31 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19NhJD-00013j-00
	for lemonade@ietf.org; Wed, 04 Jun 2003 19:04:43 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx with esmtp (Exim 4.12)
	id 19NhJC-00013g-00
	for lemonade@ietf.org; Wed, 04 Jun 2003 19:04:42 -0400
Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148])
	by ithilien.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h54N6R6I024633;
	Wed, 4 Jun 2003 16:06:28 -0700 (PDT)
Received: from [129.46.74.63] (loud.qualcomm.com [129.46.74.63])
	by magus.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h54N6Psh001785;
	Wed, 4 Jun 2003 16:06:26 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <a0600142abb0429d84dce@[129.46.74.63]>
In-Reply-To: 
 <54E40201497DF142B06B27255953F79705951BC8@il0015exch007u.ih.lucent.com
 >
References: 
 <54E40201497DF142B06B27255953F79705951BC8@il0015exch007u.ih.lucent.com
 >
X-Mailer: Eudora for Mac OS X v6.0a
Date: Wed, 4 Jun 2003 16:06:15 -0700
To: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>, lemonade@ietf.org
From: Randall Gellens <randy@qualcomm.com>
Subject: Re: [lemonade] Revisions to the Requirements document
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b25
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

At 7:38 AM -0500 6/3/03, Greg M (Greg) Vaudreuil wrote:

>  - The current requirements document reflects the "unified 
> messaging" theme. The latest charter has refocused on diverse 
> endpoints, with an emphasis on mobile clients. Do we drop 
> references to UM in the requirements as part of a refocus on 
> something more akin to an Internet mail based MM1 interface 
> alternative?

It makes sense to make the requirements document match the charter.

>  - There are several work-efforts on re-injecting M-IMAP into the 
> 3GPP2 MMS standards. Should we work to make an explicit effort to 
> stick lemonade protocols in that space instead? I imagine an effort 
> like the FAX WG where the IETF process is accelerated by the needs 
> for liaison with an organization with a live heartbeat.

3GPP2 recently approved M-IMAP as an MM1 protocol.  I see lemonade as 
being especially useful in defining future 
extensions/optimizations/etc for IMAP that would provide the 
bandwidth efficiency of M-IMAP but remain interoperable with IMAP. 
This would permit both IMAP and M-IMAP implementations to migrate to 
an interoperable new IMAP revision and gain new features (such as 
forward without download, streaming, etc.) as well as bandwidth 
gains.  In other words, I see lemonade as attempt to define the 
future (hopefully a short-term future).

>  - Do we need the existing level of "tutorial" in the document? I am 
> tempted to mark large sections for deletion rather than update to 
> sing with the newly focused charter..

I suspect we don't need tutorial material in the requirements document.


-- 
--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
All science is either physics or stamp collecting.
        --E. Rutherford
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Thu Jun  5 08:30:54 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20090
	for <lemonade-archive@odin.ietf.org>; Thu, 5 Jun 2003 08:30:54 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h55CUQh31098
	for lemonade-archive@odin.ietf.org; Thu, 5 Jun 2003 08:30:26 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55CUQB31095
	for <lemonade-web-archive@optimus.ietf.org>; Thu, 5 Jun 2003 08:30:26 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20012
	for <lemonade-web-archive@ietf.org>; Thu, 5 Jun 2003 08:30:24 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Ntr6-0005wi-00
	for lemonade-web-archive@ietf.org; Thu, 05 Jun 2003 08:28:32 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Ntr5-0005wL-00
	for lemonade-web-archive@ietf.org; Thu, 05 Jun 2003 08:28:31 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55CU6B30760;
	Thu, 5 Jun 2003 08:30:06 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55CSKB30453
	for <lemonade@optimus.ietf.org>; Thu, 5 Jun 2003 08:28:20 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19517
	for <lemonade@ietf.org>; Thu, 5 Jun 2003 08:28:07 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Ntot-0005qr-00
	for lemonade@ietf.org; Thu, 05 Jun 2003 08:26:15 -0400
Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Ntos-0005pn-00
	for lemonade@ietf.org; Thu, 05 Jun 2003 08:26:14 -0400
Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83])
	by ihemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h55CRPt26123
	for <lemonade@ietf.org>; Thu, 5 Jun 2003 07:27:25 -0500 (CDT)
Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19)
	id <L2XL4YXC>; Thu, 5 Jun 2003 07:27:25 -0500
Message-ID: <54E40201497DF142B06B27255953F79705A2CC61@il0015exch007u.ih.lucent.com>
From: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
To: Milt Roselinsky <milt.roselinsky@openwave.com>
Cc: lemonade@ietf.org
Subject: RE: [lemonade] Revisions to the Requirements document
Date: Thu, 5 Jun 2003 07:27:24 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

Great!  Can you send text and suggested changes?  i will edit into the document.

Greg V.

-----Original Message-----
From: Milt Roselinsky [mailto:milt.roselinsky@openwave.com]
Sent: Wednesday, June 04, 2003 11:14 AM
To: Vaudreuil, Greg M (Greg); lemonade@ietf.org
Subject: RE: [lemonade] Revisions to the Requirements document


Hi Greg,

It was my understanding that the LEMONADE requirements document
would be updated as a result of discussions on Openwave's presentation
and I-D.  I'd be happy to help with that.

Comments below.

Best regards,
Milt

> -----Original Message-----
> From: lemonade-admin@ietf.org [mailto:lemonade-admin@ietf.org]On Behalf
> Of Vaudreuil, Greg M (Greg)
> Sent: Tuesday, June 03, 2003 5:38 AM
> To: lemonade@ietf.org
> Subject: [lemonade] Revisions to the Requirements document
> 
> 
> I am working to update the lemonade requirements document.  As I 
> started to review these requirements, I have a few high-level 
> questions / suggestions I'd appreciate some feedback on.
> - The current requirements document reflects the "unified 
> messaging" theme. The latest charter has refocused on diverse 
> endpoints, with an emphasis on mobile clients. Do we drop 
> references to UM in the requirements as part of a refocus on 
> something more akin to an Internet mail based MM1 interface alternative? 

I support breaking the requirements into more focused documents.

> - There are several work-efforts on re-injecting M-IMAP into the 
> 3GPP2 MMS standards. Should we work to make an explicit effort to 
> stick lemonade protocols in that space instead? I imagine an 
> effort like the FAX WG where the IETF process is accelerated by 
> the needs for liaison with an organization with a live heartbeat. 

I'm puzzled by this statement.  As discussed in San Francisco, the
M-IMAP effort in 3GPP2 has resulted in an approved MM1 specification.
While 3GPP2 tsgx-mms may move forward with future versions of that spec, 
the current round of drafting and review on M-IMAP is completed.

> - Do we need the existing level of "tutorial" in the document? I 
> am tempted to mark large sections for deletion rather than update 
> to sing with the newly focused charter.. 
> Comments? 
> Greg V.
> 
> _______________________________________________
> 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 mailnull@www1.ietf.org  Thu Jun  5 13:06:49 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06670
	for <lemonade-archive@odin.ietf.org>; Thu, 5 Jun 2003 13:06:49 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h55H6OU22052
	for lemonade-archive@odin.ietf.org; Thu, 5 Jun 2003 13:06:24 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55H6NB22049
	for <lemonade-web-archive@optimus.ietf.org>; Thu, 5 Jun 2003 13:06:23 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06654
	for <lemonade-web-archive@ietf.org>; Thu, 5 Jun 2003 13:06:19 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19NyA8-0001As-00
	for lemonade-web-archive@ietf.org; Thu, 05 Jun 2003 13:04:28 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19NyA7-0001Ao-00
	for lemonade-web-archive@ietf.org; Thu, 05 Jun 2003 13:04:27 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55H6EB22031;
	Thu, 5 Jun 2003 13:06:14 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55H5JB21944
	for <lemonade@optimus.ietf.org>; Thu, 5 Jun 2003 13:05:19 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06565
	for <lemonade@ietf.org>; Thu, 5 Jun 2003 13:05:14 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Ny96-00019Y-00
	for lemonade@ietf.org; Thu, 05 Jun 2003 13:03:24 -0400
Received: from brmea-mail-2.sun.com ([192.18.98.43])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Ny95-00019U-00
	for lemonade@ietf.org; Thu, 05 Jun 2003 13:03:23 -0400
Received: from esunmail ([129.147.58.198])
	by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h55H5FYU029056
	for <lemonade@ietf.org>; Thu, 5 Jun 2003 11:05:15 -0600 (MDT)
Received: from xpa-fe1 ([129.147.58.198]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003))
 with ESMTP id <0HG00088NQ4NIG@edgemail1.Central.Sun.COM> for
 lemonade@ietf.org; Thu, 05 Jun 2003 11:05:12 -0600 (MDT)
Received: from sun.com ([192.18.127.234])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003))
 with ESMTPSA id <0HG0005GKQ4MI9@mail.sun.net> for lemonade@ietf.org; Thu,
 05 Jun 2003 11:05:11 -0600 (MDT)
Date: Thu, 05 Jun 2003 10:05:01 -0700
From: "Jonathan T. Hawkins" <Jonathan.Hawkins@Sun.COM>
Subject: OpenWave Presentation RE: [lemonade] Revisions to the Requirements
 documents
To: lemonade@ietf.org
Message-id: <3EDF783C.4174D8D3@sun.com>
Organization: Sun ONE - A Division of Sun Microsystems, Inc.
MIME-version: 1.0
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
Content-type: multipart/mixed; boundary="Boundary_(ID_7+N/cER1uW7CYotWX2WbJg)"
X-Accept-Language: rs1_e48b1af90ad, rs2_14901981695, rs3_e0801f426d
References: <20030605160005.16571.63149.Mailman@www1.ietf.org>
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This is a multi-part message in MIME format.

--Boundary_(ID_7+N/cER1uW7CYotWX2WbJg)
Content-type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7BIT



> Message: 1
> From: "Milt Roselinsky" <milt.roselinsky@openwave.com>
> To: "Vaudreuil, Greg M \(Greg\)" <gregv@lucent.com>, <lemonade@ietf.org>
> Subject: RE: [lemonade] Revisions to the Requirements document
> Date: Wed, 4 Jun 2003 09:14:18 -0700
>
> Hi Greg,
>
> It was my understanding that the LEMONADE requirements document
> would be updated as a result of discussions on Openwave's presentation
> and I-D.  I'd be happy to help with that.
>
> Comments below.
>
> Best regards,
> Milt
>

Is that presentation published somewhere?    I'm also happy to help in the effort.

Jonathan

--Boundary_(ID_7+N/cER1uW7CYotWX2WbJg)
Content-type: text/x-vcard; charset=us-ascii; name=jonathan.hawkins.vcf
Content-disposition: attachment; filename=jonathan.hawkins.vcf
Content-description: Card for Jonathan T. Hawkins
Content-Transfer-Encoding: 7BIT

begin:vcard 
n:Hawkins;Jonathan
tel;cell:408-718-0463
tel;work:408-276-4245
x-mozilla-html:FALSE
url:http://viking.red.iplanet.com/users/jhawk/publish/
org:Sun ONE NICP Communication Products;Software Deployment Engineering
version:2.1
email;internet:Jonathan.Hawkins@sun.com
title:Unified Communications Architect, Staff Engineer 
adr;quoted-printable:;;4150 Network Circle=0D=0ASCA15-201;Santa Clara;CA;95054;USA
fn:Jonathan Hawkins
end:vcard

--Boundary_(ID_7+N/cER1uW7CYotWX2WbJg)--
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Thu Jun  5 13:58:42 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08256
	for <lemonade-archive@odin.ietf.org>; Thu, 5 Jun 2003 13:58:42 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h55HwGG26334
	for lemonade-archive@odin.ietf.org; Thu, 5 Jun 2003 13:58:16 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55HwFB26331
	for <lemonade-web-archive@optimus.ietf.org>; Thu, 5 Jun 2003 13:58:15 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08244
	for <lemonade-web-archive@ietf.org>; Thu, 5 Jun 2003 13:58:12 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19NyyJ-0001YD-00
	for lemonade-web-archive@ietf.org; Thu, 05 Jun 2003 13:56:19 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19NyyI-0001Y9-00
	for lemonade-web-archive@ietf.org; Thu, 05 Jun 2003 13:56:18 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55Hw6B26312;
	Thu, 5 Jun 2003 13:58:06 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55HvCB26243
	for <lemonade@optimus.ietf.org>; Thu, 5 Jun 2003 13:57:12 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08206
	for <lemonade@ietf.org>; Thu, 5 Jun 2003 13:57:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19NyxI-0001Xt-00
	for lemonade@ietf.org; Thu, 05 Jun 2003 13:55:16 -0400
Received: from brmea-mail-2.sun.com ([192.18.98.43])
	by ietf-mx with esmtp (Exim 4.12)
	id 19NyxH-0001Xq-00
	for lemonade@ietf.org; Thu, 05 Jun 2003 13:55:15 -0400
Received: from esunmail ([129.147.58.120])
	by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h55Hv7YU004478
	for <lemonade@ietf.org>; Thu, 5 Jun 2003 11:57:07 -0600 (MDT)
Received: from xpa-fe2 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003))
 with ESMTP id <0HG0008IRSJ6IG@edgemail1.Central.Sun.COM> for
 lemonade@ietf.org; Thu, 05 Jun 2003 11:57:07 -0600 (MDT)
Received: from sun.com ([192.18.127.234])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003))
 with ESMTPSA id <0HG000E2FSJ5DP@mail.sun.net> for lemonade@ietf.org; Thu,
 05 Jun 2003 11:57:06 -0600 (MDT)
Date: Thu, 05 Jun 2003 10:56:56 -0700
From: "Jonathan T. Hawkins" <Jonathan.Hawkins@Sun.COM>
Subject: Subject: [lemonade] Revisions to the Requirements document
To: lemonade@ietf.org
Message-id: <3EDF8467.FCE26E39@sun.com>
Organization: Sun ONE - A Division of Sun Microsystems, Inc.
MIME-version: 1.0
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
Content-type: multipart/mixed; boundary="Boundary_(ID_K27h9b3KZszO6csEuFQrqw)"
X-Accept-Language: rs1_e48b1af90ad, rs2_14901981695, rs3_e0801f426d
References: <20030605160005.16571.63149.Mailman@www1.ietf.org>
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This is a multi-part message in MIME format.

--Boundary_(ID_K27h9b3KZszO6csEuFQrqw)
Content-type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7BIT

> > -----Original Message-----
> > From: lemonade-admin@ietf.org [mailto:lemonade-admin@ietf.org]On Behalf
> > Of Vaudreuil, Greg M (Greg)
> > Sent: Tuesday, June 03, 2003 5:38 AM
> > To: lemonade@ietf.org
> > Subject: [lemonade] Revisions to the Requirements document
> >
> >
> > I am working to update the lemonade requirements document.  As I
> > started to review these requirements, I have a few high-level
> > questions / suggestions I'd appreciate some feedback on.
> > - The current requirements document reflects the "unified
> > messaging" theme. The latest charter has refocused on diverse
> > endpoints, with an emphasis on mobile clients. Do we drop
> > references to UM in the requirements as part of a refocus on
> > something more akin to an Internet mail based MM1 interface alternative?
>
> I support breaking the requirements into more focused documents.
>

I'll second this.  The lemonade spec covers too many interfaces for a single
document.

Regarding UM, given that in the 3GPP Spec, UM is considered a part of an external
service this might be a good idea not to focus on it as part of the Lemonade spec.
Rather, we could opt. to include it in the appendix demonstrating the same
architecture example of its integration as an to the 3GPP spec.

--Boundary_(ID_K27h9b3KZszO6csEuFQrqw)
Content-type: text/x-vcard; charset=us-ascii; name=jonathan.hawkins.vcf
Content-disposition: attachment; filename=jonathan.hawkins.vcf
Content-description: Card for Jonathan T. Hawkins
Content-Transfer-Encoding: 7BIT

begin:vcard 
n:Hawkins;Jonathan
tel;cell:408-718-0463
tel;work:408-276-4245
x-mozilla-html:FALSE
url:http://viking.red.iplanet.com/users/jhawk/publish/
org:Sun ONE NICP Communication Products;Software Deployment Engineering
version:2.1
email;internet:Jonathan.Hawkins@sun.com
title:Unified Communications Architect, Staff Engineer 
adr;quoted-printable:;;4150 Network Circle=0D=0ASCA15-201;Santa Clara;CA;95054;USA
fn:Jonathan Hawkins
end:vcard

--Boundary_(ID_K27h9b3KZszO6csEuFQrqw)--
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Thu Jun  5 14:02:14 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08526
	for <lemonade-archive@odin.ietf.org>; Thu, 5 Jun 2003 14:02:14 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h55I1mM26571
	for lemonade-archive@odin.ietf.org; Thu, 5 Jun 2003 14:01:48 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55I1lB26568
	for <lemonade-web-archive@optimus.ietf.org>; Thu, 5 Jun 2003 14:01:47 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08515
	for <lemonade-web-archive@ietf.org>; Thu, 5 Jun 2003 14:01:43 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Nz1j-0001c4-00
	for lemonade-web-archive@ietf.org; Thu, 05 Jun 2003 13:59:51 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Nz1i-0001c1-00
	for lemonade-web-archive@ietf.org; Thu, 05 Jun 2003 13:59:50 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55I1hB26552;
	Thu, 5 Jun 2003 14:01:43 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55I0QB26460
	for <lemonade@optimus.ietf.org>; Thu, 5 Jun 2003 14:00:26 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08448
	for <lemonade@ietf.org>; Thu, 5 Jun 2003 14:00:22 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Nz0Q-0001b0-00
	for lemonade@ietf.org; Thu, 05 Jun 2003 13:58:30 -0400
Received: from brmea-mail-3.sun.com ([192.18.98.34])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Nz0P-0001ax-00
	for lemonade@ietf.org; Thu, 05 Jun 2003 13:58:29 -0400
Received: from esunmail ([129.147.58.120])
	by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h55I0Lep007695
	for <lemonade@ietf.org>; Thu, 5 Jun 2003 12:00:21 -0600 (MDT)
Received: from xpa-fe1 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003))
 with ESMTP id <0HG0008WYSMOIG@edgemail1.Central.Sun.COM> for
 lemonade@ietf.org; Thu, 05 Jun 2003 11:59:13 -0600 (MDT)
Received: from sun.com ([192.18.127.234])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003))
 with ESMTPSA id <0HG00057VSMMIR@mail.sun.net> for lemonade@ietf.org; Thu,
 05 Jun 2003 11:59:10 -0600 (MDT)
Date: Thu, 05 Jun 2003 10:59:00 -0700
From: "Jonathan T. Hawkins" <Jonathan.Hawkins@Sun.COM>
To: lemonade@ietf.org
Message-id: <3EDF84E4.317E4053@sun.com>
Organization: Sun ONE - A Division of Sun Microsystems, Inc.
MIME-version: 1.0
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
Content-type: multipart/mixed; boundary="Boundary_(ID_x70f4un1rA3Ns3akjNPoQg)"
X-Accept-Language: rs1_e48b1af90ad, rs2_14901981695, rs3_e0801f426d
References: <20030605160005.16571.63149.Mailman@www1.ietf.org>
Subject: [lemonade] Re: lemonade digest, Vol 1 #8 - 3 msgs
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This is a multi-part message in MIME format.

--Boundary_(ID_x70f4un1rA3Ns3akjNPoQg)
Content-type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7BIT

> Message: 3
> From: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
> To: Milt Roselinsky <milt.roselinsky@openwave.com>
> Cc: lemonade@ietf.org
> Subject: RE: [lemonade] Revisions to the Requirements document
> Date: Thu, 5 Jun 2003 07:27:24 -0500
>
> Great!  Can you send text and suggested changes?  i will edit into the document.
>
> Greg V.

Can we get a copy of the spec on the alias?

Cheers,

Jonathan

--Boundary_(ID_x70f4un1rA3Ns3akjNPoQg)
Content-type: text/x-vcard; charset=us-ascii; name=jonathan.hawkins.vcf
Content-disposition: attachment; filename=jonathan.hawkins.vcf
Content-description: Card for Jonathan T. Hawkins
Content-Transfer-Encoding: 7BIT

begin:vcard 
n:Hawkins;Jonathan
tel;cell:408-718-0463
tel;work:408-276-4245
x-mozilla-html:FALSE
url:http://viking.red.iplanet.com/users/jhawk/publish/
org:Sun ONE NICP Communication Products;Software Deployment Engineering
version:2.1
email;internet:Jonathan.Hawkins@sun.com
title:Unified Communications Architect, Staff Engineer 
adr;quoted-printable:;;4150 Network Circle=0D=0ASCA15-201;Santa Clara;CA;95054;USA
fn:Jonathan Hawkins
end:vcard

--Boundary_(ID_x70f4un1rA3Ns3akjNPoQg)--
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Thu Jun  5 22:14:38 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25482
	for <lemonade-archive@odin.ietf.org>; Thu, 5 Jun 2003 22:14:38 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h562ED932054
	for lemonade-archive@odin.ietf.org; Thu, 5 Jun 2003 22:14:13 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h562ECB32051
	for <lemonade-web-archive@optimus.ietf.org>; Thu, 5 Jun 2003 22:14:12 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25446
	for <lemonade-web-archive@ietf.org>; Thu, 5 Jun 2003 22:14:07 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19O6iF-0005Pc-00
	for lemonade-web-archive@ietf.org; Thu, 05 Jun 2003 22:12:15 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19O6iE-0005PZ-00
	for lemonade-web-archive@ietf.org; Thu, 05 Jun 2003 22:12:14 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h562E3B32037;
	Thu, 5 Jun 2003 22:14:03 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h562DUB31981
	for <lemonade@optimus.ietf.org>; Thu, 5 Jun 2003 22:13:30 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25427
	for <lemonade@ietf.org>; Thu, 5 Jun 2003 22:13:25 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19O6hZ-0005P7-00
	for lemonade@ietf.org; Thu, 05 Jun 2003 22:11:33 -0400
Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com)
	by ietf-mx with smtp (Exim 4.12)
	id 19O6hY-0005Os-00
	for lemonade@ietf.org; Thu, 05 Jun 2003 22:11:32 -0400
Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap 
	 id 10964; Thu, 05 Jun 2003 22:14:43 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Thu, 5 Jun 2003 22:12:55 -0400
Message-ID: <4A3384433CE2AB46A63468CB207E209D59E327@zoe.office.snowshore.com>
Thread-Topic: Life on the List, and Vienna
Thread-Index: AcMr0cPILv8vKoR1QVWDzmeCn9Heug==
From: "Eric Burger" <eburger@snowshore.com>
To: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h562DUB31982
Subject: [lemonade] Life on the List, and Vienna
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Now that things are moving again, do we want to meet in Vienna?

I would envision more of a working session than a presentation session.  E.g., sharpen your pencils, styli, and notebooks.

Please RSVP to me *directly* by Monday.  I would like to take a count to find out (1) if we have critical mass and (2) how small a room to book.

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



From mailnull@www1.ietf.org  Thu Jun  5 22:17:37 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25549
	for <lemonade-archive@odin.ietf.org>; Thu, 5 Jun 2003 22:17:36 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h562HBZ32199
	for lemonade-archive@odin.ietf.org; Thu, 5 Jun 2003 22:17:11 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h562HBB32196
	for <lemonade-web-archive@optimus.ietf.org>; Thu, 5 Jun 2003 22:17:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25536
	for <lemonade-web-archive@ietf.org>; Thu, 5 Jun 2003 22:17:06 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19O6l8-0005Qc-00
	for lemonade-web-archive@ietf.org; Thu, 05 Jun 2003 22:15:14 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19O6l7-0005QZ-00
	for lemonade-web-archive@ietf.org; Thu, 05 Jun 2003 22:15:13 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h562H1B32181;
	Thu, 5 Jun 2003 22:17:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h562GoB32161
	for <lemonade@optimus.ietf.org>; Thu, 5 Jun 2003 22:16:50 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25520
	for <lemonade@ietf.org>; Thu, 5 Jun 2003 22:16:44 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19O6kl-0005QN-00
	for lemonade@ietf.org; Thu, 05 Jun 2003 22:14:51 -0400
Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com)
	by ietf-mx with smtp (Exim 4.12)
	id 19O6kl-0005QF-00
	for lemonade@ietf.org; Thu, 05 Jun 2003 22:14:51 -0400
Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap 
	 id 10940; Thu, 05 Jun 2003 22:18:02 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Thu, 5 Jun 2003 22:16:14 -0400
Message-ID: <4A3384433CE2AB46A63468CB207E209D59E328@zoe.office.snowshore.com>
Thread-Topic: Supplementary Web Site
Thread-Index: AcMr0jpazijMIB7YTVmhehGPzz9hKg==
From: "Eric Burger" <eburger@snowshore.com>
To: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h562GoB32162
Subject: [lemonade] Supplementary Web Site
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Don't forget that we do have a supplementary web site that complements the official IETF charter site.

IETF charter site: 
<http://www.ietf.org/html.charters/lemonade-charter.html>

Supplemental lemonade web site:
<http://flyingfox.snowshore.com/i-d/lemonade/>

With the talk of "can you send that out" or "where can I find that paper", check to see if they are on the site.  If they are not, send me a request (or the document), and I'll post it.

Please do NOT post documents to the list.  Most spam filters, including the IETF's, will kill the document.  It's also a poor use of bandwidth.

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



From mailnull@www1.ietf.org  Sun Jun  8 18:04:55 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01643
	for <lemonade-archive@odin.ietf.org>; Sun, 8 Jun 2003 18:04:55 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h58M4VP27889
	for lemonade-archive@odin.ietf.org; Sun, 8 Jun 2003 18:04:31 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h58M4VB27886
	for <lemonade-web-archive@optimus.ietf.org>; Sun, 8 Jun 2003 18:04:31 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01594
	for <lemonade-web-archive@ietf.org>; Sun, 8 Jun 2003 18:04:25 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19P8F9-0005d9-00
	for lemonade-web-archive@ietf.org; Sun, 08 Jun 2003 18:02:27 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19P8F8-0005d5-00
	for lemonade-web-archive@ietf.org; Sun, 08 Jun 2003 18:02:26 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h58M4DB27878;
	Sun, 8 Jun 2003 18:04:13 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h58M3fB27856
	for <lemonade@optimus.ietf.org>; Sun, 8 Jun 2003 18:03:41 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01500
	for <lemonade@ietf.org>; Sun, 8 Jun 2003 18:03:35 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19P8EL-0005cg-00
	for lemonade@ietf.org; Sun, 08 Jun 2003 18:01:37 -0400
Received: from joy.songbird.com ([208.184.79.7])
	by ietf-mx with esmtp (Exim 4.12)
	id 19P8EK-0005cX-00
	for lemonade@ietf.org; Sun, 08 Jun 2003 18:01:36 -0400
Received: from bbprime (jay.songbird.com [208.184.79.253])
	by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h58M5xF07949;
	Sun, 8 Jun 2003 15:05:59 -0700
Date: Sun, 8 Jun 2003 15:02:57 -0700
From: Dave Crocker <dhc@dcrocker.net>
X-Mailer: The Bat! (v1.63 Beta/6) Personal
Reply-To: Dave Crocker <dcrocker@brandenburg.com>
Organization: Brandenburg InternetWorking
X-Priority: 3 (Normal)
Message-ID: <5012124474.20030608150257@brandenburg.com>
To: "Eric Burger" <eburger@snowshore.com>
CC: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: Re: [lemonade] Life on the List, and Vienna
In-Reply-To: <4A3384433CE2AB46A63468CB207E209D59E327@zoe.office.snowshore.com>
References: <4A3384433CE2AB46A63468CB207E209D59E327@zoe.office.snowshore.com>
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Eric,

EB> Now that things are moving again, do we want to meet in Vienna?

EB> I would envision more of a working session than a presentation
EB> session.  E.g., sharpen your pencils, styli, and notebooks.

The question is what we will discuss.  So we should simply offer items
to discuss (and, yes, discuss, not present.)

I'll be in Vienna.  Don't have items to suggest at the moment.



d/
--
 Dave Crocker <mailto:dcrocker@brandenburg.com>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

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



From mailnull@www1.ietf.org  Sun Jun  8 21:11:43 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05568
	for <lemonade-archive@odin.ietf.org>; Sun, 8 Jun 2003 21:11:43 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h591BHT06600
	for lemonade-archive@odin.ietf.org; Sun, 8 Jun 2003 21:11:17 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h591BHB06597
	for <lemonade-web-archive@optimus.ietf.org>; Sun, 8 Jun 2003 21:11:17 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05565
	for <lemonade-web-archive@ietf.org>; Sun, 8 Jun 2003 21:11:13 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PB9u-0006WD-00
	for lemonade-web-archive@ietf.org; Sun, 08 Jun 2003 21:09:14 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PB9t-0006WA-00
	for lemonade-web-archive@ietf.org; Sun, 08 Jun 2003 21:09:13 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h591B4B06583;
	Sun, 8 Jun 2003 21:11:04 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h591AiB06567
	for <lemonade@optimus.ietf.org>; Sun, 8 Jun 2003 21:10:44 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05487
	for <lemonade@ietf.org>; Sun, 8 Jun 2003 21:10:40 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PB9N-0006UW-00
	for lemonade@ietf.org; Sun, 08 Jun 2003 21:08:41 -0400
Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PB9M-0006So-00
	for lemonade@ietf.org; Sun, 08 Jun 2003 21:08:40 -0400
Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83])
	by ihemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h591A7P19411
	for <lemonade@ietf.org>; Sun, 8 Jun 2003 20:10:07 -0500 (CDT)
Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19)
	id <L2XL6H2G>; Sun, 8 Jun 2003 20:10:06 -0500
Message-ID: <54E40201497DF142B06B27255953F79705B060F3@il0015exch007u.ih.lucent.com>
From: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
To: Dave Crocker <dcrocker@brandenburg.com>,
        Eric Burger
	 <eburger@snowshore.com>
Cc: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: RE: [lemonade] Life on the List, and Vienna
Date: Sun, 8 Jun 2003 20:10:06 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>


I (with Greg White) plan to have a revised future delivery submission draft, reflecting the agreed upon changes at the last IETF...  No IMAP outbox, keep within SMTP-submit framework, other edits.

Are there other comments before we post a new version?

Greg V.

-----Original Message-----
From: Dave Crocker [mailto:dhc@dcrocker.net]
Sent: Sunday, June 08, 2003 5:03 PM
To: Eric Burger
Cc: IETF LEMONADE (E-mail)
Subject: Re: [lemonade] Life on the List, and Vienna


Eric,

EB> Now that things are moving again, do we want to meet in Vienna?

EB> I would envision more of a working session than a presentation
EB> session.  E.g., sharpen your pencils, styli, and notebooks.

The question is what we will discuss.  So we should simply offer items
to discuss (and, yes, discuss, not present.)

I'll be in Vienna.  Don't have items to suggest at the moment.



d/
--
 Dave Crocker <mailto:dcrocker@brandenburg.com>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

_______________________________________________
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 mailnull@www1.ietf.org  Sun Jun  8 21:45:37 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06136
	for <lemonade-archive@odin.ietf.org>; Sun, 8 Jun 2003 21:45:36 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h591jBo08503
	for lemonade-archive@odin.ietf.org; Sun, 8 Jun 2003 21:45:11 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h591jBB08500
	for <lemonade-web-archive@optimus.ietf.org>; Sun, 8 Jun 2003 21:45:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06132
	for <lemonade-web-archive@ietf.org>; Sun, 8 Jun 2003 21:45:06 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PBgh-0006gJ-00
	for lemonade-web-archive@ietf.org; Sun, 08 Jun 2003 21:43:07 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PBgh-0006gG-00
	for lemonade-web-archive@ietf.org; Sun, 08 Jun 2003 21:43:07 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h591j2B08490;
	Sun, 8 Jun 2003 21:45:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h591iWB08462
	for <lemonade@optimus.ietf.org>; Sun, 8 Jun 2003 21:44:32 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06126
	for <lemonade@ietf.org>; Sun, 8 Jun 2003 21:44:27 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PBg4-0006g4-00
	for lemonade@ietf.org; Sun, 08 Jun 2003 21:42:28 -0400
Received: from panda.com
	([206.124.149.114] helo=Ikkoku-Kan.Panda.COM ident=rid)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PBg3-0006fy-00
	for lemonade@ietf.org; Sun, 08 Jun 2003 21:42:27 -0400
Received: from localhost (mrc@localhost) by Ikkoku-Kan.Panda.COM id SAA16006; Sun, 8 Jun 2003 18:44:05 -0700 (PDT)
Date: Sun, 8 Jun 2003 18:44:04 -0700 (PDT)
From: Mark Crispin <mrc@CAC.Washington.EDU>
To: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
cc: Dave Crocker <dcrocker@brandenburg.com>,
        Eric Burger <eburger@snowshore.com>,
        "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: RE: [lemonade] Life on the List, and Vienna
In-Reply-To: <54E40201497DF142B06B27255953F79705B060F3@il0015exch007u.ih.lucent.com>
Message-ID: <Pine.NXT.4.56.0306081829010.11845@Ikkoku-Kan.Panda.COM>
References: <54E40201497DF142B06B27255953F79705B060F3@il0015exch007u.ih.lucent.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Sun, 8 Jun 2003, Vaudreuil, Greg M (Greg) wrote:
> I (with Greg White) plan to have a revised future delivery submission
> draft, reflecting the agreed upon changes at the last IETF...  No IMAP
> outbox, keep within SMTP-submit framework, other edits.

I think that a successful IMAP-aware delivery-submission mechanism will
have the following characteristics:

1) Keep IMAP and POP out of the MTA and MSA business.

2) Allow the submitted message to reference data available upon multiple
   IMAP or POP servers.

3) Not depend upon having unlimited access to the user's IMAP or POP data.

The people who argued at the last IETF for an IMAP outbox focused on
action item (3) -- which I agree is important -- but chose to disregard
(1) (in spite of this principle appearing in both the IMAP and POP RFCs)
and completely failed to consider (2).

It is very tempting to "just have an outbox in IMAP" that, being the IMAP
server, can grab all the needed data as local disk access.  However,
besides being a red flag for IMAP implementors, it ignores existing server
facilities in which the user's data isn't on a single IMAP server.

I recommend a mechanism which I brought up briefly (albeit was shouted
down due to a misunderstanding of what I was going to say) at the last
IETF:
	We need a mechanism (ala IMAP URL) which, when presented
	to an IMAP server, would deliver a particular data item
	from a particular mailbox owned by a particular user
	*without* providing access to any other data in the
	mailbox.

This mechanism would be used by the submission server (which some of us
want to be a different machine from the IMAP servers!) to obtain the data
from the IMAP server.

A possible mechanism is via SASL.  Details of how such a mechanism would
work, what security mechanisms it would have, etc. to be filled in (e.g.
by experts such as Chris Newman, who may already be working on this).

The amount of effort to do this is no more than the effort to do an outbox
in IMAP; and I suspect that it would be substantially less.

-- 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 mailnull@www1.ietf.org  Mon Jun  9 03:54:51 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23645
	for <lemonade-archive@odin.ietf.org>; Mon, 9 Jun 2003 03:54:51 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h597sOb09809
	for lemonade-archive@odin.ietf.org; Mon, 9 Jun 2003 03:54:24 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h597sNB09804
	for <lemonade-web-archive@optimus.ietf.org>; Mon, 9 Jun 2003 03:54:24 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23619
	for <lemonade-web-archive@ietf.org>; Mon, 9 Jun 2003 03:54:21 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PHS1-0000Xs-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 03:52:21 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PHS1-0000Xm-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 03:52:21 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h597s4B09792;
	Mon, 9 Jun 2003 03:54:04 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h597rrB09770
	for <lemonade@optimus.ietf.org>; Mon, 9 Jun 2003 03:53:53 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23610
	for <lemonade@ietf.org>; Mon, 9 Jun 2003 03:53:50 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PHRX-0000Xb-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 03:51:51 -0400
Received: from comversegw.icomverse.com ([192.118.48.248] helo=il-tlv-smtpout1.icomverse.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PHRW-0000XX-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 03:51:50 -0400
Received: from il-tlv-mbdg1.comverse.com (localhost.localdomain [127.0.0.1])
	by il-tlv-smtpout1.icomverse.com (8.11.6/8.11.6) with ESMTP id h597reI21867;
	Mon, 9 Jun 2003 10:53:40 +0300
Received: by il-tlv-mbdg1.comverse.com with Internet Mail Service (5.5.2655.55)
	id <M2S52XST>; Mon, 9 Jun 2003 10:53:46 +0300
Message-ID: <7D4344E32B34D511A6500002A560C60204D892CF@il-tlv-mail4.comverse.com>
From: Erev Ari <Ari.Erev@comverse.com>
To: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Cc: "'Dave Crocker'" <dcrocker@brandenburg.com>,
        Eric Burger
	 <eburger@snowshore.com>,
        "'Vaudreuil, Greg M (Greg)'" <gregv@lucent.com>
Subject: RE: [lemonade] Life on the List, and Vienna
Date: Mon, 9 Jun 2003 10:53:45 +0300 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C32E5C.4084F992"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C32E5C.4084F992
Content-Type: text/plain;
	charset="iso-8859-1"


This is also an answer to Greg's question regarding the Requirment document.

> -----Original Message-----
> From: Dave Crocker [mailto:dhc@dcrocker.net]
> Sent: Monday, June 09, 2003 1:03 AM
> To: Eric Burger
> Cc: IETF LEMONADE (E-mail)
> Subject: Re: [lemonade] Life on the List, and Vienna
> 
> 
> Eric,
> 
> EB> Now that things are moving again, do we want to meet in Vienna?
> 
> EB> I would envision more of a working session than a presentation
> EB> session.  E.g., sharpen your pencils, styli, and notebooks.
> 
> The question is what we will discuss.  So we should simply offer items
> to discuss (and, yes, discuss, not present.)
> 

I suggest to continue discussing issues and ifrastructure for better support
of mailboxes containing messages with different "message-contexts".
Some work-in-progress that addresses these issue is:
- IMAP Quota revision
   http://www.ietf.org/internet-drafts/draft-cridland-imap-quota-00.txt
- SMTP MediaSize
  http://www.ietf.org/internet-drafts/draft-shveidel-mediasize-02.txt
- IMAP Status-Counters
  (now deleted from the repository, last published as:
 
http://www.ietf.org/internet-drafts/draft-neystadt-imap-status-counters-02.t
xt

I think that this still falls in the area of the "refocused charter".

I plan to be in Vienna.

Ari

------_=_NextPart_001_01C32E5C.4084F992
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: [lemonade] Life on the List, and Vienna</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>This is also an answer to Greg's question regarding =
the Requirment document.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Dave Crocker [<A =
HREF=3D"mailto:dhc@dcrocker.net">mailto:dhc@dcrocker.net</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Monday, June 09, 2003 1:03 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Eric Burger</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: IETF LEMONADE (E-mail)</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [lemonade] Life on the List, and =
Vienna</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Eric,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; EB&gt; Now that things are moving again, do we =
want to meet in Vienna?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; EB&gt; I would envision more of a working =
session than a presentation</FONT>
<BR><FONT SIZE=3D2>&gt; EB&gt; session.&nbsp; E.g., sharpen your =
pencils, styli, and notebooks.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The question is what we will discuss.&nbsp; So =
we should simply offer items</FONT>
<BR><FONT SIZE=3D2>&gt; to discuss (and, yes, discuss, not =
present.)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>I suggest to continue discussing issues and =
ifrastructure for better support of mailboxes containing messages with =
different &quot;message-contexts&quot;.</FONT></P>

<P><FONT SIZE=3D2>Some work-in-progress that addresses these issue =
is:</FONT>
<BR><FONT SIZE=3D2>- IMAP Quota revision</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; <A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-cridland-imap-quota-00=
.txt" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-cridland-ima=
p-quota-00.txt</A></FONT>
<BR><FONT SIZE=3D2>- SMTP MediaSize</FONT>
<BR><FONT SIZE=3D2>&nbsp; <A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-shveidel-mediasize-02.=
txt" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-shveidel-med=
iasize-02.txt</A></FONT>
<BR><FONT SIZE=3D2>- IMAP Status-Counters</FONT>
<BR><FONT SIZE=3D2>&nbsp; (now deleted from the repository, last =
published as:</FONT>
<BR><FONT SIZE=3D2>&nbsp; <A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-neystadt-imap-status-c=
ounters-02.txt" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-neystadt-ima=
p-status-counters-02.txt</A></FONT>
</P>

<P><FONT SIZE=3D2>I think that this still falls in the area of the =
&quot;refocused charter&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>I plan to be in Vienna.</FONT>
</P>

<P><FONT SIZE=3D2>Ari</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C32E5C.4084F992--
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Mon Jun  9 13:23:34 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13290
	for <lemonade-archive@odin.ietf.org>; Mon, 9 Jun 2003 13:23:34 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h59HNAS19355
	for lemonade-archive@odin.ietf.org; Mon, 9 Jun 2003 13:23:10 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59HN9B19351
	for <lemonade-web-archive@optimus.ietf.org>; Mon, 9 Jun 2003 13:23:09 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13259
	for <lemonade-web-archive@ietf.org>; Mon, 9 Jun 2003 13:23:04 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PQKP-0005RD-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 13:21:05 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PQKO-0005RA-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 13:21:04 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59HN5B19337;
	Mon, 9 Jun 2003 13:23:05 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59HMbB19299
	for <lemonade@optimus.ietf.org>; Mon, 9 Jun 2003 13:22:37 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13241
	for <lemonade@ietf.org>; Mon, 9 Jun 2003 13:22:31 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PQJs-0005Qi-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 13:20:32 -0400
Received: from oe-im1pub.managedmail.com ([206.46.164.52] helo=oe-im1.bizmailsrvcs.net)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PQJr-0005QK-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 13:20:31 -0400
Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26])
          by oe-im1.bizmailsrvcs.net
          (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP
          id <20030609172203.GHHW2597.oe-im1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>;
          Mon, 9 Jun 2003 12:22:03 -0500
Received: from AKSTEBBENS.mshome.net ([64.14.194.172])
          by oe-ismta1.bizmailsrvcs.net
          (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP
          id <20030609172202.HGNZ6261.oe-ismta1.bizmailsrvcs.net@AKSTEBBENS.mshome.net>;
          Mon, 9 Jun 2003 12:22:02 -0500
Date: Mon, 9 Jun 2003 10:22:02 -0700
From: "Alan K. Stebbens" <alan.stebbens@openwave.com>
X-Mailer: The Bat! (v1.62r) Personal
Reply-To: "Alan K. Stebbens" <alan.stebbens@openwave.com>
Organization: Openwave Systems, Inc.
X-Priority: 3 (Normal)
Message-ID: <1386772811.20030609102202@openwave.com>
To: "Jonathan T. Hawkins" <Jonathan.Hawkins@sun.com>
CC: lemonade@ietf.org
Subject: Re: OpenWave Presentation RE: [lemonade] Revisions to the Requirements documents
In-Reply-To: <3EDF783C.4174D8D3@sun.com>
References: <20030605160005.16571.63149.Mailman@www1.ietf.org>
 <3EDF783C.4174D8D3@sun.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hello Jonathan,

The most recent version, with updates as suggested by the RFC Editor, is
available in the directory:

  A New Internet-Draft is available from the on-line Internet-Drafts directories.


          Title           : A Survey of Mobile Messaging Architectures and
                            Requirements
          Author(s)       : A. Stebbens, M. Roselinsky
          Filename        : draft-stebrose-lemonade-mmsarch-01.txt
          Pages           : 16
          Date            : 2003-6-4

  This document presents a taxonomy of messaging architecture
  components and models, providing a comparison of their feature sets.
  It also identifies the commonalities of these mobile messaging
  solutions and abstracts from these a set of mobile messaging
  requirements.  The information is provided to inform and encourage
  future discussion of and improvements to Internet messaging in order
  to increase their applicability to mobile messaging systems.

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

I plan to be in Vienna, also.

--
Best regards,
Alan K. Stebbens

Thursday, June 5, 2003, 10:05:01 AM, you wrote, in part:



>> Message: 1
>> From: "Milt Roselinsky" <milt.roselinsky@openwave.com>
>> To: "Vaudreuil, Greg M \(Greg\)" <gregv@lucent.com>, <lemonade@ietf.org>
>> Subject: RE: [lemonade] Revisions to the Requirements document
>> Date: Wed, 4 Jun 2003 09:14:18 -0700
>>
>> Hi Greg,
>>
>> It was my understanding that the LEMONADE requirements document
>> would be updated as a result of discussions on Openwave's presentation
>> and I-D.  I'd be happy to help with that.
>>
>> Comments below.
>>
>> Best regards,
>> Milt
>>

JTH> Is that presentation published somewhere?    I'm also happy to help in the effort.

JTH> Jonathan


-- 
Best regards,
 Alan K. Stebbens <alan.stebbens@openwave.com>
 Principal Product Technologist, Messaging
 Openwave Systems, Inc.
 Cell: +1.805.886.8886  Voice/Fax: +1.866.579.0801
 Desk: +1.805.884.3162
 YIM/MSN: alan_stebbens  ICQ: 51361674  AIM: akstebbens   

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



From mailnull@www1.ietf.org  Mon Jun  9 13:30:37 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13532
	for <lemonade-archive@odin.ietf.org>; Mon, 9 Jun 2003 13:30:37 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h59HUD519800
	for lemonade-archive@odin.ietf.org; Mon, 9 Jun 2003 13:30:13 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59HUCB19797
	for <lemonade-web-archive@optimus.ietf.org>; Mon, 9 Jun 2003 13:30:12 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13524
	for <lemonade-web-archive@ietf.org>; Mon, 9 Jun 2003 13:30:06 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PQRE-0005Ul-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 13:28:08 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PQRD-0005Ui-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 13:28:07 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59HU2B19787;
	Mon, 9 Jun 2003 13:30:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59HTMB19741
	for <lemonade@optimus.ietf.org>; Mon, 9 Jun 2003 13:29:22 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13503
	for <lemonade@ietf.org>; Mon, 9 Jun 2003 13:29:16 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PQQP-0005UU-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 13:27:17 -0400
Received: from brmea-mail-3.sun.com ([192.18.98.34])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PQQP-0005UR-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 13:27:17 -0400
Received: from esunmail ([129.147.58.120])
	by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h59HTIep025365
	for <lemonade@ietf.org>; Mon, 9 Jun 2003 11:29:18 -0600 (MDT)
Received: from xpa-fe1 ([129.147.58.198]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003))
 with ESMTP id <0HG800GTJ5WTAM@edgemail1.Central.Sun.COM> for
 lemonade@ietf.org; Mon, 09 Jun 2003 11:29:18 -0600 (MDT)
Received: from sun.com ([192.18.127.234])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003))
 with ESMTPSA id <0HG8003DJ5WSDM@mail.sun.net> for lemonade@ietf.org; Mon,
 09 Jun 2003 11:29:17 -0600 (MDT)
Date: Mon, 09 Jun 2003 10:29:16 -0700
From: "Jonathan T. Hawkins" <Jonathan.Hawkins@Sun.COM>
Subject: RE: [lemonade] Life on the List, and Vienna
To: mrc@CAC.Washington.EDU
Cc: lemonade@ietf.org
Message-id: <3EE4C3EB.A8A32ABE@sun.com>
Organization: Sun ONE - A Division of Sun Microsystems, Inc.
MIME-version: 1.0
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
Content-type: multipart/mixed; boundary="Boundary_(ID_cBbdWhgm/uLLJ4ZIW/kuFw)"
X-Accept-Language: rs1_e48b1af90ad, rs2_14901981695, rs3_e0801f426d
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This is a multi-part message in MIME format.

--Boundary_(ID_cBbdWhgm/uLLJ4ZIW/kuFw)
Content-type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7BIT


Hi Mark,

I work with Chris Newman.  He is extremely busy working on our next
release. I'll ping him for a response.

I agree with your points. SMTP delivery to an INBOX would be more
reasonable in that it provides a distributed architecture in a "store
and forward" design.  Also, MTAs are typically located closer to
end-users, where as the Mail Stores are locked up in a central data
center.  Most end-users shouldn't that the message isn't immediately in
their OUTBOX. A few second (at most) propagation delay should suffice.

Also.. I almost violently agree with the idea of an IMAP data delivery
enhancements.  Today's existing IMAP could be better enhanced for large
media objects over bandwidth constrained networks.  On a mobile mail
user agent device, it is absolutely painful to pull down media content
over the air, repackage, and then resubmit back over the air.  If I
could just forward the message, it would be a much better user
experience.

At the moment, I'm not quite sure which is more desirable: IMAP delivery
(many folks against it) or IMAP URL ACLs (complicated).  The URL
ACL-based IMAP access presents some complications in access managment
for a site.  The ACL aging policy might be something worth looking at.

Another option would be to extend SMTP to reference an IMAP URL?  In
this manner, the server-side Authenticated SMTP session could provide
the SASL mechanism to retrieve the IMAP data.

Jonathan

Date: Sun, 8 Jun 2003 18:44:04 -0700 (PDT)
From: Mark Crispin <mrc@CAC.Washington.EDU>
To: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
cc: Dave Crocker <dcrocker@brandenburg.com>,
   Eric Burger <eburger@snowshore.com>,
   "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: RE: [lemonade] Life on the List, and Vienna

On Sun, 8 Jun 2003, Vaudreuil, Greg M (Greg) wrote:
> I (with Greg White) plan to have a revised future delivery submission
> draft, reflecting the agreed upon changes at the last IETF...  No IMAP

> outbox, keep within SMTP-submit framework, other edits.

I think that a successful IMAP-aware delivery-submission mechanism will
have the following characteristics:

1) Keep IMAP and POP out of the MTA and MSA business.

2) Allow the submitted message to reference data available upon multiple

   IMAP or POP servers.

3) Not depend upon having unlimited access to the user's IMAP or POP
data.

The people who argued at the last IETF for an IMAP outbox focused on
action item (3) -- which I agree is important -- but chose to disregard
(1) (in spite of this principle appearing in both the IMAP and POP RFCs)

and completely failed to consider (2).

It is very tempting to "just have an outbox in IMAP" that, being the
IMAP
server, can grab all the needed data as local disk access.  However,
besides being a red flag for IMAP implementors, it ignores existing
server
facilities in which the user's data isn't on a single IMAP server.

I recommend a mechanism which I brought up briefly (albeit was shouted
down due to a misunderstanding of what I was going to say) at the last
IETF:
        We need a mechanism (ala IMAP URL) which, when presented
        to an IMAP server, would deliver a particular data item
        from a particular mailbox owned by a particular user
        *without* providing access to any other data in the
        mailbox.

This mechanism would be used by the submission server (which some of us
want to be a different machine from the IMAP servers!) to obtain the
data from the IMAP server.

A possible mechanism is via SASL.  Details of how such a mechanism would
work, what security mechanisms it would have, etc. to be filled in (e.g.
by experts such as Chris Newman, who may already be working on this).

The amount of effort to do this is no more than the effort to do an
outbox
in IMAP; and I suspect that it would be substantially less.

-- Mark --

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

--Boundary_(ID_cBbdWhgm/uLLJ4ZIW/kuFw)
Content-type: text/x-vcard; charset=us-ascii; name=jonathan.hawkins.vcf
Content-disposition: attachment; filename=jonathan.hawkins.vcf
Content-description: Card for Jonathan T. Hawkins
Content-Transfer-Encoding: 7BIT

begin:vcard 
n:Hawkins;Jonathan
tel;cell:408-718-0463
tel;work:408-276-4245
x-mozilla-html:FALSE
url:http://viking.red.iplanet.com/users/jhawk/publish/
org:Sun ONE NICP Communication Products;Software Deployment Engineering
version:2.1
email;internet:Jonathan.Hawkins@sun.com
title:Unified Communications Architect, Staff Engineer 
adr;quoted-printable:;;4150 Network Circle=0D=0ASCA15-201;Santa Clara;CA;95054;USA
fn:Jonathan Hawkins
end:vcard

--Boundary_(ID_cBbdWhgm/uLLJ4ZIW/kuFw)--
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Mon Jun  9 14:03:39 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14615
	for <lemonade-archive@odin.ietf.org>; Mon, 9 Jun 2003 14:03:39 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h59I3DM22343
	for lemonade-archive@odin.ietf.org; Mon, 9 Jun 2003 14:03:13 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59I3DB22340
	for <lemonade-web-archive@optimus.ietf.org>; Mon, 9 Jun 2003 14:03:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14599
	for <lemonade-web-archive@ietf.org>; Mon, 9 Jun 2003 14:03:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PQxA-0005ow-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 14:01:08 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PQx9-0005ot-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 14:01:07 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59I33B22293;
	Mon, 9 Jun 2003 14:03:03 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59I2HB22225
	for <lemonade@optimus.ietf.org>; Mon, 9 Jun 2003 14:02:17 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14553
	for <lemonade@ietf.org>; Mon, 9 Jun 2003 14:02:12 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PQwF-0005np-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 14:00:11 -0400
Received: from oe-im2pub.managedmail.com ([206.46.164.53] helo=oe-im2.bizmailsrvcs.net)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PQwE-0005n4-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 14:00:10 -0400
Received: from oe-ismta2.bizmailsrvcs.net ([206.46.164.29])
          by oe-im2.bizmailsrvcs.net
          (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP
          id <20030609180141.DVNM7174.oe-im2.bizmailsrvcs.net@oe-ismta2.bizmailsrvcs.net>;
          Mon, 9 Jun 2003 13:01:41 -0500
Received: from AKSTEBBENS.mshome.net ([64.14.194.172])
          by oe-ismta2.bizmailsrvcs.net
          (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP
          id <20030609180141.ZTEK8315.oe-ismta2.bizmailsrvcs.net@AKSTEBBENS.mshome.net>;
          Mon, 9 Jun 2003 13:01:41 -0500
Date: Mon, 9 Jun 2003 11:01:40 -0700
From: "Alan K. Stebbens" <alan.stebbens@openwave.com>
X-Mailer: The Bat! (v1.62r) Personal
Reply-To: "Alan K. Stebbens" <alan.stebbens@openwave.com>
Organization: Openwave Systems, Inc.
X-Priority: 3 (Normal)
Message-ID: <639142451.20030609110140@openwave.com>
To: "Eric Burger" <eburger@snowshore.com>
CC: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: Re: [lemonade] Life on the List, and Vienna
In-Reply-To: <4A3384433CE2AB46A63468CB207E209D59E327@zoe.office.snowshore.com>
References: <4A3384433CE2AB46A63468CB207E209D59E327@zoe.office.snowshore.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hello Eric,

EB> Now that things are moving again, do we want to meet in Vienna?

Of course, this is a good idea.  I'll be there.

I agree with the idea of discussing changes or innovations.  I'll contribute
my $0.02 to the discussion:

Based on innovative use of IMAP for mobile messaging that we have
participated in, with different mobile operators, I'd suggest that the
essential requirements for mobile messaging consist of the following:

a1. Efficient, Binary Transport of Multimedia Message Components

    An efficient, access protocol that allows partial or complete access,
    with efficient transport of binary data, to multimedia message and
    information about it (content-type, MIME structure, etc.).

    The retrieval of meta-data should be made as efficient as possible, and
    also allow the client to control how much information is returned for
    any given request.

A2. Additional, External Content Processing for Accessed Messages

    The access protocol must support a mechanism to allow some messaging
    clients to be able to request additional processing on one or more
    components of the original multimedia content. Examples of additional
    processing include: image size and format transformations, audio codec
    transcoding, text-to-speech, and speech-to-text, etc.

b1. Efficient, Binary Messaging Submission

    A message submission protocol that supports efficient binary transport.


b2. External References

    The Messaging Submission protocol must support an external reference
    mechanism by which multiple components can be assembled into a
    multimedia message.

    The reference mechanism must allow for references to messages, or
    components of messages, obtained from [a], must be transparent to the
    eventual recipients(s), and must not depend upon or require
    authentication agreements between the originator and recipient(s).


These four requirements, two for access and two for submission, are the
essence of the kinds of innovative adaptations made by mobile operators in
achieving a viable multimedia mobile messaging service.

If you read these requirements carefully, you'll notice that it is *not* a
foregone conclusion that IMAP (which fulfills [a1] easily) should be adapted
to fulfill either [b1] or [b2].

I think IMAP4, with BINARY, WINDOW, & SORT features, supports [a1]

IMAP4 CHANNEL supports [a2]

SMTP with BDAT supports [a3]

And, IMHO, the Path of Least Resistance would be to introduce a new SMTP
command, say, ATTACH, by which the contents addressed by a URL would be
inserted, as an additional MIME object, into the outgoing message.

The issue of whether or not the ATTACH URL were authenticated or not depends
upon the scheme referenced in the URL.


-- 
Best regards,
 Alan K. Stebbens <alan.stebbens@openwave.com>
 Principal Product Technologist, Messaging
 Openwave Systems, Inc.
 Cell: +1.805.886.8886  Voice/Fax: +1.866.579.0801
 Desk: +1.805.884.3162
 YIM/MSN: alan_stebbens  ICQ: 51361674  AIM: akstebbens   

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



From mailnull@www1.ietf.org  Mon Jun  9 14:13:31 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14927
	for <lemonade-archive@odin.ietf.org>; Mon, 9 Jun 2003 14:13:31 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h59ID6S23872
	for lemonade-archive@odin.ietf.org; Mon, 9 Jun 2003 14:13:06 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59ID6B23869
	for <lemonade-web-archive@optimus.ietf.org>; Mon, 9 Jun 2003 14:13:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14916
	for <lemonade-web-archive@ietf.org>; Mon, 9 Jun 2003 14:13:00 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PR6i-0005u0-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 14:11:00 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PR6h-0005tx-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 14:10:59 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59ID2B23833;
	Mon, 9 Jun 2003 14:13:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59ICMB23799
	for <lemonade@optimus.ietf.org>; Mon, 9 Jun 2003 14:12:22 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14889
	for <lemonade@ietf.org>; Mon, 9 Jun 2003 14:12:17 -0400 (EDT)
From: hardie@qualcomm.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PR60-0005tX-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 14:10:16 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PR5z-0005tU-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 14:10:16 -0400
Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149])
	by numenor.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h59ICDXF008449
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Mon, 9 Jun 2003 11:12:14 -0700 (PDT)
Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161])
	by neophyte.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h59ICBuh018751;
	Mon, 9 Jun 2003 11:12:11 -0700 (PDT)
Mime-Version: 1.0
X-Sender: hardie@mage.qualcomm.com
Message-Id: <p06001204bb0a7dfdc193@[129.46.227.161]>
In-Reply-To: <639142451.20030609110140@openwave.com>
References: 
 <4A3384433CE2AB46A63468CB207E209D59E327@zoe.office.snowshore.com>
 <639142451.20030609110140@openwave.com>
Date: Mon, 9 Jun 2003 11:12:14 -0700
To: "Alan K. Stebbens" <alan.stebbens@openwave.com>,
        "Eric Burger" <eburger@snowshore.com>
Subject: Re: [lemonade] Life on the List, and Vienna
Cc: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

Hi Alan,
	In both A1 and B1, you have Efficient, Binary as
pair of linked needs.  Are they linked because you see
"binary" as the only way to achieve "efficient"?  If
not, is there a different need for this requirement for binary
transport?
			regards,
				Ted Hardie

At 11:01 AM -0700 6/9/03, Alan K. Stebbens wrote:
>Hello Eric,
>
>EB> Now that things are moving again, do we want to meet in Vienna?
>
>Of course, this is a good idea.  I'll be there.
>
>I agree with the idea of discussing changes or innovations.  I'll contribute
>my $0.02 to the discussion:
>
>Based on innovative use of IMAP for mobile messaging that we have
>participated in, with different mobile operators, I'd suggest that the
>essential requirements for mobile messaging consist of the following:
>
>a1. Efficient, Binary Transport of Multimedia Message Components
>
>     An efficient, access protocol that allows partial or complete access,
>     with efficient transport of binary data, to multimedia message and
>     information about it (content-type, MIME structure, etc.).
>
>     The retrieval of meta-data should be made as efficient as possible, and
>     also allow the client to control how much information is returned for
>     any given request.
>
>A2. Additional, External Content Processing for Accessed Messages
>
>     The access protocol must support a mechanism to allow some messaging
>     clients to be able to request additional processing on one or more
>     components of the original multimedia content. Examples of additional
>     processing include: image size and format transformations, audio codec
>     transcoding, text-to-speech, and speech-to-text, etc.
>
>b1. Efficient, Binary Messaging Submission
>
>     A message submission protocol that supports efficient binary transport.
>
>
>b2. External References
>
>     The Messaging Submission protocol must support an external reference
>     mechanism by which multiple components can be assembled into a
>     multimedia message.
>
>     The reference mechanism must allow for references to messages, or
>     components of messages, obtained from [a], must be transparent to the
>     eventual recipients(s), and must not depend upon or require
>     authentication agreements between the originator and recipient(s).
>
>
>These four requirements, two for access and two for submission, are the
>essence of the kinds of innovative adaptations made by mobile operators in
>achieving a viable multimedia mobile messaging service.
>
>If you read these requirements carefully, you'll notice that it is *not* a
>foregone conclusion that IMAP (which fulfills [a1] easily) should be adapted
>to fulfill either [b1] or [b2].
>
>I think IMAP4, with BINARY, WINDOW, & SORT features, supports [a1]
>
>IMAP4 CHANNEL supports [a2]
>
>SMTP with BDAT supports [a3]
>
>And, IMHO, the Path of Least Resistance would be to introduce a new SMTP
>command, say, ATTACH, by which the contents addressed by a URL would be
>inserted, as an additional MIME object, into the outgoing message.
>
>The issue of whether or not the ATTACH URL were authenticated or not depends
>upon the scheme referenced in the URL.

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



From mailnull@www1.ietf.org  Mon Jun  9 14:26:51 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15502
	for <lemonade-archive@odin.ietf.org>; Mon, 9 Jun 2003 14:26:50 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h59IQQs24998
	for lemonade-archive@odin.ietf.org; Mon, 9 Jun 2003 14:26:26 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59IQQB24995
	for <lemonade-web-archive@optimus.ietf.org>; Mon, 9 Jun 2003 14:26:26 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15482
	for <lemonade-web-archive@ietf.org>; Mon, 9 Jun 2003 14:26:20 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PRJc-00062O-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 14:24:20 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PRJb-00062L-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 14:24:19 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59IQEB24973;
	Mon, 9 Jun 2003 14:26:14 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59IPlB24935
	for <lemonade@optimus.ietf.org>; Mon, 9 Jun 2003 14:25:47 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15438
	for <lemonade@ietf.org>; Mon, 9 Jun 2003 14:25:42 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PRJ0-00061s-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 14:23:42 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PRIz-00061o-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 14:23:41 -0400
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150])
	by numenor.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h59IPXXF009270
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Mon, 9 Jun 2003 11:25:33 -0700 (PDT)
Received: from [10.10.0.150] (vpn-10-50-0-110.qualcomm.com [10.50.0.110])
	by sabrina.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h59IP5BC017756;
	Mon, 9 Jun 2003 11:25:12 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <a06001406bb0a7f742ef1@[10.10.0.150]>
In-Reply-To: <3EE4C3EB.A8A32ABE@sun.com>
References: <3EE4C3EB.A8A32ABE@sun.com>
X-Mailer: Eudora for Mac OS X v6.0a
Date: Mon, 9 Jun 2003 14:24:51 -0400
To: "Jonathan T. Hawkins" <Jonathan.Hawkins@sun.com>, mrc@CAC.Washington.EDU
From: Randall Gellens <randy@qualcomm.com>
Subject: RE: [lemonade] Life on the List, and Vienna
Cc: lemonade@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b25
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

At 10:29 AM -0700 6/9/03, Jonathan T. Hawkins wrote:

>  At the moment, I'm not quite sure which is more desirable: IMAP delivery
>  (many folks against it) or IMAP URL ACLs (complicated).  The URL
>  ACL-based IMAP access presents some complications in access managment
>  for a site.  The ACL aging policy might be something worth looking at.
>
>  Another option would be to extend SMTP to reference an IMAP URL?  In
>  this manner, the server-side Authenticated SMTP session could provide
>  the SASL mechanism to retrieve the IMAP data.

We had a lot of discussion on this in San Francisco.  Essentially, 
there are two camps:
	- Add submission to IMAP
		- Use IMAP Outbox or Drafts folder
		- Store desired Submit (port 587) envelope in annotation
		- Can include references to IMAP parts
		- References to IMAP parts are expanded on submission
		> Requires Submit server to trust IMAP server, or adding 
Submission to IMAP server
		> Need to be careful that all enhancements are done by using 
Submit mechanisms, otherwise we end up defining two parallel 
submission mechanisms, one for Port 587 and one for IMAP.

	- Add IMAP (and maybe other) URLs to Submission (port 587)
		- Allow arbitrary content to be incorporated into messages 
without first downloading by client
		> Requires IMAP server to trust Submit server

I apologize if I misstated either camp.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Arguments are to be avoided; they are always vulgar and often convincing.                                     --Oscar Wilde
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Mon Jun  9 14:34:31 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15947
	for <lemonade-archive@odin.ietf.org>; Mon, 9 Jun 2003 14:34:30 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h59IY6S25533
	for lemonade-archive@odin.ietf.org; Mon, 9 Jun 2003 14:34:06 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59IY6B25530
	for <lemonade-web-archive@optimus.ietf.org>; Mon, 9 Jun 2003 14:34:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15927
	for <lemonade-web-archive@ietf.org>; Mon, 9 Jun 2003 14:34:00 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PRR2-00068i-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 14:32:00 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PRR1-00068f-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 14:31:59 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59IY1B25520;
	Mon, 9 Jun 2003 14:34:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59IX5B25473
	for <lemonade@optimus.ietf.org>; Mon, 9 Jun 2003 14:33:05 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15914
	for <lemonade@ietf.org>; Mon, 9 Jun 2003 14:32:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PRQ3-00068I-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 14:30:59 -0400
Received: from panda.com
	([206.124.149.114] helo=Ikkoku-Kan.Panda.COM ident=azuma)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PRQ1-00068D-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 14:30:57 -0400
Received: from localhost (mrc@localhost) by Ikkoku-Kan.Panda.COM id LAA17014; Mon, 9 Jun 2003 11:32:36 -0700 (PDT)
Date: Mon, 9 Jun 2003 11:32:35 -0700 (PDT)
From: Mark Crispin <mrc@CAC.Washington.EDU>
To: "Jonathan T. Hawkins" <Jonathan.Hawkins@Sun.COM>
cc: lemonade@ietf.org
Subject: RE: [lemonade] Life on the List, and Vienna
In-Reply-To: <3EE4C3EB.A8A32ABE@sun.com>
Message-ID: <Pine.NXT.4.56.0306091122140.11845@Ikkoku-Kan.Panda.COM>
References: <3EE4C3EB.A8A32ABE@sun.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Mon, 9 Jun 2003, Jonathan T. Hawkins wrote:
> On a mobile mail
> user agent device, it is absolutely painful to pull down media content
> over the air, repackage, and then resubmit back over the air.  If I
> could just forward the message, it would be a much better user
> experience.

I think that everybody agrees on this point.

> At the moment, I'm not quite sure which is more desirable: IMAP delivery
> (many folks against it) or IMAP URL ACLs (complicated).

I think that the complexity is the same with both; however the latter is
more functional.  No matter how you look at it, you need a mechanism to
have "insert such-and-such here" tokens in a message.

> Another option would be to extend SMTP to reference an IMAP URL?  In
> this manner, the server-side Authenticated SMTP session could provide
> the SASL mechanism to retrieve the IMAP data.

Something in this line is the right track, although obviously refinements
and functional enhancements are necessary.

-- 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 mailnull@www1.ietf.org  Mon Jun  9 14:35:39 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16015
	for <lemonade-archive@odin.ietf.org>; Mon, 9 Jun 2003 14:35:39 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h59IZEs25594
	for lemonade-archive@odin.ietf.org; Mon, 9 Jun 2003 14:35:14 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59IZEB25591
	for <lemonade-web-archive@optimus.ietf.org>; Mon, 9 Jun 2003 14:35:14 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15990
	for <lemonade-web-archive@ietf.org>; Mon, 9 Jun 2003 14:35:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PRS8-000691-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 14:33:08 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PRS7-00068y-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 14:33:07 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59IZ2B25581;
	Mon, 9 Jun 2003 14:35:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59IYnB25559
	for <lemonade@optimus.ietf.org>; Mon, 9 Jun 2003 14:34:49 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15963
	for <lemonade@ietf.org>; Mon, 9 Jun 2003 14:34:43 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PRRj-00068o-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 14:32:43 -0400
Received: from oe-im2pub.managedmail.com ([206.46.164.53] helo=oe-im2.bizmailsrvcs.net)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PRRj-00068l-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 14:32:43 -0400
Received: from oe-ismta2.bizmailsrvcs.net ([206.46.164.29])
          by oe-im2.bizmailsrvcs.net
          (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP
          id <20030609183414.EBJY7174.oe-im2.bizmailsrvcs.net@oe-ismta2.bizmailsrvcs.net>;
          Mon, 9 Jun 2003 13:34:14 -0500
Received: from AKSTEBBENS.mshome.net ([64.14.194.172])
          by oe-ismta2.bizmailsrvcs.net
          (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP
          id <20030609183414.ZYKT8315.oe-ismta2.bizmailsrvcs.net@AKSTEBBENS.mshome.net>;
          Mon, 9 Jun 2003 13:34:14 -0500
Date: Mon, 9 Jun 2003 11:34:13 -0700
From: "Alan K. Stebbens" <alan.stebbens@openwave.com>
X-Mailer: The Bat! (v1.62r) Personal
Reply-To: "Alan K. Stebbens" <alan.stebbens@openwave.com>
Organization: Openwave Systems, Inc.
X-Priority: 3 (Normal)
Message-ID: <123306705.20030609113413@openwave.com>
To: hardie@qualcomm.com
CC: "Eric Burger" <eburger@snowshore.com>,
        "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: Re: [lemonade] Life on the List, and Vienna
In-Reply-To: <p06001204bb0a7dfdc193@[129\.46\.227\.161]>
References: <4A3384433CE2AB46A63468CB207E209D59E327@zoe.office.snowshore.com>
 <639142451.20030609110140@openwave.com> <p06001204bb0a7dfdc193@[129.46.227.161]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

hqc> In both A1 and B1, you have Efficient, Binary as pair of linked needs.
hqc> Are they linked because you see "binary" as the only way to achieve
hqc> "efficient"? If not, is there a different need for this requirement for
hqc> binary transport?

Hello Ted,

Efficient is needed to minimize the over-the-air byte count, which is the
basis for mobile operator billing to subscribers

Binary is needed to transport multimedia objects, such as audio files,
pictures, and even video files.

In theory, both are independent requirements, but with both being important,
they often end up being linked in practice.

--
Best regards,
Alan K. Stebbens

Monday, June 9, 2003, 11:12:14 AM, you wrote, in part:

>>EB> Now that things are moving again, do we want to meet in Vienna?
>>
>>Of course, this is a good idea.  I'll be there.
>>
>>I agree with the idea of discussing changes or innovations.  I'll contribute
>>my $0.02 to the discussion:
>>
>>Based on innovative use of IMAP for mobile messaging that we have
>>participated in, with different mobile operators, I'd suggest that the
>>essential requirements for mobile messaging consist of the following:
>>
>>a1. Efficient, Binary Transport of Multimedia Message Components
>>
>>     An efficient, access protocol that allows partial or complete access,
>>     with efficient transport of binary data, to multimedia message and
>>     information about it (content-type, MIME structure, etc.).
>>
>>     The retrieval of meta-data should be made as efficient as possible, and
>>     also allow the client to control how much information is returned for
>>     any given request.
>>
>>A2. Additional, External Content Processing for Accessed Messages
>>
>>     The access protocol must support a mechanism to allow some messaging
>>     clients to be able to request additional processing on one or more
>>     components of the original multimedia content. Examples of additional
>>     processing include: image size and format transformations, audio codec
>>     transcoding, text-to-speech, and speech-to-text, etc.
>>
>>b1. Efficient, Binary Messaging Submission
>>
>>     A message submission protocol that supports efficient binary transport.
>>
>>
>>b2. External References
>>
>>     The Messaging Submission protocol must support an external reference
>>     mechanism by which multiple components can be assembled into a
>>     multimedia message.
>>
>>     The reference mechanism must allow for references to messages, or
>>     components of messages, obtained from [a], must be transparent to the
>>     eventual recipients(s), and must not depend upon or require
>>     authentication agreements between the originator and recipient(s).
>>
>>
>>These four requirements, two for access and two for submission, are the
>>essence of the kinds of innovative adaptations made by mobile operators in
>>achieving a viable multimedia mobile messaging service.
>>
>>If you read these requirements carefully, you'll notice that it is *not* a
>>foregone conclusion that IMAP (which fulfills [a1] easily) should be adapted
>>to fulfill either [b1] or [b2].
>>
>>I think IMAP4, with BINARY, WINDOW, & SORT features, supports [a1]
>>
>>IMAP4 CHANNEL supports [a2]
>>
>>SMTP with BDAT supports [a3]
>>
>>And, IMHO, the Path of Least Resistance would be to introduce a new SMTP
>>command, say, ATTACH, by which the contents addressed by a URL would be
>>inserted, as an additional MIME object, into the outgoing message.
>>
>>The issue of whether or not the ATTACH URL were authenticated or not depends
>>upon the scheme referenced in the URL.

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


-- 
Best regards,
 Alan K. Stebbens <alan.stebbens@openwave.com>
 Principal Product Technologist, Messaging
 Openwave Systems, Inc.
 Cell: +1.805.886.8886  Voice/Fax: +1.866.579.0801
 Desk: +1.805.884.3162
 YIM/MSN: alan_stebbens  ICQ: 51361674  AIM: akstebbens   

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



From mailnull@www1.ietf.org  Mon Jun  9 14:49:29 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16333
	for <lemonade-archive@odin.ietf.org>; Mon, 9 Jun 2003 14:49:29 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h59In5727021
	for lemonade-archive@odin.ietf.org; Mon, 9 Jun 2003 14:49:05 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59In5B27018
	for <lemonade-web-archive@optimus.ietf.org>; Mon, 9 Jun 2003 14:49:05 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16326
	for <lemonade-web-archive@ietf.org>; Mon, 9 Jun 2003 14:48:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PRfX-0006Dt-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 14:46:59 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PRfW-0006Dq-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 14:46:58 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59In1B27009;
	Mon, 9 Jun 2003 14:49:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59ImeB26985
	for <lemonade@optimus.ietf.org>; Mon, 9 Jun 2003 14:48:40 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16320
	for <lemonade@ietf.org>; Mon, 9 Jun 2003 14:48:34 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PRf7-0006Di-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 14:46:34 -0400
Received: from brmea-mail-2.sun.com ([192.18.98.43])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PRf7-0006Df-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 14:46:33 -0400
Received: from esunmail ([129.147.58.198])
	by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h59ImYYU028819
	for <lemonade@ietf.org>; Mon, 9 Jun 2003 12:48:34 -0600 (MDT)
Received: from xpa-fe1 ([129.147.58.198]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003))
 with ESMTP id <0HG8008YY9H5H9@edgemail1.Central.Sun.COM> for
 lemonade@ietf.org; Mon, 09 Jun 2003 12:46:18 -0600 (MDT)
Received: from sun.com ([192.18.127.234])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003))
 with ESMTPSA id <0HG8003S69H4DM@mail.sun.net> for lemonade@ietf.org; Mon,
 09 Jun 2003 12:46:17 -0600 (MDT)
Date: Mon, 09 Jun 2003 11:46:16 -0700
From: "Jonathan T. Hawkins" <Jonathan.Hawkins@Sun.COM>
Subject: Re: [lemonade] Life on the List, and Vienna
To: Mark Crispin <mrc@CAC.Washington.EDU>
Cc: lemonade@ietf.org
Message-id: <3EE4D5F7.E0F4750D@sun.com>
Organization: Sun ONE - A Division of Sun Microsystems, Inc.
MIME-version: 1.0
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
Content-type: multipart/mixed; boundary="Boundary_(ID_CMOo+UN2SnpGYUjBnHn7KQ)"
X-Accept-Language: rs1_e48b1af90ad, rs2_14901981695, rs3_e0801f426d
References: <3EE4C3EB.A8A32ABE@sun.com>
 <Pine.NXT.4.56.0306091122140.11845@Ikkoku-Kan.Panda.COM>
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This is a multi-part message in MIME format.

--Boundary_(ID_CMOo+UN2SnpGYUjBnHn7KQ)
Content-type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7BIT



Mark Crispin wrote:

> On Mon, 9 Jun 2003, Jonathan T. Hawkins wrote:
> > On a mobile mail
> > user agent device, it is absolutely painful to pull down media content
> > over the air, repackage, and then resubmit back over the air.  If I
> > could just forward the message, it would be a much better user
> > experience.
>
> I think that everybody agrees on this point.
>

Ok.. great

>
> > At the moment, I'm not quite sure which is more desirable: IMAP delivery
> > (many folks against it) or IMAP URL ACLs (complicated).
>
> I think that the complexity is the same with both; however the latter is
> more functional.  No matter how you look at it, you need a mechanism to
> have "insert such-and-such here" tokens in a message.
>

I'll sit back and let my accomplished collegues figure out this one.

>
> > Another option would be to extend SMTP to reference an IMAP URL?  In
> > this manner, the server-side Authenticated SMTP session could provide
> > the SASL mechanism to retrieve the IMAP data.
>
> Something in this line is the right track, although obviously refinements
> and functional enhancements are necessary.
>

I'd like to test the waters with this idea.  I'll put together a draft.

Cheers..

Jonathan

--Boundary_(ID_CMOo+UN2SnpGYUjBnHn7KQ)
Content-type: text/x-vcard; charset=us-ascii; name=jonathan.hawkins.vcf
Content-disposition: attachment; filename=jonathan.hawkins.vcf
Content-description: Card for Jonathan T. Hawkins
Content-Transfer-Encoding: 7BIT

begin:vcard 
n:Hawkins;Jonathan
tel;cell:408-718-0463
tel;work:408-276-4245
x-mozilla-html:FALSE
url:http://viking.red.iplanet.com/users/jhawk/publish/
org:Sun ONE NICP Communication Products;Software Deployment Engineering
version:2.1
email;internet:Jonathan.Hawkins@sun.com
title:Unified Communications Architect, Staff Engineer 
adr;quoted-printable:;;4150 Network Circle=0D=0ASCA15-201;Santa Clara;CA;95054;USA
fn:Jonathan Hawkins
end:vcard

--Boundary_(ID_CMOo+UN2SnpGYUjBnHn7KQ)--
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Mon Jun  9 15:01:36 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16804
	for <lemonade-archive@odin.ietf.org>; Mon, 9 Jun 2003 15:01:36 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h59J1CD27583
	for lemonade-archive@odin.ietf.org; Mon, 9 Jun 2003 15:01:12 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59J1CB27580
	for <lemonade-web-archive@optimus.ietf.org>; Mon, 9 Jun 2003 15:01:12 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16786
	for <lemonade-web-archive@ietf.org>; Mon, 9 Jun 2003 15:01:06 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PRrF-0006JL-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 14:59:05 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PRrF-0006JI-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 14:59:05 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59J11B27557;
	Mon, 9 Jun 2003 15:01:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59J0nB27508
	for <lemonade@optimus.ietf.org>; Mon, 9 Jun 2003 15:00:49 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16770
	for <lemonade@ietf.org>; Mon, 9 Jun 2003 15:00:42 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PRqs-0006Iz-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 14:58:42 -0400
Received: from panda.com
	([206.124.149.114] helo=Ikkoku-Kan.Panda.COM ident=cao)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PRqr-0006Iw-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 14:58:41 -0400
Received: from localhost (mrc@localhost) by Ikkoku-Kan.Panda.COM id MAA17045; Mon, 9 Jun 2003 12:00:27 -0700 (PDT)
Date: Mon, 9 Jun 2003 12:00:26 -0700 (PDT)
From: Mark Crispin <mrc@CAC.Washington.EDU>
To: Randall Gellens <randy@qualcomm.com>
cc: "Jonathan T. Hawkins" <Jonathan.Hawkins@sun.com>, lemonade@ietf.org
Subject: RE: [lemonade] Life on the List, and Vienna
In-Reply-To: <a06001406bb0a7f742ef1@[10.10.0.150]>
Message-ID: <Pine.NXT.4.56.0306091132430.11845@Ikkoku-Kan.Panda.COM>
References: <3EE4C3EB.A8A32ABE@sun.com> <a06001406bb0a7f742ef1@[10.10.0.150]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Mon, 9 Jun 2003, Randall Gellens wrote:
> We had a lot of discussion on this in San Francisco.  Essentially,
> there are two camps:
> 	- Add submission to IMAP
> 		- Use IMAP Outbox or Drafts folder
> 		- Store desired Submit (port 587) envelope in annotation
> 		- Can include references to IMAP parts
> 		- References to IMAP parts are expanded on submission
> 		> Requires Submit server to trust IMAP server, or adding
> Submission to IMAP server
> 		> Need to be careful that all enhancements are done by using
> Submit mechanisms, otherwise we end up defining two parallel
> submission mechanisms, one for Port 587 and one for IMAP.
>
> 	- Add IMAP (and maybe other) URLs to Submission (port 587)
> 		- Allow arbitrary content to be incorporated into messages
> without first downloading by client
> 		> Requires IMAP server to trust Submit server

You missed an important insight developed in the second camp:
	It is NOT necessary for the IMAP server to trust the
	Submit server if we create a mechanism (URL or otherwise)
	that permits the Submit server to obtain the data it needs
	without granting it unnecessary access.

If this mechanism is based upon IMAP URLs, then we have something that we
use today, with *all* IMAP servers.  With traditional IMAP servers, the
mobile client would generate a traditional IMAP URL which would require
trust of the submit server.  With enhanced IMAP servers, the client would
generate a new-type IMAP URL that doesn't require trust.

Mobile clients will benefit because they can be deployed without requiring
a change to the IMAP server.  A mobile client that requires a special IMAP
server will face a deployment barrier.  An IT department that refuses to
offer the special IMAP server will effectively block the mobile clients.

A large (and growing number) of deployed mobile clients will serve to
convince IMAP server vendors to support the URL extensions so trust is not
required.  Assuming that the security issues in the URL extensions can be
resolved (and I think that they can), it will be almost a no-brainer to
add them to an IMAP server.

Another important detail about the second camp is that it does not depend
upon all the data for submit being on one IMAP server.  We have facilities
today in which such a dependency would be fatal.

-- 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 mailnull@www1.ietf.org  Mon Jun  9 15:36:43 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18719
	for <lemonade-archive@odin.ietf.org>; Mon, 9 Jun 2003 15:36:43 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h59JaGD30043
	for lemonade-archive@odin.ietf.org; Mon, 9 Jun 2003 15:36:16 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59JaFB30040
	for <lemonade-web-archive@optimus.ietf.org>; Mon, 9 Jun 2003 15:36:15 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18706
	for <lemonade-web-archive@ietf.org>; Mon, 9 Jun 2003 15:36:13 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PSPF-0006Uo-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 15:34:13 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PSPE-0006Ul-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 15:34:12 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59Ja4B30013;
	Mon, 9 Jun 2003 15:36:04 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59JZPB29993
	for <lemonade@optimus.ietf.org>; Mon, 9 Jun 2003 15:35:25 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18681
	for <lemonade@ietf.org>; Mon, 9 Jun 2003 15:35:22 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PSOQ-0006UQ-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 15:33:22 -0400
Received: from ahimsa.guppylake.com ([208.177.184.197])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PSOP-0006UN-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 15:33:21 -0400
Received: from floater.guppylake.com (floater.guppylake.com [208.177.184.198])
	by ahimsa.guppylake.com (8.12.8/8.12.8) with ESMTP id h59JPHg3028445;
	Mon, 9 Jun 2003 15:25:17 -0400
Subject: Re: [lemonade] Life on the List, and Vienna
From: Nathaniel Borenstein <nsb@guppylake.com>
To: "Alan K. Stebbens" <alan.stebbens@openwave.com>
Cc: Eric Burger <eburger@snowshore.com>,
        "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
In-Reply-To: <639142451.20030609110140@openwave.com>
References: 
	 <4A3384433CE2AB46A63468CB207E209D59E327@zoe.office.snowshore.com>
	 <639142451.20030609110140@openwave.com>
Content-Type: text/plain
Message-Id: <1055187322.3665.2.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) 
Date: 09 Jun 2003 15:35:22 -0400
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

On Mon, 2003-06-09 at 14:01, Alan K. Stebbens wrote:

> And, IMHO, the Path of Least Resistance would be to introduce a new SMTP
> command, say, ATTACH, by which the contents addressed by a URL would be
> inserted, as an additional MIME object, into the outgoing message.

Pardon me if I'm coming into this discussion a bit late, but couldn't
you accomplish the same thing by defining this as the default behavior
of a mobile messaging gateway that encounters a MIME type of
message/external-body?  I'm not clear why you can't use that existing
MIME type.  -- Nathaniel

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



From mailnull@www1.ietf.org  Mon Jun  9 15:44:38 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18965
	for <lemonade-archive@odin.ietf.org>; Mon, 9 Jun 2003 15:44:38 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h59JiBc31204
	for lemonade-archive@odin.ietf.org; Mon, 9 Jun 2003 15:44:11 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59JiBB31201
	for <lemonade-web-archive@optimus.ietf.org>; Mon, 9 Jun 2003 15:44:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18945
	for <lemonade-web-archive@ietf.org>; Mon, 9 Jun 2003 15:44:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PSWu-0006XV-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 15:42:08 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PSWt-0006XS-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 15:42:07 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59Ji1B31167;
	Mon, 9 Jun 2003 15:44:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59Jh0B31105
	for <lemonade@optimus.ietf.org>; Mon, 9 Jun 2003 15:43:00 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18892
	for <lemonade@ietf.org>; Mon, 9 Jun 2003 15:42:57 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PSVl-0006X3-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 15:40:57 -0400
Received: from brmea-mail-2.sun.com ([192.18.98.43])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PSVk-0006Wz-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 15:40:56 -0400
Received: from esunmail ([129.147.58.120])
	by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h59JgvYU001881
	for <lemonade@ietf.org>; Mon, 9 Jun 2003 13:42:57 -0600 (MDT)
Received: from xpa-fe2 ([129.147.58.198]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003))
 with ESMTP id <0HG800M6DBZRMN@edgemail1.Central.Sun.COM> for
 lemonade@ietf.org; Mon, 09 Jun 2003 13:40:40 -0600 (MDT)
Received: from sun.com ([192.18.127.234])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003))
 with ESMTPSA id <0HG8005KNBZQVI@mail.sun.net> for lemonade@ietf.org; Mon,
 09 Jun 2003 13:40:39 -0600 (MDT)
Date: Mon, 09 Jun 2003 12:40:38 -0700
From: "Jonathan T. Hawkins" <Jonathan.Hawkins@Sun.COM>
Subject: Re: [lemonade] Life on the List, and Vienna
To: Nathaniel Borenstein <nsb@guppylake.com>
Cc: "Alan K. Stebbens" <alan.stebbens@openwave.com>,
        Eric Burger <eburger@snowshore.com>,
        "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Message-id: <3EE4E2B5.49BB0A80@sun.com>
Organization: Sun ONE - A Division of Sun Microsystems, Inc.
MIME-version: 1.0
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
Content-type: multipart/mixed; boundary="Boundary_(ID_KSbeoz3qvlSF7hSuloC9tA)"
X-Accept-Language: rs1_e48b1af90ad, rs2_14901981695, rs3_e0801f426d
References: <4A3384433CE2AB46A63468CB207E209D59E327@zoe.office.snowshore.com>
 <639142451.20030609110140@openwave.com>
 <1055187322.3665.2.camel@localhost.localdomain>
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This is a multi-part message in MIME format.

--Boundary_(ID_KSbeoz3qvlSF7hSuloC9tA)
Content-type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7BIT

At the moment, the embedded URLs are pulled together via the MUA, the IMAP
client.  The proposal is for SMTP MTA side composition.

Jonathan

Nathaniel Borenstein wrote:

> On Mon, 2003-06-09 at 14:01, Alan K. Stebbens wrote:
>
> > And, IMHO, the Path of Least Resistance would be to introduce a new SMTP
> > command, say, ATTACH, by which the contents addressed by a URL would be
> > inserted, as an additional MIME object, into the outgoing message.
>
> Pardon me if I'm coming into this discussion a bit late, but couldn't
> you accomplish the same thing by defining this as the default behavior
> of a mobile messaging gateway that encounters a MIME type of
> message/external-body?  I'm not clear why you can't use that existing
> MIME type.  -- Nathaniel
>
> _______________________________________________
> lemonade mailing list
> lemonade@ietf.org
> https://www1.ietf.org/mailman/listinfo/lemonade

--Boundary_(ID_KSbeoz3qvlSF7hSuloC9tA)
Content-type: text/x-vcard; charset=us-ascii; name=jonathan.hawkins.vcf
Content-disposition: attachment; filename=jonathan.hawkins.vcf
Content-description: Card for Jonathan T. Hawkins
Content-Transfer-Encoding: 7BIT

begin:vcard 
n:Hawkins;Jonathan
tel;cell:408-718-0463
tel;work:408-276-4245
x-mozilla-html:FALSE
url:http://viking.red.iplanet.com/users/jhawk/publish/
org:Sun ONE NICP Communication Products;Software Deployment Engineering
version:2.1
email;internet:Jonathan.Hawkins@sun.com
title:Unified Communications Architect, Staff Engineer 
adr;quoted-printable:;;4150 Network Circle=0D=0ASCA15-201;Santa Clara;CA;95054;USA
fn:Jonathan Hawkins
end:vcard

--Boundary_(ID_KSbeoz3qvlSF7hSuloC9tA)--
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Mon Jun  9 16:14:42 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19730
	for <lemonade-archive@odin.ietf.org>; Mon, 9 Jun 2003 16:14:42 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h59KEFA00757
	for lemonade-archive@odin.ietf.org; Mon, 9 Jun 2003 16:14:15 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59KEFB00754
	for <lemonade-web-archive@optimus.ietf.org>; Mon, 9 Jun 2003 16:14:15 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19713
	for <lemonade-web-archive@ietf.org>; Mon, 9 Jun 2003 16:14:12 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PT00-0006hG-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 16:12:12 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PSzz-0006hD-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 16:12:11 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59KE1B00743;
	Mon, 9 Jun 2003 16:14:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59KDoB00717
	for <lemonade@optimus.ietf.org>; Mon, 9 Jun 2003 16:13:50 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19709
	for <lemonade@ietf.org>; Mon, 9 Jun 2003 16:13:47 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PSzb-0006hA-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 16:11:47 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PSza-0006h7-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 16:11:46 -0400
Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149])
	by numenor.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h59KDhXF015528
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Mon, 9 Jun 2003 13:13:44 -0700 (PDT)
Received: from [10.10.0.150] (vpn-10-50-16-23.qualcomm.com [10.50.16.23])
	by neophyte.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h59KCRuh010997;
	Mon, 9 Jun 2003 13:12:56 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <a0600140dbb0a9a3c75d7@[10.10.0.150]>
In-Reply-To: <3EE4E2B5.49BB0A80@sun.com>
References: 
 <4A3384433CE2AB46A63468CB207E209D59E327@zoe.office.snowshore.com>
 <639142451.20030609110140@openwave.com>
 <1055187322.3665.2.camel@localhost.localdomain>
 <3EE4E2B5.49BB0A80@sun.com>
X-Mailer: Eudora for Mac OS X v6.0a
Date: Mon, 9 Jun 2003 16:12:19 -0400
To: "Jonathan T. Hawkins" <Jonathan.Hawkins@sun.com>,
        Nathaniel Borenstein <nsb@guppylake.com>
From: Randall Gellens <randy@qualcomm.com>
Subject: Re: [lemonade] Life on the List, and Vienna
Cc: "Alan K. Stebbens" <alan.stebbens@openwave.com>,
        Eric Burger <eburger@snowshore.com>,
        "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b25
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

At 12:40 PM -0700 6/9/03, Jonathan T. Hawkins wrote:

>  At the moment, the embedded URLs are pulled together via the MUA, the IMAP
>  client.  The proposal is for SMTP MTA side composition.
>
>  Jonathan

I think the suggestion is to use message/external-body instead of 
URLs.  This has been discussed before, since it provides a clear way 
to distinguish between references which are to be expanded and those 
which should remain as-is.

>
>  Nathaniel Borenstein wrote:
>
>>  On Mon, 2003-06-09 at 14:01, Alan K. Stebbens wrote:
>>
>>  > And, IMHO, the Path of Least Resistance would be to introduce a new SMTP
>>  > command, say, ATTACH, by which the contents addressed by a URL would be
>>  > inserted, as an additional MIME object, into the outgoing message.
>>
>>  Pardon me if I'm coming into this discussion a bit late, but couldn't
>>  you accomplish the same thing by defining this as the default behavior
>>  of a mobile messaging gateway that encounters a MIME type of
>>  message/external-body?  I'm not clear why you can't use that existing
>>  MIME type.  -- Nathaniel
>>
>>  _______________________________________________
>>  lemonade mailing list
>>  lemonade@ietf.org
>>  https://www1.ietf.org/mailman/listinfo/lemonade
>
>  Content-type: text/x-vcard; charset=us-ascii; name=jonathan.hawkins.vcf
>  Content-disposition: attachment; filename=jonathan.hawkins.vcf
>  Content-description: Card for Jonathan T. Hawkins
>  Content-Transfer-Encoding: 7BIT
>
>  Attachment converted: TiLand:jonathan.hawkins 6.vcf (TEXT/R*ch) (0005D7CC)


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Beware of false knowledge; it is more dangerous than ignorance.
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Mon Jun  9 16:38:35 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20514
	for <lemonade-archive@odin.ietf.org>; Mon, 9 Jun 2003 16:38:35 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h59Kc9m02741
	for lemonade-archive@odin.ietf.org; Mon, 9 Jun 2003 16:38:09 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59Kc8B02738
	for <lemonade-web-archive@optimus.ietf.org>; Mon, 9 Jun 2003 16:38:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20501
	for <lemonade-web-archive@ietf.org>; Mon, 9 Jun 2003 16:38:04 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PTN6-0006qz-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 16:36:04 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PTN6-0006qw-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 16:36:04 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59Kc4B02727;
	Mon, 9 Jun 2003 16:38:04 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59KbOB02258
	for <lemonade@optimus.ietf.org>; Mon, 9 Jun 2003 16:37:24 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20448
	for <lemonade@ietf.org>; Mon, 9 Jun 2003 16:37:20 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PTMO-0006qB-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 16:35:20 -0400
Received: from champdsl-25-66.mcleodusa.net ([216.43.25.66] helo=episteme-software.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PTMN-0006ok-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 16:35:19 -0400
Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with
 ESMTP (Eudora Internet Mail Server X 3.2.2b1) for <lemonade@ietf.org>;
 Mon, 9 Jun 2003 15:36:47 -0500
Mime-Version: 1.0
X-Sender: resnick@resnick1.qualcomm.com
Message-Id: <p06001410bb0a97292a4e@[216.43.25.67]>
In-Reply-To: <Pine.NXT.4.56.0306091132430.11845@Ikkoku-Kan.Panda.COM>
References: <3EE4C3EB.A8A32ABE@sun.com>
 <a06001406bb0a7f742ef1@[10.10.0.150]>
 <Pine.NXT.4.56.0306091132430.11845@Ikkoku-Kan.Panda.COM>
X-Mailer: Eudora [Macintosh version 6.0a15]
Date: Mon, 9 Jun 2003 15:36:47 -0500
To: lemonade@ietf.org
From: Pete Resnick <presnick@qualcomm.com>
Subject: RE: [lemonade] Life on the List, and Vienna
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On 6/9/03 at 12:00 PM -0700, Mark Crispin wrote:

>On Mon, 9 Jun 2003, Randall Gellens wrote:
>>  We had a lot of discussion on this in San Francisco.  Essentially,
>>  there are two camps:
>>	- Add submission to IMAP
>>		- Use IMAP Outbox or Drafts folder

Yup.

>  >		- Store desired Submit (port 587) envelope in annotation

Or simply include that information in the IMAP command. As yet undetermined.

>  >		- Can include references to IMAP parts

Yup.

>  >		- References to IMAP parts are expanded on submission

Or might simply have some special parameter to an external-body which 
says "expand me if you submit me."

Another advantage is, "Does not require a submit server to know 
anything about MIME structure". Currently, an IMAP server needs to be 
able to parse MIME messages anyway. Current submit servers are often 
strictly 822 entities, and sometimes not even that smart. I don't see 
why we would dump more smarts into a submit server rather than 
including a single additional piece of functionality into an IMAP 
server.

>  >		> Requires Submit server to trust IMAP server, or 
>adding Submission to IMAP server

Yup, though having the submit server trust anything is often a matter 
of "is accessible within the firewall" in many environments today.

>  >		> Need to be careful that all enhancements are done 
>by using Submit mechanisms, otherwise we end up defining two 
>parallel submission mechanisms, one for Port 587 and one for IMAP.

This last one I think is a misrepresentation. It assumes that there 
are to be mechanisms in common. If (as I think about it) these are 
two completely separate services, then there is no reason to worry 
about any parallelisms.

>  >	- Add IMAP (and maybe other) URLs to Submission (port 587)
>  >		- Allow arbitrary content to be incorporated into 
>messages without first downloading by client

As I said above, this also requires the submit server to learn about 
MIME structure, as well as learn IMAP access.

>  >		> Requires IMAP server to trust Submit server
>
>You missed an important insight developed in the second camp:
>	It is NOT necessary for the IMAP server to trust the
>	Submit server if we create a mechanism (URL or otherwise)
>	that permits the Submit server to obtain the data it needs
>	without granting it unnecessary access.
>
>If this mechanism is based upon IMAP URLs, then we have something that we
>use today, with *all* IMAP servers.  With traditional IMAP servers, the
>mobile client would generate a traditional IMAP URL which would require
>trust of the submit server.  With enhanced IMAP servers, the client would
>generate a new-type IMAP URL that doesn't require trust.


This is the one that scares the daylights out of me. Right now, my 
IMAP server has all of my mail data and access to my IMAP server 
means access to all of that data. Every time I use IMAP, I *must* 
authenticate by means of an AUTH mechanism. Right now, my SMTP/submit 
server has *no* data, and access to my SMTP/submit server means only 
that I can submit mail, not that I can access any data. Often, an 
ISP's SMTP/submit server does not even need authentication passed to 
it (because it is based on allowing any machine with the correct IP 
address to send without further authentication).

The suggestion for the submit model is to invent a mechanism that has 
access to my IMAP store. You want to be able to grant it access to 
the particular MIME parts needed to compose this message, and then 
only given it access for a small period of time. (I'm inclined not to 
let my ISP's submit server have access for one second more than it 
needs to in order to get the message.) I am very worried about the 
overhead to authenticate the submit server. I am very worried about 
something getting it's mitts on the token I'm going to have to pass 
to the submit server that it's going to have to pass to my IMAP 
server. I am even worried about the fact that I have to pass *any* 
information to my submit server to allow it to get stuff from my IMAP 
server. I don't want my submit server to have *any* information that 
will allow it to access parts of my IMAP store. This sounds like a 
big gaping security hole.

In the case of using IMAP to do the submission, I will already have 
an authenticated session with the IMAP server where *I* communicate 
all of the relevant authentication information directly to my IMAP 
server in a secure manner. Then my IMAP session will have all of the 
appropriate permissions to all of the relevant portions of my IMAP 
store. The IMAP server will be the thing accessing all of the 
assorted parts and collecting them into a message to pass to the 
SMTP/submit server. Now, the only piece of authentication information 
passed from server to server (if it is even necessary) is the one 
time access for my IMAP server on the submit server to send a 
message. This seems *much* more secure, and in most environments, 
giving the IMAP server free-reign to do submissions without an 
authentication token is already allowed.

>Mobile clients will benefit because they can be deployed without requiring
>a change to the IMAP server.

But it will a require a *huge* change to the security model.

>A mobile client that requires a special IMAP
>server will face a deployment barrier.  An IT department that refuses to
>offer the special IMAP server will effectively block the mobile clients.

The reality is that the main focus of this particular service is 
going to require a number of changes to the IMAP server, so I don't 
see this as any significant issue.

>A large (and growing number) of deployed mobile clients will serve to
>convince IMAP server vendors to support the URL extensions so trust is not
>required.

I am not even convinced as a user that I would want such support in 
my IMAP server due to the security risks.

>Assuming that the security issues in the URL extensions can be 
>resolved (and I think that they can), it will be almost a no-brainer 
>to add them to an IMAP server.

I am far less sanguine about the security considerations.

>Another important detail about the second camp is that it does not 
>depend upon all the data for submit being on one IMAP server.

No, it only requires that all the data for submit be accessible from 
a single authenticated IMAP session.

And I still don't understand, from Mark's original message, why:

>1) Keep IMAP and POP out of the MTA and MSA business.

is an important characteristic of such a system. I would say:

- Keep SMTP out of the mail store business.

is a much more logical principle, and one I think I can justify.

pr
-- 
Pete Resnick <mailto:presnick@qualcomm.com>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Mon Jun  9 16:50:43 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21022
	for <lemonade-archive@odin.ietf.org>; Mon, 9 Jun 2003 16:50:43 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h59KoH003247
	for lemonade-archive@odin.ietf.org; Mon, 9 Jun 2003 16:50:17 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59KoHB03243
	for <lemonade-web-archive@optimus.ietf.org>; Mon, 9 Jun 2003 16:50:17 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21014
	for <lemonade-web-archive@ietf.org>; Mon, 9 Jun 2003 16:50:12 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PTYq-00070S-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 16:48:12 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PTYq-00070P-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 16:48:12 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59Ko1B03234;
	Mon, 9 Jun 2003 16:50:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59KnrB03191
	for <lemonade@optimus.ietf.org>; Mon, 9 Jun 2003 16:49:53 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21001
	for <lemonade@ietf.org>; Mon, 9 Jun 2003 16:49:48 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PTYS-00070G-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 16:47:49 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PTYS-00070D-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 16:47:48 -0400
Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151])
	by ithilien.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h59Knf6I009872;
	Mon, 9 Jun 2003 13:49:42 -0700 (PDT)
Received: from [10.10.0.150] (vpn-10-50-16-23.qualcomm.com [10.50.16.23])
	by crowley.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h59Kmjix012562;
	Mon, 9 Jun 2003 13:48:57 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <a0600140fbb0aa2f280a2@[10.10.0.150]>
In-Reply-To: <Pine.NXT.4.56.0306091132430.11845@Ikkoku-Kan.Panda.COM>
References: <3EE4C3EB.A8A32ABE@sun.com>
 <a06001406bb0a7f742ef1@[10.10.0.150]>
 <Pine.NXT.4.56.0306091132430.11845@Ikkoku-Kan.Panda.COM>
X-Mailer: Eudora for Mac OS X v6.0a
Date: Mon, 9 Jun 2003 16:48:42 -0400
To: Mark Crispin <mrc@CAC.Washington.EDU>,
        Randall Gellens <randy@qualcomm.com>
From: Randall Gellens <randy@qualcomm.com>
Subject: RE: [lemonade] Life on the List, and Vienna
Cc: "Jonathan T. Hawkins" <Jonathan.Hawkins@sun.com>, lemonade@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b25
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

At 12:00 PM -0700 6/9/03, Mark Crispin wrote:

>  You missed an important insight developed in the second camp:
>  	It is NOT necessary for the IMAP server to trust the
>  	Submit server if we create a mechanism (URL or otherwise)
>  	that permits the Submit server to obtain the data it needs
>  	without granting it unnecessary access.
>
>  If this mechanism is based upon IMAP URLs, then we have something that we
>  use today, with *all* IMAP servers.  With traditional IMAP servers, the
>  mobile client would generate a traditional IMAP URL which would require
>  trust of the submit server.  With enhanced IMAP servers, the client would
>  generate a new-type IMAP URL that doesn't require trust.

Thanks for pointing this out, Mark.  I'd forgotten about this.  Can 
you elaborate on this?  I've been meaning to submit a draft outlining 
the two approaches, and would like to include this.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Reporter, n.:
A writer who guesses his way to the truth and dispels it with a
tempest of words.     --Ambrose Bierce, "The Devil's Dictionary"
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Mon Jun  9 17:10:37 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21549
	for <lemonade-archive@odin.ietf.org>; Mon, 9 Jun 2003 17:10:37 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h59LACx05610
	for lemonade-archive@odin.ietf.org; Mon, 9 Jun 2003 17:10:12 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59LACB05607
	for <lemonade-web-archive@optimus.ietf.org>; Mon, 9 Jun 2003 17:10:12 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21530
	for <lemonade-web-archive@ietf.org>; Mon, 9 Jun 2003 17:10:07 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PTs7-000792-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 17:08:07 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PTs6-00078z-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 17:08:06 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59LA1B05566;
	Mon, 9 Jun 2003 17:10:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59L6rB04488
	for <lemonade@optimus.ietf.org>; Mon, 9 Jun 2003 17:06:53 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21471
	for <lemonade@ietf.org>; Mon, 9 Jun 2003 17:06:48 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PTou-00077r-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 17:04:48 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PTot-00077o-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 17:04:47 -0400
Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151])
	by ithilien.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h59L6l6I011105
	for <lemonade@ietf.org>; Mon, 9 Jun 2003 14:06:47 -0700 (PDT)
Received: from [10.10.0.150] (vpn-10-50-16-23.qualcomm.com [10.50.16.23])
	by crowley.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h59L6Bix015757;
	Mon, 9 Jun 2003 14:06:33 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <a06001410bb0aa46ed97d@[10.10.0.150]>
In-Reply-To: <p06001410bb0a97292a4e@[216.43.25.67]>
References: <3EE4C3EB.A8A32ABE@sun.com>
 <a06001406bb0a7f742ef1@[10.10.0.150]>
 <Pine.NXT.4.56.0306091132430.11845@Ikkoku-Kan.Panda.COM>
 <p06001410bb0a97292a4e@[216.43.25.67]>
X-Mailer: Eudora for Mac OS X v6.0a
Date: Mon, 9 Jun 2003 17:06:06 -0400
To: Pete Resnick <presnick@qualcomm.com>, lemonade@ietf.org
From: Randall Gellens <randy@qualcomm.com>
Subject: RE: [lemonade] Life on the List, and Vienna
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b25
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

At 3:36 PM -0500 6/9/03, Pete Resnick wrote:

>>   >		> Need to be careful that all enhancements are done by 
>> using Submit mechanisms, otherwise we end up defining two parallel 
>> submission mechanisms, one for Port 587 and one for IMAP.
>
>  This last one I think is a misrepresentation. It assumes that there 
> are to be mechanisms in common. If (as I think about it) these are 
> two completely separate services, then there is no reason to worry 
> about any parallelisms.

I'm trying to represent both approaches equally and honestly.

Can these remain two separate services?  It seems to me that they 
aren't going to remain separate, or if they do, it will be because we 
end up creating a two-class submission world, where most IMAP clients 
use this new IMAP-based mechanism exclusively, and other clients 
(including POP and those that only send mail) use the SMTP/Submit 
mechanism.  Presumably, we'd end up with some extensions only being 
in one of the two submission mechanisms even though they might be 
useful in the other.  I really don't want that to happen.

>>  Another important detail about the second camp is that it does not 
>> depend upon all the data for submit being on one IMAP server.
>
>  No, it only requires that all the data for submit be accessible 
> from a single authenticated IMAP session.

I read the comment as saying that you could include information from 
an FTP or HTTP URL, for example, besides IMAP.


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
The shepherd drives the wolf from the sheep's throat, for which the
sheep thanks the shepherd as his liberator, while the wolf denounces
him for the same act....  Plainly the sheep and the wolf are not
agreed upon a definition of liberty.               --Abraham Lincoln
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Mon Jun  9 17:11:34 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21600
	for <lemonade-archive@odin.ietf.org>; Mon, 9 Jun 2003 17:11:34 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h59LB9K05661
	for lemonade-archive@odin.ietf.org; Mon, 9 Jun 2003 17:11:09 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59LB9B05658
	for <lemonade-web-archive@optimus.ietf.org>; Mon, 9 Jun 2003 17:11:09 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21574
	for <lemonade-web-archive@ietf.org>; Mon, 9 Jun 2003 17:11:04 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PTt2-00079Y-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 17:09:04 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PTt1-00079V-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 17:09:03 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59LB0B05649;
	Mon, 9 Jun 2003 17:11:00 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59LACB05623
	for <lemonade@optimus.ietf.org>; Mon, 9 Jun 2003 17:10:12 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21529
	for <lemonade@ietf.org>; Mon, 9 Jun 2003 17:10:07 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PTs7-000795-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 17:08:07 -0400
Received: from mxout3.cac.washington.edu ([140.142.32.166])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PTs6-00078y-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 17:08:06 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139])
	by mxout3.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h59L9xSL030455;
	Mon, 9 Jun 2003 14:09:59 -0700
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
	(authenticated bits=0)
	by smtp.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h59L9xQ0011551
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Mon, 9 Jun 2003 14:09:59 -0700
Date: Mon, 9 Jun 2003 14:10:00 -0700 (Pacific Daylight Time)
From: Mark Crispin <MRC@CAC.Washington.EDU>
To: Randall Gellens <randy@qualcomm.com>
cc: "Jonathan T. Hawkins" <Jonathan.Hawkins@sun.com>,
        Nathaniel Borenstein <nsb@guppylake.com>,
        "Alan K. Stebbens" <alan.stebbens@openwave.com>,
        Eric Burger <eburger@snowshore.com>,
        "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: Re: [lemonade] Life on the List, and Vienna
In-Reply-To: <a0600140dbb0a9a3c75d7@[10.10.0.150]>
Message-ID: <Pine.WNT.4.60.0306091407580.924@Tomobiki-Cho.CAC.Washington.EDU>
References: <4A3384433CE2AB46A63468CB207E209D59E327@zoe.office.snowshore.com>
 <639142451.20030609110140@openwave.com> <1055187322.3665.2.camel@localhost.localdomain>
 <3EE4E2B5.49BB0A80@sun.com> <a0600140dbb0a9a3c75d7@[10.10.0.150]>
Organization: Networks & Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Mon, 9 Jun 2003, Randall Gellens wrote:
> I think the suggestion is to use message/external-body instead of
> URLs.  This has been discussed before, since it provides a clear way
> to distinguish between references which are to be expanded and those
> which should remain as-is.

I don't think that "instead" is correct.

As I understood it, MESSAGE/EXTERNAL-BODY would be used as the means in
MIME by which the IMAP access cookie (which we're assuming will be an IMAP
URL) would be conveyed.  I'm surprised that there isn't a URL access-type
defined already; but that is easy to amend.

-- 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 mailnull@www1.ietf.org  Mon Jun  9 17:22:37 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21816
	for <lemonade-archive@odin.ietf.org>; Mon, 9 Jun 2003 17:22:37 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h59LMC006097
	for lemonade-archive@odin.ietf.org; Mon, 9 Jun 2003 17:22:12 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59LMCB06094
	for <lemonade-web-archive@optimus.ietf.org>; Mon, 9 Jun 2003 17:22:12 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21809
	for <lemonade-web-archive@ietf.org>; Mon, 9 Jun 2003 17:22:06 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PU3j-0007D9-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 17:20:07 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PU3i-0007D6-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 17:20:06 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59LM1B06078;
	Mon, 9 Jun 2003 17:22:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59LLVB06052
	for <lemonade@optimus.ietf.org>; Mon, 9 Jun 2003 17:21:31 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21785
	for <lemonade@ietf.org>; Mon, 9 Jun 2003 17:21:26 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PU34-0007Cl-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 17:19:26 -0400
Received: from mxout2.cac.washington.edu ([140.142.33.4])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PU34-0007Ci-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 17:19:26 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139])
	by mxout2.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h59LLQ5R022970;
	Mon, 9 Jun 2003 14:21:26 -0700
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
	(authenticated bits=0)
	by smtp.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h59LLQQ0012373
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Mon, 9 Jun 2003 14:21:26 -0700
Date: Mon, 9 Jun 2003 14:21:27 -0700 (Pacific Daylight Time)
From: Mark Crispin <MRC@CAC.Washington.EDU>
To: Randall Gellens <randy@qualcomm.com>
cc: Pete Resnick <presnick@qualcomm.com>, lemonade@ietf.org
Subject: RE: [lemonade] Life on the List, and Vienna
In-Reply-To: <a06001410bb0aa46ed97d@[10.10.0.150]>
Message-ID: <Pine.WNT.4.60.0306091411240.924@Tomobiki-Cho.CAC.Washington.EDU>
References: <3EE4C3EB.A8A32ABE@sun.com> <a06001406bb0a7f742ef1@[10.10.0.150]>
 <Pine.NXT.4.56.0306091132430.11845@Ikkoku-Kan.Panda.COM>
 <p06001410bb0a97292a4e@[216.43.25.67]> <a06001410bb0aa46ed97d@[10.10.0.150]>
Organization: Networks & Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Mon, 9 Jun 2003, Randall Gellens wrote:
> Can these remain two separate services?  It seems to me that they
> aren't going to remain separate, or if they do, it will be because we
> end up creating a two-class submission world, where most IMAP clients
> use this new IMAP-based mechanism exclusively, and other clients
> (including POP and those that only send mail) use the SMTP/Submit
> mechanism.  Presumably, we'd end up with some extensions only being
> in one of the two submission mechanisms even though they might be
> useful in the other.  I really don't want that to happen.

That will inevitably happen if submit is put into IMAP.

> >>  Another important detail about the second camp is that it does not
> >> depend upon all the data for submit being on one IMAP server.
> >  No, it only requires that all the data for submit be accessible
> > from a single authenticated IMAP session.
> I read the comment as saying that you could include information from
> an FTP or HTTP URL, for example, besides IMAP.

Your reading is correct; you can include information from other kinds of
URLs.

Nevertheless, the requirement that all the data for submit be accessible
form a single authenticated IMAP session effectively requires that all the
data for submit be on one IMAP server (leaving aside silliness like
requiring that IMAP servers have built-in IMAP clients).

-- 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 mailnull@www1.ietf.org  Mon Jun  9 17:33:37 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22060
	for <lemonade-archive@odin.ietf.org>; Mon, 9 Jun 2003 17:33:37 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h59LXCT06521
	for lemonade-archive@odin.ietf.org; Mon, 9 Jun 2003 17:33:12 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59LXCB06518
	for <lemonade-web-archive@optimus.ietf.org>; Mon, 9 Jun 2003 17:33:12 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22053
	for <lemonade-web-archive@ietf.org>; Mon, 9 Jun 2003 17:33:06 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PUEN-0007Ga-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 17:31:07 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PUEM-0007GW-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 17:31:06 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59LX2B06496;
	Mon, 9 Jun 2003 17:33:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59LW5B06457
	for <lemonade@optimus.ietf.org>; Mon, 9 Jun 2003 17:32:05 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22031
	for <lemonade@ietf.org>; Mon, 9 Jun 2003 17:31:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PUDI-0007GT-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 17:30:00 -0400
Received: from darius.cyrusoft.com ([63.163.82.2])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PUDG-0007GP-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 17:29:59 -0400
Received: from socrates.cyrusoft.com (localhost [127.0.0.1])
	by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id RAA25809;
	Mon, 9 Jun 2003 17:28:10 -0400 (EDT)
Date: Mon, 09 Jun 2003 17:31:48 -0400
From: Cyrus Daboo <daboo@cyrusoft.com>
To: Mark Crispin <MRC@cac.washington.edu>,
        Randall Gellens <randy@qualcomm.com>
cc: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: Re: [lemonade] Life on the List, and Vienna
Message-ID: <2147483647.1055179908@socrates.cyrusoft.com>
In-Reply-To: <Pine.WNT.4.60.0306091407580.924@Tomobiki-Cho.CAC.Washington.EDU>
References: <4A3384433CE2AB46A63468CB207E209D59E327@zoe.office.snowshore.com>
  <639142451.20030609110140@openwave.com>
 <1055187322.3665.2.camel@localhost.localdomain> <3EE4E2B5.49BB0A80@sun.com>
 <a0600140dbb0a9a3c75d7@[10.10.0.150]>
 <Pine.WNT.4.60.0306091407580.924@Tomobiki-Cho.CAC.Washington.EDU>
X-Mailer: Mulberry/3.1.0b1 (Mac OS/PPC)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi Mark,

--On Monday, June 9, 2003 2:10 PM -0700 Mark Crispin 
<MRC@cac.washington.edu> wrote:

| As I understood it, MESSAGE/EXTERNAL-BODY would be used as the means in
| MIME by which the IMAP access cookie (which we're assuming will be an IMAP
| URL) would be conveyed.  I'm surprised that there isn't a URL access-type
| defined already; but that is easy to amend.

There is:

RFC2017: 'Definition of the URL MIME External-Body Access-Type'.

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



From mailnull@www1.ietf.org  Mon Jun  9 17:45:35 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22179
	for <lemonade-archive@odin.ietf.org>; Mon, 9 Jun 2003 17:45:35 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h59LjBj07664
	for lemonade-archive@odin.ietf.org; Mon, 9 Jun 2003 17:45:11 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59LjAB07661
	for <lemonade-web-archive@optimus.ietf.org>; Mon, 9 Jun 2003 17:45:10 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22176
	for <lemonade-web-archive@ietf.org>; Mon, 9 Jun 2003 17:45:05 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PUPx-0007Ix-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 17:43:05 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PUPx-0007Iu-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 17:43:05 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59Lj5B07652;
	Mon, 9 Jun 2003 17:45:05 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59LicB07623
	for <lemonade@optimus.ietf.org>; Mon, 9 Jun 2003 17:44:38 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22154
	for <lemonade@ietf.org>; Mon, 9 Jun 2003 17:44:32 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PUPR-0007Ih-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 17:42:33 -0400
Received: from inet-consulting.com ([4.23.9.166] helo=royer.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PUPP-0007Ie-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 17:42:31 -0400
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h59LiIbt020352
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <lemonade@ietf.org>; Mon, 9 Jun 2003 14:44:27 -0700
Message-ID: <3EE4FFA0.9060001@Royer.com>
Date: Mon, 09 Jun 2003 15:44:00 -0600
From: Doug Royer <Doug@Royer.com>
Reply-To: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: Re: [lemonade] Life on the List, and Vienna
References: <4A3384433CE2AB46A63468CB207E209D59E327@zoe.office.snowshore.com> <639142451.20030609110140@openwave.com> <1055187322.3665.2.camel@localhost.localdomain> <3EE4E2B5.49BB0A80@sun.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020804040700030604070209"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This is a cryptographically signed message in MIME format.

--------------ms020804040700030604070209
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Jonathan T. Hawkins wrote:
> At the moment, the embedded URLs are pulled together via the MUA, the IMAP
> client.  The proposal is for SMTP MTA side composition.

How is that different than having the gateway do the message/external-body
processing? If the CELL-MUA generates a MIME message that contains an
external body part. Then the CELL-MUA's MTA (is gateway) ~could~ be written
so that it expands/replaces the external body part into the message that
is sent.

And if there is going to be MTA side processing of messages, then
if done my MIME type or URL should make no difference with respect
to security.


> Jonathan
> 
> Nathaniel Borenstein wrote:
> 
> 
>>On Mon, 2003-06-09 at 14:01, Alan K. Stebbens wrote:
>>
>>
>>>And, IMHO, the Path of Least Resistance would be to introduce a new SMTP
>>>command, say, ATTACH, by which the contents addressed by a URL would be
>>>inserted, as an additional MIME object, into the outgoing message.
>>
>>Pardon me if I'm coming into this discussion a bit late, but couldn't
>>you accomplish the same thing by defining this as the default behavior
>>of a mobile messaging gateway that encounters a MIME type of
>>message/external-body?  I'm not clear why you can't use that existing
>>MIME type.  -- Nathaniel

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  Doug@Royer.com                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

--------------ms020804040700030604070209
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC
A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j
cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB
MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T
BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN
VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre
qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+
5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA
MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg
TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD
QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx
ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz
IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq
hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34
1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA
gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK
YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd
SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC
AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF
BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl
cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl
IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs
MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq
1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2
TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail
MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE
AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO
b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG
MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD
VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV
BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv
43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y
lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP
D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn
0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK
bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg
hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT
IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI
AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t
L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk
OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW
yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1
MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl
ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MDkyMTQ0MDFaMCMGCSqGSIb3DQEJBDEWBBTy
u2ZxCxJrrbQAYf47Xx0J3UMShDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL
KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAUllAoXnar+V3
0Ngm0m5S5wxS7RwuZvgXPtEin1+piu3AMahwBgvx3bwouIKFW6AESbp77DAlM6qCjCrIxlej
q8PCrbqjRoQb+FboVDxqLgCPaNRxK+V4a/p27N/BamlPWYZLuUaZ01BzcDVBFdyK43Paz+Gw
NBlvAch4KIbe0JjW+s9qtlBhQf0rjNP9qu/zR0ufud1XqHL4iAk/2y8psrCatOhBxKWeKBLS
F3vQyFkGpy4K0ZGnPSKdN9ULrUqGH3d2eNkQNuznYU/PajVZRvkGvS4Mu0DIwaH2mu9L5sxH
InzbG0LNSTxFXk0x2AqWgiS+P1ue9vPlfLYZBJGtygAAAAAAAA==
--------------ms020804040700030604070209--

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



From mailnull@www1.ietf.org  Mon Jun  9 18:13:47 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23550
	for <lemonade-archive@odin.ietf.org>; Mon, 9 Jun 2003 18:13:47 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h59MDNg09436
	for lemonade-archive@odin.ietf.org; Mon, 9 Jun 2003 18:13:23 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59MDNB09433
	for <lemonade-web-archive@optimus.ietf.org>; Mon, 9 Jun 2003 18:13:23 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23507
	for <lemonade-web-archive@ietf.org>; Mon, 9 Jun 2003 18:13:17 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PUrF-0007QT-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 18:11:17 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PUrF-0007QP-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 18:11:17 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59MD9B09423;
	Mon, 9 Jun 2003 18:13:09 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59MCpB09405
	for <lemonade@optimus.ietf.org>; Mon, 9 Jun 2003 18:12:51 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23458
	for <lemonade@ietf.org>; Mon, 9 Jun 2003 18:12:44 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PUqj-0007QM-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 18:10:45 -0400
Received: from oe-im2pub.managedmail.com ([206.46.164.53] helo=oe-im2.bizmailsrvcs.net)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PUqi-0007QC-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 18:10:44 -0400
Received: from oe-ismta2.bizmailsrvcs.net ([206.46.164.29])
          by oe-im2.bizmailsrvcs.net
          (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP
          id <20030609221216.FHCM7174.oe-im2.bizmailsrvcs.net@oe-ismta2.bizmailsrvcs.net>;
          Mon, 9 Jun 2003 17:12:16 -0500
Received: from AKSTEBBENS.mshome.net ([64.14.194.172])
          by oe-ismta2.bizmailsrvcs.net
          (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP
          id <20030609221215.BHGW8315.oe-ismta2.bizmailsrvcs.net@AKSTEBBENS.mshome.net>;
          Mon, 9 Jun 2003 17:12:15 -0500
Date: Mon, 9 Jun 2003 15:12:14 -0700
From: "Alan K. Stebbens" <alan.stebbens@openwave.com>
X-Mailer: The Bat! (v1.62r) Personal
Reply-To: "Alan K. Stebbens" <alan.stebbens@openwave.com>
Organization: Openwave Systems, Inc.
X-Priority: 3 (Normal)
Message-ID: <172316146.20030609151214@openwave.com>
To: Mark Crispin <MRC@CAC.Washington.EDU>
CC: Randall Gellens <randy@qualcomm.com>,
        "Jonathan T. Hawkins" <Jonathan.Hawkins@sun.com>,
        Nathaniel Borenstein <nsb@guppylake.com>,
        Eric Burger <eburger@snowshore.com>,
        "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: Re: [lemonade] Life on the List, and Vienna
In-Reply-To: <Pine.WNT.4.60.0306091407580.924@Tomobiki-Cho.CAC.Washington.EDU>
References: <4A3384433CE2AB46A63468CB207E209D59E327@zoe.office.snowshore.com>
 <639142451.20030609110140@openwave.com>
 <1055187322.3665.2.camel@localhost.localdomain> <3EE4E2B5.49BB0A80@sun.com>
 <a0600140dbb0a9a3c75d7@[10.10.0.150]>
 <Pine.WNT.4.60.0306091407580.924@Tomobiki-Cho.CAC.Washington.EDU>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

MC> On Mon, 9 Jun 2003, Randall Gellens wrote:
>> I think the suggestion is to use message/external-body instead of
>> URLs.  This has been discussed before, since it provides a clear way
>> to distinguish between references which are to be expanded and those
>> which should remain as-is.

MC> I don't think that "instead" is correct.

MC> As I understood it, MESSAGE/EXTERNAL-BODY would be used as the means in
MC> MIME by which the IMAP access cookie (which we're assuming will be an IMAP
MC> URL) would be conveyed.  I'm surprised that there isn't a URL access-type
MC> defined already; but that is easy to amend.

The problem is not a specific type/subtype, but what the SMTP server does
with it.

Currently, most SMTP servers do not interpolate (dereference) embedded
links; they just pass them along.

The problem with the current functionality is that the implicit,
network-based authentication enjoyed by an MTA that is a "companion" to an
IMAP server, is not likely to be available to the destination SMTP server
which ultimately delivers the message to the recipient.  Thus, the
de-referencing of any IMAP URLs needs to be done by the originating SMTP
server, in order to realize the benefit of shared network-based
authentication.

Therefore, a new type/subtype, perhaps a qualifier to one, or, even a new
SMTP command (ATTACH?) needs to be defined to trigger the dereferencing of
the URLs.

-- 
Best regards,
 Alan K. Stebbens <alan.stebbens@openwave.com>
 Principal Product Technologist, Messaging
 Openwave Systems, Inc.
 Cell: +1.805.886.8886  Voice/Fax: +1.866.579.0801
 Desk: +1.805.884.3162
 YIM/MSN: alan_stebbens  ICQ: 51361674  AIM: akstebbens   

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



From mailnull@www1.ietf.org  Mon Jun  9 18:20:30 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23809
	for <lemonade-archive@odin.ietf.org>; Mon, 9 Jun 2003 18:20:30 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h59MK6P09707
	for lemonade-archive@odin.ietf.org; Mon, 9 Jun 2003 18:20:06 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59MK6B09704
	for <lemonade-web-archive@optimus.ietf.org>; Mon, 9 Jun 2003 18:20:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23800
	for <lemonade-web-archive@ietf.org>; Mon, 9 Jun 2003 18:19:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PUxk-0007Ra-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 18:18:00 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PUxj-0007RV-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 18:17:59 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59MK2B09687;
	Mon, 9 Jun 2003 18:20:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59MJIB09637
	for <lemonade@optimus.ietf.org>; Mon, 9 Jun 2003 18:19:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23786
	for <lemonade@ietf.org>; Mon, 9 Jun 2003 18:19:11 -0400 (EDT)
From: william@elan.net
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PUwx-0007RH-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 18:17:11 -0400
Received: from sokol.elan.net ([216.151.192.200])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PUwx-0007R9-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 18:17:11 -0400
Received: from sokol.elan.net (localhost.localdomain [127.0.0.1])
	by sokol.elan.net (8.12.5/8.12.5) with ESMTP id h59JXBII031598
	for <lemonade@ietf.org>; Mon, 9 Jun 2003 12:33:11 -0700
Received: from localhost (william@localhost)
	by sokol.elan.net (8.12.5/8.12.5/Submit) with ESMTP id h59JXB1j031594
	for <lemonade@ietf.org>; Mon, 9 Jun 2003 12:33:11 -0700
X-Authentication-Warning: sokol.elan.net: william owned process doing -bs
Date: Mon, 9 Jun 2003 12:33:11 -0700 (PDT)
To: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: RE: [lemonade] Life on the List, and Vienna
In-Reply-To: <Pine.NXT.4.56.0306081829010.11845@Ikkoku-Kan.Panda.COM>
Message-ID: <Pine.LNX.4.44.0306091218180.16563-100000@sokol.elan.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Sun, 8 Jun 2003, Mark Crispin wrote:

> I recommend a mechanism which I brought up briefly (albeit was shouted
> down due to a misunderstanding of what I was going to say) at the last
> IETF:
> 	We need a mechanism (ala IMAP URL) which, when presented
> 	to an IMAP server, would deliver a particular data item
> 	from a particular mailbox owned by a particular user
> 	*without* providing access to any other data in the
> 	mailbox.
> 
> This mechanism would be used by the submission server (which some of us
> want to be a different machine from the IMAP servers!) to obtain the data
> from the IMAP server.
The above mechanism would work, however it would be quite complicated still.

The particular problem is that its quite often not the entire email you 
want to forward but only part of it and that can be very much inside your 
own reply email with one part of original email, followed by reply text, 
followed by another part, etc. etc.  

This gets very complicated if we do it by URL:
 1. We have to allow for email on IMAP server to be broken into multiple 
    small parts and store each part with special security settings (only 
    for submit server use). These parts have to be deleted after submission.
 2. We have to allow submit server to not only add particular headers but 
    create new body for the email - i.e. it takes part of the text sent to 
    it, looks at particular references to other parts of the text adds it 
    all up and creates new mime body. Not an easy process to describe - I 
    see inventions of new MIME types, like "Partial-email-text" (what if  
    its not a text???) and "Partial-email-imap-reference-url". And then 
    submit server has to deal with cases of content-type being different
    in original email (at IMAP server) and new parts being sent to it.

In the end I think it would be better (and possibly even less complicated?)
to allow editing of email within IMAP itself, so that there is entire 
email body already ready for submission.  After this it does not matter if 
submit process is called by end-user and refernces this already-made body
(and actual headers are added by submit) or if IMAP calls submit process 
itself.

And having email created entirely within IMAP framework does have its
advantages in the practical use as it would not be necessary to create 
such a complicated authorization system and since in real-world right now 
firewalls often do not filter IMAP but they do filter SMTP and SMTP-submit.

---
William Leibzon
Elan Communications Inc. 
william@elan.net

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



From mailnull@www1.ietf.org  Mon Jun  9 18:23:35 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23859
	for <lemonade-archive@odin.ietf.org>; Mon, 9 Jun 2003 18:23:35 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h59MNBD09836
	for lemonade-archive@odin.ietf.org; Mon, 9 Jun 2003 18:23:11 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59MNBB09833
	for <lemonade-web-archive@optimus.ietf.org>; Mon, 9 Jun 2003 18:23:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23855
	for <lemonade-web-archive@ietf.org>; Mon, 9 Jun 2003 18:23:04 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PV0j-0007SQ-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 18:21:05 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PV0i-0007SN-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 18:21:04 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59MN0B09811;
	Mon, 9 Jun 2003 18:23:00 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59MMjB09773
	for <lemonade@optimus.ietf.org>; Mon, 9 Jun 2003 18:22:45 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23842
	for <lemonade@ietf.org>; Mon, 9 Jun 2003 18:22:38 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PV0J-0007SE-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 18:20:39 -0400
Received: from mxout1.cac.washington.edu ([140.142.32.134])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PV0I-0007SB-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 18:20:38 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9])
	by mxout1.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h59MMcRG008813;
	Mon, 9 Jun 2003 15:22:38 -0700
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
	(authenticated bits=0)
	by smtp.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h59MMc7k013482
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Mon, 9 Jun 2003 15:22:38 -0700
Date: Mon, 9 Jun 2003 15:22:39 -0700 (Pacific Daylight Time)
From: Mark Crispin <MRC@CAC.Washington.EDU>
To: Pete Resnick <presnick@qualcomm.com>
cc: lemonade@ietf.org
Subject: RE: [lemonade] Life on the List, and Vienna
In-Reply-To: <p06001410bb0a97292a4e@[216.43.25.67]>
Message-ID: <Pine.WNT.4.60.0306091433020.924@Tomobiki-Cho.CAC.Washington.EDU>
References: <3EE4C3EB.A8A32ABE@sun.com> <a06001406bb0a7f742ef1@[10.10.0.150]>
 <Pine.NXT.4.56.0306091132430.11845@Ikkoku-Kan.Panda.COM>
 <p06001410bb0a97292a4e@[216.43.25.67]>
Organization: Networks & Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Mon, 9 Jun 2003, Pete Resnick wrote:
> Another advantage is, "Does not require a submit server to know
> anything about MIME structure".

A submit service is already required to understand headers and MIME, since
otherwise it won't be able to perform the transforms required by 8-bit.

This "advantage" therefore does not buy anything.

> Currently, an IMAP server needs to be
> able to parse MIME messages anyway.

An IMAP server is required to parse MIME as specified for an MUA.  A
submit service has substantial additional requirements which IMAP does not
have.

> Current submit servers are often
> strictly 822 entities, and sometimes not even that smart.

A strictly 822 entity does not offer 8-bit, which I was hearing was an
important requirement for lemonade.

I see no reason why to dump substantial additional requirements into IMAP
servers in order to avoid upgrading submit servers that are already
provably inadequate for the task.

> I don't see
> why we would dump more smarts into a submit server rather than
> including a single additional piece of functionality into an IMAP
> server.

If a submit server does 8-bit, either the smarts are there or it is
non-compliant.

> >		> Need to be careful that all enhancements are done
> >by using Submit mechanisms, otherwise we end up defining two
> >parallel submission mechanisms, one for Port 587 and one for IMAP.
> This last one I think is a misrepresentation. It assumes that there
> are to be mechanisms in common. If (as I think about it) these are
> two completely separate services, then there is no reason to worry
> about any parallelisms.

Huh??  You are claiming that, in spite of the fact that there are going to
be two means of doing submission, that there will not be any parallelisms
between the two???


> This is the one that scares the daylights out of me. Right now, my
> IMAP server has all of my mail data and access to my IMAP server
> means access to all of that data.

Yes.  And how would you like an IMAP server with all that power being made
to do processing and reformatting of submit requests?  This opens a vast
hole that you can drive a truck through!

> The suggestion for the submit model is to invent a mechanism that has
> access to my IMAP store. You want to be able to grant it access to
> the particular MIME parts needed to compose this message, and then
> only given it access for a small period of time.

Yes.  This would not be required, but would be highly desirable.  The
submit process is denied access to any other data.

> I am very worried about the
> overhead to authenticate the submit server.

This is minimal; the token itself carries that.

What about the overhead placed upon the IMAP server to process submits?

> I am very worried about
> something getting it's mitts on the token I'm going to have to pass
> to the submit server that it's going to have to pass to my IMAP
> server.

This is easily solved.  It isn't as if we don't have the intelligence to
work how a way of generating tokens that only a particular entity can use.

Aren't you worried about the IMAP server being compelled to massage data
in ways that no IMAP server has ever done before?

> I am even worried about the fact that I have to pass *any*
> information to my submit server to allow it to get stuff from my IMAP
> server. I don't want my submit server to have *any* information that
> will allow it to access parts of my IMAP store. This sounds like a
> big gaping security hole.

So, to solve this security hole, you propose to pass *all* of your
information to your submit server to allow it to get stuff from your IMAP
server.  You propose to provide your submit server with information that
will grant it *full* access to your entire IMAP store -- because you want
the IMAP server to *be* the submit server!

> In the case of using IMAP to do the submission, I will already have
> an authenticated session with the IMAP server where *I* communicate
> all of the relevant authentication information directly to my IMAP
> server in a secure manner. Then my IMAP session will have all of the
> appropriate permissions to all of the relevant portions of my IMAP
> store. The IMAP server will be the thing accessing all of the
> assorted parts and collecting them into a message to pass to the
> SMTP/submit server.

This in effect makes the IMAP server be the submit server.  Put another
way, a separate "SMTP/submit server" in this model is a completely
extraneous step with no apparent purpose.

> >Mobile clients will benefit because they can be deployed without requiring
> >a change to the IMAP server.
> But it will a require a *huge* change to the security model.

Not at all.  As far as the client is concerned, it's just URLs.

> The reality is that the main focus of this particular service is
> going to require a number of changes to the IMAP server, so I don't
> see this as any significant issue.

Wrong.

It can be deployed with *no* changes to any IMAP server, albeit with the
disadvantage that you'll have to give IMAP server authorization
credentials to the submit server.

The only enhancements to the IMAP server would be: (1) a command to
generate the token (URL or otherwise), and a SASL mechanism to return the
data given the token.

> >A large (and growing number) of deployed mobile clients will serve to
> >convince IMAP server vendors to support the URL extensions so trust is not
> >required.
> I am not even convinced as a user that I would want such support in
> my IMAP server due to the security risks.

I am not convinced as an IMAP server implementor that I would want submit
code (not to mention SMTP client code and outgoing SMTP connections) in
my IMAP server due to the security risks.

> >Assuming that the security issues in the URL extensions can be
> >resolved (and I think that they can), it will be almost a no-brainer
> >to add them to an IMAP server.
> I am far less sanguine about the security considerations.

I am horrified by the security considerations of making an IMAP server do
submit.

> >Another important detail about the second camp is that it does not
> >depend upon all the data for submit being on one IMAP server.
> No, it only requires that all the data for submit be accessible from
> a single authenticated IMAP session.

I debunked this statement in another message.

> And I still don't understand, from Mark's original message, why:
> >1) Keep IMAP and POP out of the MTA and MSA business.
> is an important characteristic of such a system.

An IMAP server currently does nothing more than access data from a mail
store, and export that data in various ways to an IMAP client.

Your proposal would, for the first time, require that an IMAP server be in
the business of building RFC 2822/MIME compliant mesages from input which
is not strictly compliant, including assembly of those messages with data
from the mail store.  It would also require that the IMAP server contain
an SMTP client, to pass on the message to the MTA.

There is also another security hole in your model that I just realized.
Any submit request from the mobile client which contains incoming message
data could contain IMAP-submit pointers.  Oops.  The client would have to
be extremely careful to scan for this, and the server would also have to
have to be careful.

This isn't a problem with my counter-proposal, since the pointers would
carry access-authorization data.  Even if a bad guy tricked you into
sending along a pointer of his choosing, the pointer won't work.

> - Keep SMTP out of the mail store business.
> is a much more logical principle, and one I think I can justify.

SMTP is not doing mail store.  Nor is submit.  It is merely using
the existing external-body mechanism to obtain data from a mail store.

-- 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 mailnull@www1.ietf.org  Mon Jun  9 18:27:29 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24092
	for <lemonade-archive@odin.ietf.org>; Mon, 9 Jun 2003 18:27:29 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h59MR6710000
	for lemonade-archive@odin.ietf.org; Mon, 9 Jun 2003 18:27:06 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59MR6B09997
	for <lemonade-web-archive@optimus.ietf.org>; Mon, 9 Jun 2003 18:27:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24078
	for <lemonade-web-archive@ietf.org>; Mon, 9 Jun 2003 18:26:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PV4V-0007W0-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 18:24:59 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PV4V-0007Vx-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 18:24:59 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59MR2B09988;
	Mon, 9 Jun 2003 18:27:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59MQ5B09966
	for <lemonade@optimus.ietf.org>; Mon, 9 Jun 2003 18:26:05 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23977
	for <lemonade@ietf.org>; Mon, 9 Jun 2003 18:25:58 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PV3X-0007To-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 18:23:59 -0400
Received: from mxout2.cac.washington.edu ([140.142.33.4])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PV3W-0007Ti-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 18:23:58 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9])
	by mxout2.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h59MPs5R003167;
	Mon, 9 Jun 2003 15:25:54 -0700
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
	(authenticated bits=0)
	by smtp.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h59MPs7k013678
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Mon, 9 Jun 2003 15:25:54 -0700
Date: Mon, 9 Jun 2003 15:25:55 -0700 (Pacific Daylight Time)
From: Mark Crispin <MRC@CAC.Washington.EDU>
To: william@elan.net
cc: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: RE: [lemonade] Life on the List, and Vienna
In-Reply-To: <Pine.LNX.4.44.0306091218180.16563-100000@sokol.elan.net>
Message-ID: <Pine.WNT.4.60.0306091523080.924@Tomobiki-Cho.CAC.Washington.EDU>
References: <Pine.LNX.4.44.0306091218180.16563-100000@sokol.elan.net>
Organization: Networks & Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Mon, 9 Jun 2003 william@elan.net wrote:
> The particular problem is that its quite often not the entire email you
> want to forward but only part of it and that can be very much inside your
> own reply email with one part of original email, followed by reply text,
> followed by another part, etc. etc.

IMAP already solves this.  It has partial message operations.

>  1. We have to allow for email on IMAP server to be broken into multiple
>     small parts and store each part with special security settings (only
>     for submit server use). These parts have to be deleted after submission.

Since IMAP has partial message operations, there is no need to do this
breaking or subsequent deletion.  The capability is already there.

> And having email created entirely within IMAP framework does have its
> advantages in the practical use as it would not be necessary to create
> such a complicated authorization system

But you would have to create an extremely complicated editing system.
Editing is more complicated than authorization.

> and since in real-world right now
> firewalls often do not filter IMAP but they do filter SMTP and SMTP-submit.

As soon as spammers work out how to spam with IMAP, you can be confident
that we'll start seeing blocking of IMAP ports too.

-- 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 mailnull@www1.ietf.org  Mon Jun  9 18:28:34 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24161
	for <lemonade-archive@odin.ietf.org>; Mon, 9 Jun 2003 18:28:34 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h59MSBk10089
	for lemonade-archive@odin.ietf.org; Mon, 9 Jun 2003 18:28:11 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59MSAB10086
	for <lemonade-web-archive@optimus.ietf.org>; Mon, 9 Jun 2003 18:28:10 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24146
	for <lemonade-web-archive@ietf.org>; Mon, 9 Jun 2003 18:28:03 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PV5Y-0007Wr-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 18:26:04 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PV5Y-0007Wo-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 18:26:04 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59MS0B10049;
	Mon, 9 Jun 2003 18:28:00 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59MRuB10030
	for <lemonade@optimus.ietf.org>; Mon, 9 Jun 2003 18:27:56 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24126
	for <lemonade@ietf.org>; Mon, 9 Jun 2003 18:27:49 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PV5J-0007WG-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 18:25:49 -0400
Received: from inet-consulting.com ([4.23.9.166] helo=royer.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PV5I-0007WD-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 18:25:48 -0400
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h59MRibt020707
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <lemonade@ietf.org>; Mon, 9 Jun 2003 15:27:48 -0700
Message-ID: <3EE509D4.3040109@Royer.com>
Date: Mon, 09 Jun 2003 16:27:32 -0600
From: Doug Royer <Doug@Royer.com>
Reply-To: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
References: <4A3384433CE2AB46A63468CB207E209D59E327@zoe.office.snowshore.com> <639142451.20030609110140@openwave.com> <1055187322.3665.2.camel@localhost.localdomain> <3EE4E2B5.49BB0A80@sun.com> <a0600140dbb0a9a3c75d7@[10.10.0.150]> <Pine.WNT.4.60.0306091407580.924@Tomobiki-Cho.CAC.Washington.EDU> <172316146.20030609151214@openwave.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090809070803050302070400"
Subject: [lemonade] Re: Just 'ATTACH'
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This is a cryptographically signed message in MIME format.

--------------ms090809070803050302070400
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Alan K. Stebbens wrote:

> Therefore, a new type/subtype, perhaps a qualifier to one, or, even a new
> SMTP command (ATTACH?) needs to be defined to trigger the dereferencing of
> the URLs.

SMTP commands can not be embedded into the DATA stream. So I do not think
an ATTACH SMTP command will work. Although most MUAs display 'attachments'
in a separate pane, they are inline in just about any random order.

A simple example would be a reply to a long message where the person
replying wished to include the entire text of the original:

	users comments
		forwared-text expanded my MTA
	users signature

You could not insert an ATTACH or any other command into the SMTP/DATA
stream. It would have to be some kind of URL that the MTA recognized.

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  Doug@Royer.com                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

--------------ms090809070803050302070400
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC
A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j
cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB
MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T
BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN
VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre
qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+
5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA
MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg
TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD
QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx
ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz
IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq
hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34
1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA
gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK
YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd
SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC
AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF
BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl
cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl
IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs
MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq
1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2
TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail
MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE
AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO
b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG
MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD
VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV
BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv
43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y
lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP
D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn
0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK
bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg
hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT
IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI
AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t
L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk
OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW
yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1
MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl
ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MDkyMjI3MzJaMCMGCSqGSIb3DQEJBDEWBBQK
dLvr7XrAY/Ti1chUstvYx21BBDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL
KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAf12e+5vgRJ4a
MEL9+KVa4jG5Szeuh7EgUxVv9cbLiLEd8FDx2zbsJO5qPcbeZFjDEkYqNPxRpO6PHih7A7tH
Iz0q66BZcc50KBscdTYh1CPf3H8LgUUj8oY3c5chtAbKzofK+Q1Q16PQwEvOxYAQqAGDlyRg
OwR9WExgO+MSF9c1Ol7/iQhzwjI45gMH6+HJWBXCm6LRt4fNgWVQRiv+x+mUPllroFrMxER1
e1JboAL+5AOyVsIhD0Bx1i7Q52C1wq7HwisX1nuNx5pB95wULM8smu8Ne1qGvIKTDAZ7jiEO
yowQlSjYfeX6TAeeRlUknDVtKEy1sPQWIIVn2ggv6QAAAAAAAA==
--------------ms090809070803050302070400--

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



From mailnull@www1.ietf.org  Mon Jun  9 18:49:30 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24582
	for <lemonade-archive@odin.ietf.org>; Mon, 9 Jun 2003 18:49:29 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h59Mn7W11636
	for lemonade-archive@odin.ietf.org; Mon, 9 Jun 2003 18:49:07 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59Mn6B11633
	for <lemonade-web-archive@optimus.ietf.org>; Mon, 9 Jun 2003 18:49:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24579
	for <lemonade-web-archive@ietf.org>; Mon, 9 Jun 2003 18:48:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PVPo-0007bz-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 18:47:00 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PVPn-0007bw-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 18:46:59 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59Mn1B11617;
	Mon, 9 Jun 2003 18:49:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59Mm0B11571
	for <lemonade@optimus.ietf.org>; Mon, 9 Jun 2003 18:48:00 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24521
	for <lemonade@ietf.org>; Mon, 9 Jun 2003 18:47:53 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PVOk-0007bH-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 18:45:54 -0400
Received: from inet-consulting.com ([4.23.9.166] helo=royer.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PVOi-0007bA-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 18:45:52 -0400
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h59Mlmbt020868
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <lemonade@ietf.org>; Mon, 9 Jun 2003 15:47:52 -0700
Message-ID: <3EE50E89.8040509@Royer.com>
Date: Mon, 09 Jun 2003 16:47:37 -0600
From: Doug Royer <Doug@Royer.com>
Reply-To: lemonade@ietf.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: lemonade@ietf.org
References: <3EE4C3EB.A8A32ABE@sun.com> <a06001406bb0a7f742ef1@[10.10.0.150]> <Pine.NXT.4.56.0306091132430.11845@Ikkoku-Kan.Panda.COM> <p06001410bb0a97292a4e@[216.43.25.67]> <Pine.WNT.4.60.0306091433020.924@Tomobiki-Cho.CAC.Washington.EDU>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030407040902090302050401"
Subject: [lemonade] Re: IMAP as a submit server
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This is a cryptographically signed message in MIME format.

--------------ms030407040902090302050401
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


I really do not understand your points below (I hope I did not cut
out any thing important). It seems to me as if your points are
in conflict with each other.

If I give a submit server my authentication credentials, then it is
in effect an IMAP client - with FULL IMAP access anyway. Are you
proposing that each submission be given a unique authentication so
that the IMAP server knows to give 'this' and only 'this' message
or meassage-body-part to 'that' IMAP client?

In order for the IMAP server to know that only this MIME body part
should be given to 'this' submit server for the purpose of doing
an in-line expansion would require the IMAP client tell the IMAP server
each and every time that 'this' MIME object can be shared.
This looks like a lot of round trips and complication to me.

It seems to me that if an IMAP server were also a submit server
then it would reduce any cross-vendor submit/imap-server security
holes. And it would reduce the ACLs (or whatever is used) control
complexities which again I think would reduce the security holes.

Mark Crispin wrote:

> ...
> 
>>This is the one that scares the daylights out of me. Right now, my
>>IMAP server has all of my mail data and access to my IMAP server
>>means access to all of that data.
> 
> 
> Yes.  And how would you like an IMAP server with all that power being made
> to do processing and reformatting of submit requests?  This opens a vast
> hole that you can drive a truck through!
> 
> 
>>The suggestion for the submit model is to invent a mechanism that has
>>access to my IMAP store. You want to be able to grant it access to
>>the particular MIME parts needed to compose this message, and then
>>only given it access for a small period of time.
> 
> 
> Yes.  This would not be required, but would be highly desirable.  The
> submit process is denied access to any other data.
> 
> 
> ...
 > ...
> 
>>I am very worried about
>>something getting it's mitts on the token I'm going to have to pass
>>to the submit server that it's going to have to pass to my IMAP
>>server.
> 
> 
> This is easily solved.  It isn't as if we don't have the intelligence to
> work how a way of generating tokens that only a particular entity can use.
> 
> Aren't you worried about the IMAP server being compelled to massage data
> in ways that no IMAP server has ever done before?
> 
> 
>>I am even worried about the fact that I have to pass *any*
>>information to my submit server to allow it to get stuff from my IMAP
>>server. I don't want my submit server to have *any* information that
>>will allow it to access parts of my IMAP store. This sounds like a
>>big gaping security hole.
> 
> 
> So, to solve this security hole, you propose to pass *all* of your
> information to your submit server to allow it to get stuff from your IMAP
> server.  You propose to provide your submit server with information that
> will grant it *full* access to your entire IMAP store -- because you want
> the IMAP server to *be* the submit server!
> 
> ...
> 
>>>Mobile clients will benefit because they can be deployed without requiring
>>>a change to the IMAP server.
>>
>>But it will a require a *huge* change to the security model.
> 
> 
> Not at all.  As far as the client is concerned, it's just URLs.
> 
> 
>>The reality is that the main focus of this particular service is
>>going to require a number of changes to the IMAP server, so I don't
>>see this as any significant issue.
> 
> 
> Wrong.
> 
> It can be deployed with *no* changes to any IMAP server, albeit with the
> disadvantage that you'll have to give IMAP server authorization
> credentials to the submit server.
> 
> The only enhancements to the IMAP server would be: (1) a command to
> generate the token (URL or otherwise), and a SASL mechanism to return the
> data given the token.
> 
> 
>>>A large (and growing number) of deployed mobile clients will serve to
>>>convince IMAP server vendors to support the URL extensions so trust is not
>>>required.
>>
>>I am not even convinced as a user that I would want such support in
>>my IMAP server due to the security risks.
> 
> 
> I am not convinced as an IMAP server implementor that I would want submit
> code (not to mention SMTP client code and outgoing SMTP connections) in
> my IMAP server due to the security risks.
> 
> 
>>>Assuming that the security issues in the URL extensions can be
>>>resolved (and I think that they can), it will be almost a no-brainer
>>>to add them to an IMAP server.
>>
>>I am far less sanguine about the security considerations.
> 
> 
> I am horrified by the security considerations of making an IMAP server do
> submit.
> 
> 
> ...



>>

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  Doug@Royer.com                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

--------------ms030407040902090302050401
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC
A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j
cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB
MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T
BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN
VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre
qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+
5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA
MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg
TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD
QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx
ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz
IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq
hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34
1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA
gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK
YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd
SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC
AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF
BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl
cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl
IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs
MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq
1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2
TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail
MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE
AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO
b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG
MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD
VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV
BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv
43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y
lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP
D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn
0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK
bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg
hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT
IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI
AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t
L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk
OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW
yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1
MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl
ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MDkyMjQ3MzdaMCMGCSqGSIb3DQEJBDEWBBQp
KwCAqE/lXS503538gh0pe7w6rzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL
KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAeZChQxwwHNfs
yjlLEtAWMO/pzVwN4yTJgFG+IRh6xfdoWS6EkqXmIX4kWnTfd5u611yeN6JRaBQdI5bgeyWn
xdCjje8HJ9Mge8XvuJmd9z+tibTCSwQVPn+phXo1CbAtL/TPVcCTCa+Ugr8GGTXsWrrB3jUx
XehExVlo5KabjMD1+1QpWbcyyyXdro2X6Hi9XZIJx+QZ9cwzP+dMKOshyKYQnrlaDs7Aunum
bc6SVBG/oMSmRvrMyliLDfDMNse56vlmaIt5qfgAUnB8N18nRGnBORw9EhwG4kHKkB6EdR+6
QAeHZM8tMHZI6oKUtUQfXLe1nDkCE/vjd+SrlpOkQgAAAAAAAA==
--------------ms030407040902090302050401--

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



From mailnull@www1.ietf.org  Mon Jun  9 18:56:28 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24682
	for <lemonade-archive@odin.ietf.org>; Mon, 9 Jun 2003 18:56:28 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h59Mu5V11777
	for lemonade-archive@odin.ietf.org; Mon, 9 Jun 2003 18:56:05 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59Mu5B11774
	for <lemonade-web-archive@optimus.ietf.org>; Mon, 9 Jun 2003 18:56:05 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24679
	for <lemonade-web-archive@ietf.org>; Mon, 9 Jun 2003 18:55:57 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PVWY-0007d8-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 18:53:58 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PVWY-0007d5-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 18:53:58 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59Mu1B11766;
	Mon, 9 Jun 2003 18:56:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59MtSB11750
	for <lemonade@optimus.ietf.org>; Mon, 9 Jun 2003 18:55:28 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24675
	for <lemonade@ietf.org>; Mon, 9 Jun 2003 18:55:20 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PVVx-0007ck-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 18:53:21 -0400
Received: from inet-consulting.com ([4.23.9.166] helo=royer.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PVVw-0007ch-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 18:53:20 -0400
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h59MtGbt020953
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <lemonade@ietf.org>; Mon, 9 Jun 2003 15:55:20 -0700
Message-ID: <3EE5104F.5010303@Royer.com>
Date: Mon, 09 Jun 2003 16:55:11 -0600
From: Doug Royer <Doug@Royer.com>
Reply-To: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: lemonade@ietf.org
References: <Pine.LNX.4.44.0306091218180.16563-100000@sokol.elan.net> <Pine.WNT.4.60.0306091523080.924@Tomobiki-Cho.CAC.Washington.EDU>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050900080203040200040309"
Subject: [lemonade] Re: IMAP  as submit server and SPAM
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This is a cryptographically signed message in MIME format.

--------------ms050900080203040200040309
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Mark Crispin wrote:

> ....
>>and since in real-world right now
>>firewalls often do not filter IMAP but they do filter SMTP and SMTP-submit.
> 
> 
> As soon as spammers work out how to spam with IMAP, you can be confident
> that we'll start seeing blocking of IMAP ports too.

True. My experience shows me that most SPAM comes from open relays.
IMAP submissions would be already authenticated and could be signed
in some simple or complex way on their way out.


-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  Doug@Royer.com                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

--------------ms050900080203040200040309
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC
A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j
cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB
MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T
BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN
VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre
qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+
5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA
MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg
TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD
QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx
ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz
IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq
hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34
1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA
gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK
YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd
SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC
AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF
BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl
cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl
IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs
MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq
1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2
TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail
MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE
AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO
b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG
MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD
VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV
BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv
43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y
lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP
D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn
0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK
bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg
hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT
IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI
AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t
L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk
OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW
yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1
MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl
ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MDkyMjU1MTFaMCMGCSqGSIb3DQEJBDEWBBT5
p/Z1UB5pfvPqVb7R/XaXatKuUDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL
KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAWyvdsYfmgzg2
fA/ia4bfIFXWayh46jAMgLPQ9txrX/OgXpTbjpL1mgnw1/sAD17wQgwQiaChCvy++Nz29ht/
BYfZ1rL9giEgdL8Uwq0IRt/pwu7FeTBH6+dZs74LyZZyW3P0kpryHTapv2QNO+Kb6Gjd2h0d
qDvhY/8JODmD1GXzehy0NK34bGhc+keQWqT8yhTSldwpU1U+/ybNN7Smp4kMUD0aOhMKm9nA
efcxiF5oxGv5mYTrGEkmfwa0MyTSCVlx1FrSOZ1YHtZdBUK7eDPDoKNVpeBKle4wk7AxvDT4
8q7vpJvBntTKhjTIX5CAz5xPZ6A31u9uwasLYKkoVAAAAAAAAA==
--------------ms050900080203040200040309--

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



From mailnull@www1.ietf.org  Mon Jun  9 20:22:44 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26155
	for <lemonade-archive@odin.ietf.org>; Mon, 9 Jun 2003 20:22:43 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5A0MGc17428
	for lemonade-archive@odin.ietf.org; Mon, 9 Jun 2003 20:22:16 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A0MGB17424
	for <lemonade-web-archive@optimus.ietf.org>; Mon, 9 Jun 2003 20:22:16 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26132
	for <lemonade-web-archive@ietf.org>; Mon, 9 Jun 2003 20:22:13 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PWs0-0000ET-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 20:20:12 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PWs0-0000EQ-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 20:20:12 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A0M6B17375;
	Mon, 9 Jun 2003 20:22:06 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A0LOB17332
	for <lemonade@optimus.ietf.org>; Mon, 9 Jun 2003 20:21:24 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26110
	for <lemonade@ietf.org>; Mon, 9 Jun 2003 20:21:21 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PWrA-0000Dk-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 20:19:20 -0400
Received: from mxout3.cac.washington.edu ([140.142.32.166])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PWr9-0000Dc-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 20:19:19 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9])
	by mxout3.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h5A0LHSL000566
	for <lemonade@ietf.org>; Mon, 9 Jun 2003 17:21:17 -0700
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
	(authenticated bits=0)
	by smtp.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h5A0LH7k020409
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT)
	for <lemonade@ietf.org>; Mon, 9 Jun 2003 17:21:17 -0700
Date: Mon, 9 Jun 2003 17:21:19 -0700 (Pacific Daylight Time)
From: Mark Crispin <MRC@CAC.Washington.EDU>
To: lemonade@ietf.org
Subject: Re: [lemonade] Re: IMAP as a submit server
In-Reply-To: <3EE50E89.8040509@Royer.com>
Message-ID: <Pine.WNT.4.60.0306091704290.924@Tomobiki-Cho.CAC.Washington.EDU>
References: <3EE4C3EB.A8A32ABE@sun.com> <a06001406bb0a7f742ef1@[10.10.0.150]>
 <Pine.NXT.4.56.0306091132430.11845@Ikkoku-Kan.Panda.COM>
 <p06001410bb0a97292a4e@[216.43.25.67]> <Pine.WNT.4.60.0306091433020.924@Tomobiki-Cho.CAC.Washington.EDU>
 <3EE50E89.8040509@Royer.com>
Organization: Networks & Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Mon, 9 Jun 2003, Doug Royer wrote:
> I really do not understand your points below (I hope I did not cut
> out any thing important). It seems to me as if your points are
> in conflict with each other.

I hope that I can explain.

> If I give a submit server my authentication credentials, then it is
> in effect an IMAP client - with FULL IMAP access anyway.

I am not proposing that that be done; or rather, I am not proposing that
that be done when talking to an enhanced IMAP server.  If you have to use
a non-enhanced IMAP server, you have no choice but to do that.

> Are you
> proposing that each submission be given a unique authentication so
> that the IMAP server knows to give 'this' and only 'this' message
> or meassage-body-part to 'that' IMAP client?

Not exactly.  Each IMAP URL (assuming that URLs are the means to convey
the tokens) in the submission has its own unique authentication that gives
"this" and only "this" mesage or message-body-part.

The basic idea is that the token is something that only someone with
access to the data can generate.  So, the token needs to contain the
necessary data (user, mailbox name, message UID and part specifier) and
some signature which the IMAP server will recognize.

One way for the client to build this token is to ask the IMAP server for
it (after all, it has to be in communication with the IMAP server to know
that the data is there!).  So, instead of doing:
	tag UID FETCH 122239 BODY[1.3]
it would do something like:
	tag UID GENTOKEN 122239 BODY[1.3]
and insert the result into the message being submitted.  You can imagine
adding things like expiration times, or tokens that only the submit server
can use, etc.

The submit server would use a SASL authenticator to get at it.  In other
words, it would all be done via the AUTHENTICATE command.

> In order for the IMAP server to know that only this MIME body part
> should be given to 'this' submit server for the purpose of doing
> an in-line expansion would require the IMAP client tell the IMAP server
> each and every time that 'this' MIME object can be shared.
> This looks like a lot of round trips and complication to me.

Not if we make it possible to coalesce requests, such as:
	tag UID GENTOKEN (122239 BODY[1.3] BODY[1.4])(121232 BODY[3.2])

> It seems to me that if an IMAP server were also a submit server
> then it would reduce any cross-vendor submit/imap-server security
> holes. And it would reduce the ACLs (or whatever is used) control
> complexities which again I think would reduce the security holes.

I don't see how you came to that conclusion.

By making an IMAP server do submit you're putting all your security eggs
into one monolithic basket.  Crack any egg and everything is lost.

-- 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 mailnull@www1.ietf.org  Mon Jun  9 23:26:39 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29503
	for <lemonade-archive@odin.ietf.org>; Mon, 9 Jun 2003 23:26:39 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5A3QBv28928
	for lemonade-archive@odin.ietf.org; Mon, 9 Jun 2003 23:26:11 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A3QBB28925
	for <lemonade-web-archive@optimus.ietf.org>; Mon, 9 Jun 2003 23:26:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29482
	for <lemonade-web-archive@ietf.org>; Mon, 9 Jun 2003 23:26:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PZk0-00019w-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 23:24:08 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PZk0-00019t-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 23:24:08 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A3Q7B28898;
	Mon, 9 Jun 2003 23:26:07 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A3PIB28874
	for <lemonade@optimus.ietf.org>; Mon, 9 Jun 2003 23:25:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29407
	for <lemonade@ietf.org>; Mon, 9 Jun 2003 23:25:15 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PZj9-00017w-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 23:23:15 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PZj8-00017l-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 23:23:14 -0400
Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151])
	by ithilien.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h5A3PBfE028399;
	Mon, 9 Jun 2003 20:25:11 -0700 (PDT)
Received: from [10.10.0.150] (vpn-10-50-0-3.qualcomm.com [10.50.0.3])
	by crowley.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h5A3OMix008825;
	Mon, 9 Jun 2003 20:24:46 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <a06001412bb0afdf79699@[10.10.0.150]>
In-Reply-To: <Pine.LNX.4.44.0306091218180.16563-100000@sokol.elan.net>
References: <Pine.LNX.4.44.0306091218180.16563-100000@sokol.elan.net>
X-Mailer: Eudora for Mac OS X v6.0a
Date: Mon, 9 Jun 2003 23:19:39 -0400
To: william@elan.net, "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
From: Randall Gellens <randy@qualcomm.com>
Subject: RE: [lemonade] Life on the List, and Vienna
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b25
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

At 12:33 PM -0700 6/9/03, william@elan.net wrote:

>  in real-world right now
>  firewalls often do not filter IMAP but they do filter SMTP and SMTP-submit.

Firewalls filter inbound or outbound SMTP and Submit?  Filtering 
inbound SMTP blocks all external access to the SMTP server, which 
makes it impossible for anyone outside to send you mail.  Filtering 
inbound Submit serves only to block access to the submit server by 
authorized persons wishing to submit mail from outside (assuming the 
submit server requires authentication for all transactions, as is 
recommended).  Filtering outbound SMTP prevents your users from 
spamming; this may or may not be useful, depending on how much 
control you have over your users.  Filtering outbound Submit doesn't 
make sense, since Submit servers should require authentication and 
thus aren't generally useful for spamming.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Democracy is a form of government in which it is permitted to wonder
aloud what the country could do under first-class management.
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Mon Jun  9 23:26:45 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29524
	for <lemonade-archive@odin.ietf.org>; Mon, 9 Jun 2003 23:26:45 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5A3QIT28945
	for lemonade-archive@odin.ietf.org; Mon, 9 Jun 2003 23:26:18 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A3QIB28942
	for <lemonade-web-archive@optimus.ietf.org>; Mon, 9 Jun 2003 23:26:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29492
	for <lemonade-web-archive@ietf.org>; Mon, 9 Jun 2003 23:26:15 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PZk7-0001A9-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 23:24:15 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PZk6-0001A6-00
	for lemonade-web-archive@ietf.org; Mon, 09 Jun 2003 23:24:14 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A3Q8B28915;
	Mon, 9 Jun 2003 23:26:08 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A3PrB28883
	for <lemonade@optimus.ietf.org>; Mon, 9 Jun 2003 23:25:53 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29471
	for <lemonade@ietf.org>; Mon, 9 Jun 2003 23:25:50 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PZji-00019b-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 23:23:50 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PZjh-00019T-00
	for lemonade@ietf.org; Mon, 09 Jun 2003 23:23:49 -0400
Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151])
	by ithilien.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h5A3PnfE028417;
	Mon, 9 Jun 2003 20:25:49 -0700 (PDT)
Received: from [10.10.0.150] (vpn-10-50-0-3.qualcomm.com [10.50.0.3])
	by crowley.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h5A3OMj1008825;
	Mon, 9 Jun 2003 20:25:24 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <a06001413bb0afefcd3bf@[10.10.0.150]>
In-Reply-To: <3EE509D4.3040109@Royer.com>
References: 
 <4A3384433CE2AB46A63468CB207E209D59E327@zoe.office.snowshore.com>
 <639142451.20030609110140@openwave.com>
 <1055187322.3665.2.camel@localhost.localdomain>
 <3EE4E2B5.49BB0A80@sun.com> <a0600140dbb0a9a3c75d7@[10.10.0.150]>
 <Pine.WNT.4.60.0306091407580.924@Tomobiki-Cho.CAC.Washington.EDU>
 <172316146.20030609151214@openwave.com> <3EE509D4.3040109@Royer.com>
X-Mailer: Eudora for Mac OS X v6.0a
Date: Mon, 9 Jun 2003 23:24:09 -0400
To: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
From: Randall Gellens <randy@qualcomm.com>
Subject: [lemonade] Re: Just 'ATTACH'
Cc: Doug Royer <Doug@royer.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b25
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

At 4:27 PM -0600 6/9/03, Doug Royer wrote:

>  Alan K. Stebbens wrote:
>
>>  Therefore, a new type/subtype, perhaps a qualifier to one, or, even a new
>>  SMTP command (ATTACH?) needs to be defined to trigger the dereferencing of
>>  the URLs.
>
>  SMTP commands can not be embedded into the DATA stream. So I do not think
>  an ATTACH SMTP command will work. Although most MUAs display 'attachments'
>  in a separate pane, they are inline in just about any random order.

We would be creating a new Submit extension mechanism.  Such a 
mechanism could be as simple as saying 'expand references external 
body parts that have the "expand" flag set'.  Note that during the 
discussions on developing a separate SMTP submit service from the 
SMTP relay service, it was suggested that future Submit extensions 
that were only useful for message submission should perhaps look 
quite different from SMTP extensions, to prevent them from leaking 
into SMTP relay.  One example would be a kind of envelope wrapping 
the transaction.  At the time, there was discussion of using a Submit 
service for various sorts of helpful things, including transcoding of 
voice attachments, creating a proper message, etc.


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Nothing is illegal if one hundred businessmen decide to do it.
        --Andrew Young
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Tue Jun 10 00:09:33 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00238
	for <lemonade-archive@odin.ietf.org>; Tue, 10 Jun 2003 00:09:32 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5A496V31960
	for lemonade-archive@odin.ietf.org; Tue, 10 Jun 2003 00:09:06 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A496B31957
	for <lemonade-web-archive@optimus.ietf.org>; Tue, 10 Jun 2003 00:09:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00228
	for <lemonade-web-archive@ietf.org>; Tue, 10 Jun 2003 00:09:02 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PaPW-0001KN-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 00:07:02 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PaPW-0001KK-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 00:07:02 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A492B31942;
	Tue, 10 Jun 2003 00:09:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A483B31909
	for <lemonade@optimus.ietf.org>; Tue, 10 Jun 2003 00:08:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00172
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 00:07:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PaOV-0001Jz-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 00:05:59 -0400
Received: from champdsl-25-66.mcleodusa.net ([216.43.25.66] helo=episteme-software.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PaOU-0001Jv-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 00:05:58 -0400
Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with
 ESMTP (Eudora Internet Mail Server X 3.2.2b1) for <lemonade@ietf.org>;
 Mon, 9 Jun 2003 23:07:28 -0500
Mime-Version: 1.0
X-Sender: resnick@resnick1.qualcomm.com
Message-Id: <p06001411bb0ae3b51b57@[216.43.25.67]>
In-Reply-To: 
 <Pine.WNT.4.60.0306091433020.924@Tomobiki-Cho.CAC.Washington.EDU>
References: <3EE4C3EB.A8A32ABE@sun.com>
 <a06001406bb0a7f742ef1@[10.10.0.150]>
 <Pine.NXT.4.56.0306091132430.11845@Ikkoku-Kan.Panda.COM>
 <p06001410bb0a97292a4e@[216.43.25.67]>
 <Pine.WNT.4.60.0306091433020.924@Tomobiki-Cho.CAC.Washington.EDU>
X-Mailer: Eudora [Macintosh version 6.0a15]
Date: Mon, 9 Jun 2003 23:07:26 -0500
To: lemonade@ietf.org
From: Pete Resnick <presnick@qualcomm.com>
Subject: RE: [lemonade] Life on the List, and Vienna
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On 6/9/03 at 3:22 PM -0700, Mark Crispin wrote:

>On Mon, 9 Jun 2003, Pete Resnick wrote:
>>Another advantage is, "Does not require a submit server to know 
>>anything about MIME structure".
>
>A submit service is already required to understand headers and MIME, 
>since otherwise it won't be able to perform the transforms required 
>by 8-bit.

1. There is a very big difference between being able to understand 
CTE's, things of type "multipart", and things of type "message" 
versus being able to generate an appropriately formatted MIME message 
from URLs and external-body parts. There is already plenty of code in 
the IMAP implementations I know about to get through structures much 
more complicated than any current submit server has to deal with.

2. Many folks do (and the proposed IMAP servers could) use submit 
servers that don't understand MIME. That is to say, many folks use 
plain old (non-ESMTP) SMTP servers to submit on port 25. Sure, that 
might mean your stuck with 7bit, or you might be stuck with an ESMTP 
server that cannot down-convert 8-bit (perfectly legal according to 
the 8BITMIME spec, and perfectly sensible in an environment where 
there will likely only ever be 8-bit), but it means that you can use 
a very stupid SMTP server without having it understand MIME structure.

>This "advantage" therefore does not buy anything.

Nonsense. You can use completely off-the-shelf SMTP servers for the 
submit end. My contention is that folks in "mobile client world" 
(read: 3G*, etc.) won't be able to use an off-the-shelf IMAP server 
anyway.

>I see no reason why to dump substantial additional requirements into 
>IMAP servers in order to avoid upgrading submit servers that are 
>already provably inadequate for the task.

The "task" in this case would be to accept (via SMTP) and forward an 
already formed MIME message. I would say that almost any SMTP server 
is up to that task.

>If a submit server does 8-bit, either the smarts are there or it is 
>non-compliant.

No, that's simply wrong. See RFC 2476 and RFC 1652. You can accept 
8-bit without guaranteeing down-convert.

>>>Need to be careful that all enhancements are done by using Submit 
>>>mechanisms, otherwise we end up defining two parallel submission 
>>>mechanisms, one for Port 587 and one for IMAP.
>>
>>This last one I think is a misrepresentation. It assumes that there 
>>are to be mechanisms in common. If (as I think about it) these are 
>>two completely separate services, then there is no reason to worry 
>>about any parallelisms.
>
>Huh??  You are claiming that, in spite of the fact that there are 
>going to be two means of doing submission, that there will not be 
>any parallelisms between the two???

No, I am simply claiming that adding submit to IMAP does not 
necessarily entail any new features for submit servers, and that any 
additions to submit servers can occur independently of anything going 
on with IMAP.

>>This is the one that scares the daylights out of me. Right now, my 
>>IMAP server has all of my mail data and access to my IMAP server 
>>means access to all of that data.
>
>Yes. And how would you like an IMAP server with all that power being 
>made to do processing and reformatting of submit requests? This 
>opens a vast hole that you can drive a truck through!

I'm sorry, I simply don't see the hole. Is it that because this IMAP 
server can now open a socket *to* port 25 (or 587), it can suddenly 
do something so vastly more horrible with my data than could be done 
before? And this is somehow supposed to be *worse* than my SMTP 
server being given access to port 143?

>>The suggestion for the submit model is to invent a mechanism that 
>>has access to my IMAP store. You want to be able to grant it access 
>>to the particular MIME parts needed to compose this message, and 
>>then only given it access for a small period of time.
>
>Yes.  This would not be required, but would be highly desirable.

I can't see the security considerations section of that document not 
requiring it.

>>I am very worried about the overhead to authenticate the submit server.
>
>This is minimal; the token itself carries that.

And what about my IMAP server which requires Kerberos tokens? Or 
requires other challenge-response kinds of tokens? Won't there be 
some significant overhead there? Or are SMTP servers are going to be 
given "special" (i.e., easier) access to the IMAP server?

>What about the overhead placed upon the IMAP server to process submits?

- The amount of overhead to *access* the various parts is a wash in 
either case.

-The authentication step is a wash if (in IMAP submit) the SMTP 
server requires such a token and (in SMTP gather submit) the submit 
server only has to authenticate for a single part. If there are 
multiple parts, or the SMTP server doesn't require additional 
authentication, then the IMAP submit method is better.

- The overhead to do the proposed collection in comparison to the 
overall overhead for other operations on a submit server is rather 
large. The overhead to do submission in comparison to the rest of 
IMAP operations is relatively lower. Remember, the IMAP server is in 
the habit of (and likely tuned for) doing database-query-like hits on 
the message store. Most submit servers I know about are lump-and-dump 
kinds of i/o machines.

>>I am very worried about something getting it's mitts on the token 
>>I'm going to have to pass to the submit server that it's going to 
>>have to pass to my IMAP server.
>
>This is easily solved.  It isn't as if we don't have the 
>intelligence to work how a way of generating tokens that only a 
>particular entity can use.

I am not so confident that (a) we can design this in a rock-solid way 
*and* (b) people will not screw up the implementations of it. I would 
certainly like to see a design before I would call it "easily solved".

>Aren't you worried about the IMAP server being compelled to massage 
>data in ways that no IMAP server has ever done before?

Of course I'm worried about that. But it is a worry of whether the 
IMAP server can handle the load and whether it can do it without 
incorrectly formatting the data. That's different from my worry about 
privacy and security of my data. The latter is much more worrisome.

>>I am even worried about the fact that I have to pass *any* 
>>information to my submit server to allow it to get stuff from my 
>>IMAP server. I don't want my submit server to have *any* 
>>information that will allow it to access parts of my IMAP store. 
>>This sounds like a big gaping security hole.
>
>So, to solve this security hole, you propose to pass *all* of your 
>information to your submit server to allow it to get stuff from your 
>IMAP server.  You propose to provide your submit server with 
>information that will grant it *full* access to your entire IMAP 
>store -- because you want the IMAP server to *be* the submit server!

No. Not at all. I want my IMAP server to collect together data that 
it already has access to and, within an authenticated session, send 
it (upon my command) through a single pipe to a SMTP server. The IMAP 
server and the submission server are two separate entities connected 
by that single port 25 (or 587) pipe. In the other proposal, the 
submission server has repeated access to my IMAP store without having 
me be in an authenticated session on the IMAP server.

>>In the case of using IMAP to do the submission, I will already have 
>>an authenticated session with the IMAP server where *I* communicate 
>>all of the relevant authentication information directly to my IMAP 
>>server in a secure manner. Then my IMAP session will have all of 
>>the appropriate permissions to all of the relevant portions of my 
>>IMAP store. The IMAP server will be the thing accessing all of the 
>>assorted parts and collecting them into a message to pass to the 
>>SMTP/submit server.
>
>This in effect makes the IMAP server be the submit server. Put 
>another way, a separate "SMTP/submit server" in this model is a 
>completely extraneous step with no apparent purpose.

No, the separation in the model is key. It means that there is a 
single pipe to the SMTP service out of my IMAP server. My IMAP server 
doesn't need to be concerned with the rest of the SMTP service 
(queuing, MX records, retries, etc.) and my SMTP service doesn't have 
to be concerned with the internals of my IMAP mail store. My IMAP 
submit service effectively becomes a special kind of "collected 
FETCH" which outputs it's response to an SMTP pipe. It is, IMO, much 
closer to what an IMAP server does now than the "collect-from-IMAP" 
mechanism is to what an SMTP server does.

Of course, you could put the two together if you like, but the key 
for me is that they don't *need* to be intimately aware of each other 
as is the case with the other mechanism.

>>>Mobile clients will benefit because they can be deployed without 
>>>requiring a change to the IMAP server.
>>
>>  But it will a require a *huge* change to the security model.
>
>Not at all.  As far as the client is concerned, it's just URLs.

But it's allowing access to data *without* having an authenticated 
session. This *is* a huge change to the IMAP security model.

>>The reality is that the main focus of this particular service is 
>>going to require a number of changes to the IMAP server, so I don't 
>>see this as any significant issue.
>
>Wrong.
>
>It can be deployed with *no* changes to any IMAP server, albeit with 
>the disadvantage that you'll have to give IMAP server authorization 
>credentials to the submit server.

1. What I initially meant by the above was that the consumers of 
LEMONADE are going to want other changes in their IMAP servers 
anyway, so there is no particular advantage in having the ability to 
use off-the-shelf IMAP servers.

2. It is completely unacceptable to be handing server authorization 
credentials to the submit server, so an off-the-shelf IMAP server is 
already unacceptable for this service.

On the other hand, an off-the-shelf SMTP server *can* be used for the 
submission end in my model.

>I am not convinced as an IMAP server implementor that I would want 
>submit code (not to mention SMTP client code and outgoing SMTP 
>connections) in my IMAP server due to the security risks.

I think I have given pretty plausible security risk scenarios for the 
other case. I have yet to hear a convincing case for why the threat 
model is *worse* in this case. Please explain.

>I am horrified by the security considerations of making an IMAP 
>server do submit.

And repeating it doesn't make it any more true. Please explain.

>>>Another important detail about the second camp is that it does not 
>>>depend upon all the data for submit being on one IMAP server.
>>
>>No, it only requires that all the data for submit be accessible 
>>from a single authenticated IMAP session.
>
>I debunked this statement in another message.

Calling something "debunked" does not make it so. It's a lousy 
debating tactic meant to make people who aren't paying attention 
think a good argument has been made.

Of course, crossing servers does mean that you need some sort of 
"IMAP store" sharing mechanism or some way to forward commands to 
another IMAP server (what Mark derided as "silliness like requiring 
that IMAP servers have built-in IMAP clients"), but those mechanisms 
do exist.

>>And I still don't understand, from Mark's original message, why:
>>>1) Keep IMAP and POP out of the MTA and MSA business.
>>is an important characteristic of such a system.
>
>An IMAP server currently does nothing more than access data from a 
>mail store, and export that data in various ways to an IMAP client.
>
>Your proposal would, for the first time, require that an IMAP server 
>be in the business of building RFC 2822/MIME compliant mesages from 
>input which is not strictly compliant,

"Not strictly compliant"? Explain please.

>including assembly of those messages with data from the mail store.

Yup. Seems to me much simpler code to put into an IMAP server than to 
put into a submit server.

>It would also require that the IMAP server contain an SMTP client, 
>to pass on the message to the MTA.

Something that even the simplest POP or IMAP client has as part of 
its code. We're not talking about rocket science here.

Again, what's the horrible impact here of not "keeping IMAP out of 
the MTA business"?

>There is also another security hole in your model that I just 
>realized. Any submit request from the mobile client which contains 
>incoming message data could contain IMAP-submit pointers.  Oops. 
>The client would have to be extremely careful to scan for this, and 
>the server would also have to have to be careful.

Or we could simply make the "auto-expand" part of this only work in 
the "Draft" or other special "Composition" mailbox. Not exactly a 
hard thing to avoid.

>>- Keep SMTP out of the mail store business.
>>is a much more logical principle, and one I think I can justify.
>
>SMTP is not doing mail store.  Nor is submit.

Sure it is. It's implementing an IMAP client. That seems like a much 
more radical departure than an IMAP server implementing an SMTP 
client.

pr
-- 
Pete Resnick <mailto:presnick@qualcomm.com>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Tue Jun 10 01:29:35 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01753
	for <lemonade-archive@odin.ietf.org>; Tue, 10 Jun 2003 01:29:35 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5A5T8W04073
	for lemonade-archive@odin.ietf.org; Tue, 10 Jun 2003 01:29:08 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A5T8B04070
	for <lemonade-web-archive@optimus.ietf.org>; Tue, 10 Jun 2003 01:29:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01748
	for <lemonade-web-archive@ietf.org>; Tue, 10 Jun 2003 01:29:05 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pbew-0001hd-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 01:27:02 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pbew-0001ha-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 01:27:02 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A5T3B04062;
	Tue, 10 Jun 2003 01:29:03 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A5SuB04046
	for <lemonade@optimus.ietf.org>; Tue, 10 Jun 2003 01:28:56 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01745
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 01:28:53 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pbek-0001hX-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 01:26:50 -0400
Received: from panda.com
	([206.124.149.114] helo=Ikkoku-Kan.Panda.COM ident=weiner)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pbej-0001hU-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 01:26:49 -0400
Received: from localhost (mrc@localhost) by Ikkoku-Kan.Panda.COM id WAA17923; Mon, 9 Jun 2003 22:28:38 -0700 (PDT)
Date: Mon, 9 Jun 2003 22:28:37 -0700 (PDT)
From: Mark Crispin <mrc@CAC.Washington.EDU>
To: Pete Resnick <presnick@qualcomm.com>
cc: lemonade@ietf.org
Subject: RE: [lemonade] Life on the List, and Vienna
In-Reply-To: <p06001411bb0ae3b51b57@[216.43.25.67]>
Message-ID: <Pine.NXT.4.56.0306092112530.11845@Ikkoku-Kan.Panda.COM>
References: <3EE4C3EB.A8A32ABE@sun.com> <a06001406bb0a7f742ef1@[10.10.0.150]>
 <Pine.NXT.4.56.0306091132430.11845@Ikkoku-Kan.Panda.COM>
 <p06001410bb0a97292a4e@[216.43.25.67]> <Pine.WNT.4.60.0306091433020.924@Tomobiki-Cho.CAC.Washington.EDU>
 <p06001411bb0ae3b51b57@[216.43.25.67]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Mon, 9 Jun 2003, Pete Resnick wrote:
> I'm sorry, I simply don't see the hole. Is it that because this IMAP
> server can now open a socket *to* port 25 (or 587), it can suddenly
> do something so vastly more horrible with my data than could be done
> before?

The whole is that a large and very complicated process (a message
composer), not to mention an SMTP client, neither of which have anything
to do with message access, are now running on the IMAP server machine with
unlimited access to mailbox data.

> And this is somehow supposed to be *worse* than my SMTP
> server being given access to port 143?

Yes, it is; because the SMTP server won't have unlimited access.

> >>The suggestion for the submit model is to invent a mechanism that
> >>has access to my IMAP store. You want to be able to grant it access
> >>to the particular MIME parts needed to compose this message, and
> >>then only given it access for a small period of time.
> >Yes.  This would not be required, but would be highly desirable.
> I can't see the security considerations section of that document not
> requiring it.

Why?  It only matters if the IMAP server does not trust the submit server.
There will be many environments in which such trust will exist.

> Or are SMTP servers are going to be
> given "special" (i.e., easier) access to the IMAP server?

I don't understand how you could have missed this.  That is *exactly* what
is being proposed.  These tokens will carry their own access authorization
credentials.

> -The authentication step is a wash

There is no "authentication step".

> - The overhead to do the proposed collection in comparison to the
> overall overhead for other operations on a submit server is rather
> large. The overhead to do submission in comparison to the rest of
> IMAP operations is relatively lower.

You are disregarding the overhead of actually building the message; this
is something that is fundamentally different than anything else that an
IMAP server does.  A submit server, on the other hand, already has to know
how to build messages.

> I am not so confident that (a) we can design this in a rock-solid way
> *and* (b) people will not screw up the implementations of it. I would
> certainly like to see a design before I would call it "easily solved".

Are you really saying that we don't know how to sign a piece of text in a
way that, when we subsequently look at it, we can tell whether or not that
text was signed by us?

> >So, to solve this security hole, you propose to pass *all* of your
> >information to your submit server to allow it to get stuff from your
> >IMAP server.  You propose to provide your submit server with
> >information that will grant it *full* access to your entire IMAP
> >store -- because you want the IMAP server to *be* the submit server!
> No. Not at all. I want my IMAP server to collect together data that
> it already has access to and, within an authenticated session, send
> it (upon my command) through a single pipe to a SMTP server.

You just echoed exactly what I said.

You propose to move the function of a submit (as opposed to SMTP)  server
to the IMAP server.

> No, the separation in the model is key. It means that there is a
> single pipe to the SMTP service out of my IMAP server.

So how do you propose sending a message which contains data from multiple
IMAP servers with your single pipe?

> My IMAP server
> doesn't need to be concerned with the rest of the SMTP service

So why do you want it to have an SMTP client?

> My IMAP
> submit service effectively becomes a special kind of "collected
> FETCH" which outputs it's response to an SMTP pipe.

What you call a "collected FETCH" is an 2822/MIME formatted message.
Building such a thing requires an extensive body of software which is not
in IMAP servers today.

> But it's allowing access to data *without* having an authenticated
> session. This *is* a huge change to the IMAP security model.

Not at all, because the tokens contain their own authentication.

I find it fascinating that you are lecturing me about the IMAP security
model.  The idea of a consolidated one-shot form of access (even UDP
based) is something that had been part of the architecture from the
beginning; this is just the first time that a need has come up for it.

> 1. What I initially meant by the above was that the consumers of
> LEMONADE are going to want other changes in their IMAP servers
> anyway, so there is no particular advantage in having the ability to
> use off-the-shelf IMAP servers.

Oh?  So you're saying that you want to build mobile devices that won't
work with the installed base?

Are you trying to build a useful product, or is this something useless
like the cell phone web browsers?

> 2. It is completely unacceptable to be handing server authorization
> credentials to the submit server, so an off-the-shelf IMAP server is
> already unacceptable for this service.

It is unacceptable in *some* environments, but not in others.  There are
many environments, e.g. enterprise, in which such trust relationships
exist.

> On the other hand, an off-the-shelf SMTP server *can* be used for the
> submission end in my model.

So, in order to have a no-op SMTP server, you want to make huge changes in
IMAP?

And what if the text isn't in IMAP?  Suppose it's on a POP3 server?  Or an
NNTP server?

> I think I have given pretty plausible security risk scenarios for the
> other case. I have yet to hear a convincing case for why the threat
> model is *worse* in this case. Please explain.

Composing a message requires buffers.  The composer has to do substantial
reformatting in order to ensure that the text complies with SMTP.  The
reformatting can result in text that is substantially larger than the
source.  The composer also has to be capable of negotiating SMTP, and of
handling the error responses (which also require buffers).

All of these are places in which a single faulty consideration can cause a
buffer overflow.

> >I am horrified by the security considerations of making an IMAP
> >server do submit.
> And repeating it doesn't make it any more true. Please explain.

Unlike you, I've written an IMAP server.  Multiple ones in fact.

A fundamental part of security is isolation of function.  An IMAP server
already has a great deal to do.  You are proposing a completely orthogonal
function to IMAP.  IMAP servers currently have *nothing* in the way of
code to build 2822/MIME texts, nor do they have an SMTP client.

I also have to consider your comments in light of your past statements
with regard to IMAP.  I remember quite a bit of criticism by you to the
effect that IMAP has "too much" functionality compared to POP.

> Calling something "debunked" does not make it so. It's a lousy
> debating tactic meant to make people who aren't paying attention
> think a good argument has been made.

Saying it isn't so doesn't mean that it isn't so.

Repeating the same refuted points doesn't cancel the refutation.

Two can play at this game.

Note that I am not claiming that your model won't work.  I am claiming
that your model is functionally limited (no way to incorporate data from
other sources), puts a substantial added burden on IMAP servers with
potential security implications, and damages the IMAP architecture (I as
the IMAP architect should be considered authoritative on that poin).

You on the other hand are going to great efforts to try to claim that my
model won't work, can't work, and shouldn't work.  For some reason, you
very much want to force this on IMAP.  You are refusing to consider an
alternative?

Why?  You are getting the strongest possible pushback of "we don't want to
do it this way."  Why not consider another way?  Why does this offend you?

I can tell you why your proposal offends us; it violates the fundamental
scope of IMAP.  And at least two of the major IMAP server implementors are
terrified of its implications.

I haven't heard of any submit server implementor mentioning such fears.
To the extent that there *are* submit server implementors, they're
wondering "how is this different from SMTP"?  Well, we now have something
that will make submit very much different.

> Of course, crossing servers does mean that you need some sort of
> "IMAP store" sharing mechanism or some way to forward commands to
> another IMAP server (what Mark derided as "silliness like requiring
> that IMAP servers have built-in IMAP clients"), but those mechanisms
> do exist.

Where?  Name them.

I have mail at ndcms.cac.washington.edu and panda.com.  There is no trust
relationship between the two.  There is no common password between the
two.

How do I post a message that incorporates data from both servers in your
model?

> >Your proposal would, for the first time, require that an IMAP server
> >be in the business of building RFC 2822/MIME compliant mesages from
> >input which is not strictly compliant,
> "Not strictly compliant"? Explain please.

By definition, a submit server can accept messages that lack such things
as Date:, From:, Message-ID:, etc.

> >including assembly of those messages with data from the mail store.
> Yup. Seems to me much simpler code to put into an IMAP server than to
> put into a submit server.

At least two IMAP server developers don't agree with that assessment.

> >It would also require that the IMAP server contain an SMTP client,
> >to pass on the message to the MTA.
> Something that even the simplest POP or IMAP client has as part of
> its code. We're not talking about rocket science here.

There is a difference between a client and a server.  It really doesn't
matter all that much in the overall scheme of things if a client hangs or
crashes or gets a buffer overflow.

It matters a great deal if that happens to a server.  Server code is much
more sensitive.

Now, when you have message composition done by a server, that means that
that sensitive code has to be somewhere.  You seem to want it to be in an
IMAP server.

We, observing that the state of submit (as opposed to SMTP) is rather
embryonic, believe that it belongs in the submit server.  Not only that,
but we feel that the submit server is going to have that capability sooner
or later in any case.

So, the obvious question is, why duplicate the same thing in IMAP?  Is it
as a temporary hack, to avoid having to think about building a submit
server (such as was done XSND or whatever it was called was in qpopper)?

Why bloat IMAP into such an unwieldy mess that it collapses under its own
weight?

> Again, what's the horrible impact here of not "keeping IMAP out of
> the MTA business"?

Why, after 20 or so years of opposition by both the POP and IMAP
communities against being in the MTA business, are we still discussing
this?

This is like the way the Democrats get bonds for some frivilous thing
passed by the voters; just keep on putting the damn thing on the ballot
over and over again until the "correct" vote happens.

Can't we move on?

We don't need this to accomplish the requirement.

> >There is also another security hole in your model that I just
> >realized. Any submit request from the mobile client which contains
> >incoming message data could contain IMAP-submit pointers.  Oops.
> >The client would have to be extremely careful to scan for this, and
> >the server would also have to have to be careful.
> Or we could simply make the "auto-expand" part of this only work in
> the "Draft" or other special "Composition" mailbox. Not exactly a
> hard thing to avoid.

That doesn't fix the problem.

Consider "reply including replied-to text".  Consider that text being
HTML.

> >SMTP is not doing mail store.  Nor is submit.
> Sure it is. It's implementing an IMAP client. That seems like a much
> more radical departure than an IMAP server implementing an SMTP
> client.

It also opens the possibility of the submit (not SMTP -- why do you keep
confusing the two?) server having a POP client, or an NNTP client, or a
FTP client, or an HTTP client, or a Gopher client, or a whatever new comes
up client.

This is a great benefit, with substantial expansion in the future.  What's
more, much of the infrastructure already exists in MIME.

Why should we want to restrict this capability to IMAP, and even worse to
one single IMAP server?

Are you claiming that message submission will never want to use other
protocols?  How much are you willing to wager?

Let's do the message submission right the first time, and not leave the
wreakage of quick-and-dirty hacks behind in other protocols.

Similarly, let's do mobile device email right the first time.  We should
be able to learn from the mistakes of others (such as cell phone web
browsers) and not repeat the same mistakes.  Maybe we'll make new
mistakes, but at least they won't be the same mistakes.

-- 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 mailnull@www1.ietf.org  Tue Jun 10 09:18:25 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28424
	for <lemonade-archive@odin.ietf.org>; Tue, 10 Jun 2003 09:18:24 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5ADHwR20705
	for lemonade-archive@odin.ietf.org; Tue, 10 Jun 2003 09:17:58 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ADHwB20702
	for <lemonade-web-archive@optimus.ietf.org>; Tue, 10 Jun 2003 09:17:58 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28322
	for <lemonade-web-archive@ietf.org>; Tue, 10 Jun 2003 09:17:54 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Piye-0005tY-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 09:15:52 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Piyd-0005tV-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 09:15:51 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ADHRB20649;
	Tue, 10 Jun 2003 09:17:27 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ADG5B20532
	for <lemonade@optimus.ietf.org>; Tue, 10 Jun 2003 09:16:05 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28200
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 09:16:01 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Piwp-0005qu-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 09:13:59 -0400
Received: from smtp7.andrew.cmu.edu ([128.2.10.87])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Piwo-0005qM-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 09:13:58 -0400
Received: from majormajor.REM.CMU.EDU (DYN-4-219.CC.cmu.edu [128.2.4.219] (may be forged))
	(user=leg mech=GSSAPI (0 bits))
	by smtp7.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h5ADFnXj018327
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT);
	Tue, 10 Jun 2003 09:15:49 -0400
Date: Tue, 10 Jun 2003 09:15:31 -0400
From: Lawrence Greenfield <leg+@andrew.cmu.edu>
To: Mark Crispin <mrc@cac.washington.edu>,
        Pete Resnick <presnick@qualcomm.com>
cc: lemonade@ietf.org
Subject: RE: [lemonade] Life on the List, and Vienna
Message-ID: <467548599.1055236531@majormajor.REM.CMU.EDU>
In-Reply-To: <Pine.NXT.4.56.0306092112530.11845@Ikkoku-Kan.Panda.COM>
References: <3EE4C3EB.A8A32ABE@sun.com>
 <a06001406bb0a7f742ef1@[10.10.0.150]>
 <Pine.NXT.4.56.0306091132430.11845@Ikkoku-Kan.Panda.COM>
 <p06001410bb0a97292a4e@[216.43.25.67]>
 <Pine.WNT.4.60.0306091433020.924@Tomobiki-Cho.CAC.Washington.EDU>
 <p06001411bb0ae3b51b57@[216.43.25.67]>
 <Pine.NXT.4.56.0306092112530.11845@Ikkoku-Kan.Panda.COM>
X-Mailer: Mulberry/3.0.3 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

--On Monday, June 09, 2003 10:28 PM -0700 Mark Crispin 
<mrc@cac.washington.edu> wrote:

> Not at all, because the tokens contain their own authentication.
>
> I find it fascinating that you are lecturing me about the IMAP security
> model.  The idea of a consolidated one-shot form of access (even UDP
> based) is something that had been part of the architecture from the
> beginning; this is just the first time that a need has come up for it.

It is!?!? That's really big news to me and I thought I had a pretty good 
understanding of the IMAP architecture.

IMAP seems to be ill-suited for one-shot access. You can't change 
authentication or authorization in midsession, meaning a new TCP session 
will need to be built for each access. The obvious granularity of access 
control, the mailbox, isn't fine grained enough to allow for the sort of 
fetches we're talking about here. Since it's difficult to do partial 
failures, it's not clear how to fail a FETCH that touches one authorized 
piece of information and one non-authorized piece of information.

In contrast, something like HTTP is well-suited for this style of access.

Larry

PS Mark, I think I agree with you, but please confine your technical 
messages to technical subjects and avoid politics.
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Tue Jun 10 12:40:40 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08450
	for <lemonade-archive@odin.ietf.org>; Tue, 10 Jun 2003 12:40:40 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5AGeEg07124
	for lemonade-archive@odin.ietf.org; Tue, 10 Jun 2003 12:40:14 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AGeEB07117
	for <lemonade-web-archive@optimus.ietf.org>; Tue, 10 Jun 2003 12:40:14 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08437
	for <lemonade-web-archive@ietf.org>; Tue, 10 Jun 2003 12:40:10 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pm8O-0000ML-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 12:38:08 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pm8O-0000MH-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 12:38:08 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AGe3B07094;
	Tue, 10 Jun 2003 12:40:03 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AGb4B06172
	for <lemonade@optimus.ietf.org>; Tue, 10 Jun 2003 12:37:04 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08334
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 12:37:00 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pm5K-0000KB-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 12:34:59 -0400
Received: from darius.cyrusoft.com ([63.163.82.2])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pm5K-0000K8-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 12:34:58 -0400
Received: from socrates.cyrusoft.com (localhost [127.0.0.1])
	by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id MAA02811;
	Tue, 10 Jun 2003 12:33:17 -0400 (EDT)
Date: Tue, 10 Jun 2003 12:36:55 -0400
From: Cyrus Daboo <daboo@cyrusoft.com>
To: Randall Gellens <randy@qualcomm.com>,
        "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
cc: Doug Royer <Doug@royer.com>
Subject: Re: [lemonade] Re: Just 'ATTACH'
Message-ID: <2147483647.1055248615@socrates.cyrusoft.com>
In-Reply-To: <a06001413bb0afefcd3bf@[10.10.0.150]>
References:  <4A3384433CE2AB46A63468CB207E209D59E327@zoe.office.snowshore.com
 > <639142451.20030609110140@openwave.com>
 <1055187322.3665.2.camel@localhost.localdomain> <3EE4E2B5.49BB0A80@sun.com>
 <a0600140dbb0a9a3c75d7@[10.10.0.150]>
 <Pine.WNT.4.60.0306091407580.924@Tomobiki-Cho.CAC.Washington.EDU>
 <172316146.20030609151214@openwave.com> <3EE509D4.3040109@Royer.com>
 <a06001413bb0afefcd3bf@[10.10.0.150]>
X-Mailer: Mulberry/3.1.0b1 (Mac OS/PPC)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi Randall,

--On Monday, June 9, 2003 11:24 PM -0400 Randall Gellens 
<randy@qualcomm.com> wrote:

|>  SMTP commands can not be embedded into the DATA stream. So I do not
|>  think an ATTACH SMTP command will work. Although most MUAs display
|>  'attachments' in a separate pane, they are inline in just about any
|>  random order.
|
| We would be creating a new Submit extension mechanism.  Such a mechanism
| could be as simple as saying 'expand references external body parts that
| have the "expand" flag set'.  Note that during the discussions on
| developing a separate SMTP submit service from the SMTP relay service, it
| was suggested that future Submit extensions that were only useful for
| message submission should perhaps look quite different from SMTP
| extensions, to prevent them from leaking into SMTP relay.  One example
| would be a kind of envelope wrapping the transaction.  At the time, there
| was discussion of using a Submit service for various sorts of helpful
| things, including transcoding of voice attachments, creating a proper
| message, etc.

Can we have a clear statement of what exactly needs to be expanded for this 
application? The two possibilities I see right now are:

1) Expand entire MIME parts by substituting data from an outside source: 
external-body expansion.

2) Expand inline data (e.g. quotations in a reply or forward).

The former is relatively easy to do - just substituting one MIME part for 
another.

The later is much more complicated as it requires detailed knowledge of the 
data itself. This really requires a full-blown 'composition agent' that 
knows how to deal with character set and encoding issues for all components 
of the data being expanded, as well as data format issues (e.g. knows how 
to put together HTML fragments in a consistent manner). That definitely 
goes beyond anything that either SMTP or IMAP has had to do up till now.

If (2) is a requirement then I'd be more inclined to go with a third server 
option that has not been discussed much - namely having a new type of 
server a 'message composition server' that has all the logic and capability 
of a typical desktop MUA in terms of building rfc2822/MIME messages as well 
as the ability to pull in data from external sources (with an appropriate 
security model). As well as providing pointers to the source components of 
the message, the client of this server would also be able to specify the 
destination, which might be an IMAP server or an SMTP server or some other 
destination in a similar manner to IMAP CHANNEL. Has this third server 
option been ruled out for any reason?

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



From mailnull@www1.ietf.org  Tue Jun 10 13:03:38 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09227
	for <lemonade-archive@odin.ietf.org>; Tue, 10 Jun 2003 13:03:38 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5AH3C208420
	for lemonade-archive@odin.ietf.org; Tue, 10 Jun 2003 13:03:12 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AH3CB08417
	for <lemonade-web-archive@optimus.ietf.org>; Tue, 10 Jun 2003 13:03:12 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09208
	for <lemonade-web-archive@ietf.org>; Tue, 10 Jun 2003 13:03:07 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PmUc-0000XZ-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 13:01:06 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PmUb-0000XV-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 13:01:05 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AH32B08400;
	Tue, 10 Jun 2003 13:03:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AH26B08350
	for <lemonade@optimus.ietf.org>; Tue, 10 Jun 2003 13:02:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09193
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 13:02:01 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PmTY-0000XF-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 13:00:00 -0400
Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PmTX-0000Wr-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 12:59:59 -0400
Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83])
	by ihemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h5AH1Ut22457
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 12:01:30 -0500 (CDT)
Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19)
	id <L2XL0P3Y>; Tue, 10 Jun 2003 12:01:29 -0500
Message-ID: <54E40201497DF142B06B27255953F79705BFD86F@il0015exch007u.ih.lucent.com>
From: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
To: Mark Crispin <MRC@CAC.Washington.EDU>, lemonade@ietf.org
Subject: RE: [lemonade] Re: IMAP as a submit server
Date: Tue, 10 Jun 2003 12:01:27 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

Mark, 

- What happens if the body is deleted off the IMAP server before the external component is resolved by the submit server?  How is this race condition resolved?   (use case: User forwards big message and then deletes the original)  

Greg V.


-----Original Message-----
From: Mark Crispin [mailto:MRC@CAC.Washington.EDU]
Sent: Monday, June 09, 2003 7:21 PM
To: lemonade@ietf.org
Subject: Re: [lemonade] Re: IMAP as a submit server


On Mon, 9 Jun 2003, Doug Royer wrote:
> I really do not understand your points below (I hope I did not cut
> out any thing important). It seems to me as if your points are
> in conflict with each other.

I hope that I can explain.

> If I give a submit server my authentication credentials, then it is
> in effect an IMAP client - with FULL IMAP access anyway.

I am not proposing that that be done; or rather, I am not proposing that
that be done when talking to an enhanced IMAP server.  If you have to use
a non-enhanced IMAP server, you have no choice but to do that.

> Are you
> proposing that each submission be given a unique authentication so
> that the IMAP server knows to give 'this' and only 'this' message
> or meassage-body-part to 'that' IMAP client?

Not exactly.  Each IMAP URL (assuming that URLs are the means to convey
the tokens) in the submission has its own unique authentication that gives
"this" and only "this" mesage or message-body-part.

The basic idea is that the token is something that only someone with
access to the data can generate.  So, the token needs to contain the
necessary data (user, mailbox name, message UID and part specifier) and
some signature which the IMAP server will recognize.

One way for the client to build this token is to ask the IMAP server for
it (after all, it has to be in communication with the IMAP server to know
that the data is there!).  So, instead of doing:
	tag UID FETCH 122239 BODY[1.3]
it would do something like:
	tag UID GENTOKEN 122239 BODY[1.3]
and insert the result into the message being submitted.  You can imagine
adding things like expiration times, or tokens that only the submit server
can use, etc.

The submit server would use a SASL authenticator to get at it.  In other
words, it would all be done via the AUTHENTICATE command.

> In order for the IMAP server to know that only this MIME body part
> should be given to 'this' submit server for the purpose of doing
> an in-line expansion would require the IMAP client tell the IMAP server
> each and every time that 'this' MIME object can be shared.
> This looks like a lot of round trips and complication to me.

Not if we make it possible to coalesce requests, such as:
	tag UID GENTOKEN (122239 BODY[1.3] BODY[1.4])(121232 BODY[3.2])

> It seems to me that if an IMAP server were also a submit server
> then it would reduce any cross-vendor submit/imap-server security
> holes. And it would reduce the ACLs (or whatever is used) control
> complexities which again I think would reduce the security holes.

I don't see how you came to that conclusion.

By making an IMAP server do submit you're putting all your security eggs
into one monolithic basket.  Crack any egg and everything is lost.

-- 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
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Tue Jun 10 13:03:51 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09243
	for <lemonade-archive@odin.ietf.org>; Tue, 10 Jun 2003 13:03:51 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5AH3P708450
	for lemonade-archive@odin.ietf.org; Tue, 10 Jun 2003 13:03:25 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AH3PB08447
	for <lemonade-web-archive@optimus.ietf.org>; Tue, 10 Jun 2003 13:03:25 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09213
	for <lemonade-web-archive@ietf.org>; Tue, 10 Jun 2003 13:03:20 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PmUp-0000Xg-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 13:01:19 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PmUp-0000Xd-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 13:01:19 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AH32B08384;
	Tue, 10 Jun 2003 13:03:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AH24B08343
	for <lemonade@optimus.ietf.org>; Tue, 10 Jun 2003 13:02:04 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09176
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 13:01:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PmTW-0000X9-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 12:59:58 -0400
Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PmTV-0000Wq-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 12:59:57 -0400
Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83])
	by ihemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h5AH1Rt22418
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 12:01:27 -0500 (CDT)
Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19)
	id <L2XL0P3Q>; Tue, 10 Jun 2003 12:01:26 -0500
Message-ID: <54E40201497DF142B06B27255953F79705BFD86E@il0015exch007u.ih.lucent.com>
From: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
To: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: RE: [lemonade] Re: IMAP  as submit server and SPAM
Date: Tue, 10 Jun 2003 12:01:26 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>


Comparing the two options in light of the Lemonade requirements for efficiency over costly, high-latency links.

Using SMTP-Submit, 

1) Client requests a hash-token for a body part or message of interest from existing IMAP connection. (one round trip)

2) Client opens new TCP session to SMTP-Submit server (one round-trip)

3) Initiates SMTP protocol, determine capabilities, and authenticates to Submit server (three round trips)

4) Client sends message to submit server (about two round trips using command pipelining)

5) Client closes SMTP (1 round-trip)

Each wireless round-trip is about 100-150 ms... for a network-induced "extra" latency of about a second.  Extra latency if the client has to wait for the submit server to resolve the references before providing the 200 OK response to the DATA or BDAT for the submission.

The open of TCP and authentication also requires sending of extra data... maybe two hundred extra bytes or so vs. using an existing authenticated session. (extra $$)


Using IMAP-Submit 

1) Client posts message to outbox, client annotates message with SMTP envelope in pipeline, receives status in response (1 round trip)
	
Greg V.

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



From mailnull@www1.ietf.org  Tue Jun 10 13:30:48 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10210
	for <lemonade-archive@odin.ietf.org>; Tue, 10 Jun 2003 13:30:48 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5AHUNj10684
	for lemonade-archive@odin.ietf.org; Tue, 10 Jun 2003 13:30:23 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AHUNB10681
	for <lemonade-web-archive@optimus.ietf.org>; Tue, 10 Jun 2003 13:30:23 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10185
	for <lemonade-web-archive@ietf.org>; Tue, 10 Jun 2003 13:30:18 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pmuv-0000o6-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 13:28:17 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pmuu-0000o3-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 13:28:16 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AHU8B10661;
	Tue, 10 Jun 2003 13:30:08 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AHT1B10607
	for <lemonade@optimus.ietf.org>; Tue, 10 Jun 2003 13:29:01 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10142
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 13:28:55 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pmta-0000n4-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 13:26:54 -0400
Received: from champdsl-25-66.mcleodusa.net ([216.43.25.66] helo=episteme-software.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PmtZ-0000mo-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 13:26:53 -0400
Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with
 ESMTP (Eudora Internet Mail Server X 3.2.2b1);
 Tue, 10 Jun 2003 12:28:22 -0500
Mime-Version: 1.0
X-Sender: resnick@resnick1.qualcomm.com
Message-Id: <p06001417bb0ba02445e7@[216.43.25.67]>
In-Reply-To: <Pine.NXT.4.56.0306092112530.11845@Ikkoku-Kan.Panda.COM>
References: <3EE4C3EB.A8A32ABE@sun.com>
 <a06001406bb0a7f742ef1@[10.10.0.150]>
 <Pine.NXT.4.56.0306091132430.11845@Ikkoku-Kan.Panda.COM>
 <p06001410bb0a97292a4e@[216.43.25.67]>
 <Pine.WNT.4.60.0306091433020.924@Tomobiki-Cho.CAC.Washington.EDU>
 <p06001411bb0ae3b51b57@[216.43.25.67]>
 <Pine.NXT.4.56.0306092112530.11845@Ikkoku-Kan.Panda.COM>
X-Mailer: Eudora [Macintosh version 6.0a15]
Date: Tue, 10 Jun 2003 12:28:20 -0500
To: Mark Crispin <mrc@CAC.Washington.EDU>
From: Pete Resnick <presnick@qualcomm.com>
Subject: RE: [lemonade] Life on the List, and Vienna
Cc: lemonade@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

[Mark: I am trying very hard to keep this from being personal and 
rather make these arguments solely on technical grounds. You seem to 
be doing everything to do exactly the opposite. Where I can, I have 
cut out the personal attacks you made in the text below. Please try 
and avoid the personalization in the future.]

On 6/9/03 at 10:28 PM -0700, Mark Crispin wrote:

>On Mon, 9 Jun 2003, Pete Resnick wrote:
>>I'm sorry, I simply don't see the hole.
>
>The whole is that a large and very complicated process (a message 
>composer), not to mention an SMTP client, neither of which have 
>anything to do with message access, are now running on the IMAP 
>server machine with unlimited access to mailbox data.

- How does the message composer constitute a security hole?

- Having the SMTP client means that anything that already has access 
to the server can send its data through SMTP. How is this a 
significantly larger security hole than having IMAP access to the 
server? And how is it significantly larger compared to giving an 
entirely new process (i.e., the submit server) a completely different 
avenue to get data from the server?

>>>>You want to be able to grant it access to the particular MIME 
>>>>parts needed to compose this message, and then only given it 
>>>>access for a small period of time.
>>>Yes.  This would not be required, but would be highly desirable.
>>I can't see the security considerations section of that document 
>>not requiring it.
>
>Why?  It only matters if the IMAP server does not trust the submit 
>server. There will be many environments in which such trust will 
>exist.

We have been repeatedly beat up for having security considerations 
sections which allow for "insecure behavior so long as there is 
out-of-band trust". I don't think such a thing is going to fly 
(though perhaps it will be implemented that way.)

>>Or are SMTP servers are going to be given "special" (i.e., easier) 
>>access to the IMAP server?
>
>That is *exactly* what is being proposed.  These tokens will carry 
>their own access authorization credentials.

So, the authorization for SMTP servers is going to be *weaker* than 
the authorization for users of the system. That seems like a bad plan.

[WRT overhead]
>>-The authentication step is a wash
>
>There is no "authentication step".

Of course I meant "authorization". Sorry.

>You are disregarding the overhead of actually building the message; 
>this is something that is fundamentally different than anything else 
>that an IMAP server does.  A submit server, on the other hand, 
>already has to know how to build messages.

Unless this is simply referring to the ability to fix up the 
top-level headers of a message, many submit servers know *nothing* 
about how to build messages, so this would be entirely new code 
(along with the ability to retrieve parts from the IMAP server). 
Furthermore, most submit server never do build messages (since they 
are often built correctly by submission clients anyway), hence the 
overhead differential (which is what this whole section is talking 
about) would be much greater.

>>I am not so confident that (a) we can design this in a rock-solid 
>>way *and* (b) people will not screw up the implementations of it. I 
>>would certainly like to see a design before I would call it "easily 
>>solved".
>
>Are you really saying that we don't know how to sign a piece of text 
>in a way that, when we subsequently look at it, we can tell whether 
>or not that text was signed by us?

It is much more involved than that. I have to sign something that the 
server needs to keep track of that the server can verify when it is 
handed this piece of text by a third party. I certainly see how it 
*could* be done. What I'm not sure of is where all of the security 
risks are with such a scheme. It is much clearer to me what the risks 
are from giving an IMAP server access to an SMTP port.

>So how do you propose sending a message which contains data from 
>multiple IMAP servers with your single pipe?

If, by "multiple IMAP servers" you mean "multiple IMAP authorized 
sessions", you cannot send the data through a single pipe unless you 
transfer the data between servers. I have never claimed that this 
proposal is more general. However, since the general use case that's 
folks have in mind is the "forward without download" case, I am 
willing to forgo that additional functionality in favor of what I 
view as a simpler model and better security.

>>My IMAP server doesn't need to be concerned with the rest of the SMTP service
>
>So why do you want it to have an SMTP client?

Somewhere in either proposal there is going to have to be an 
interface between IMAP and SMTP. For the "SMTP-server-does-the-work" 
proposal, it's when the SMTP server accesses the IMAP server. For the 
"IMAP-server-does-the-work" proposal, it's where the IMAP server uses 
it's SMTP client. Am I missing something in this question?

>What you call a "collected FETCH" is an 2822/MIME formatted message. 
>Building such a thing requires an extensive body of software which 
>is not in IMAP servers today.

I will leave it to others to judge whether the "extensive body of 
software" will be significantly larger for IMAP servers or for SMTP 
servers.

>>...the consumers of LEMONADE are going to want other changes in 
>>their IMAP servers anyway, so there is no particular advantage in 
>>having the ability to use off-the-shelf IMAP servers.
>
>Oh?  So you're saying that you want to build mobile devices that 
>won't work with the installed base?

Well, this is a completely different topic, but the answer is 
"maybe". This is the whole issue of point 3 in the charter. All of 
the interactions between such servers and clients will be perfectly 
legal IMAP, but the clients will not have to support some optional 
behavior in servers that current clients must account for.

>Are you trying to build a useful product, or is this something 
>useless like the cell phone web browsers?

Please try to discuss and understand the issue before resorting to 
purposeful baiting like the above.

>So, in order to have a no-op SMTP server...

No, not a no-op SMTP server. It has to support all of the *SMTP* 
functionality of routing, queuing, forwarding, etc. (unlike a simple 
SMTP submission client), but we don't have to (in the language of the 
below) "make huge changes to SMTP."

>you want to make huge changes in IMAP?

It is yet to be determined how huge the changes are. And please 
separate out "changes to the IMAP protocol" from "changes to any 
particular implementation of an IMAP server".

>And what if the text isn't in IMAP?  Suppose it's on a POP3 server? 
>Or an NNTP server?

Absolutely, those are not addressed by the proposal. I am inclined 
not to boil the ocean, especially when the requirement we are really 
trying to address is "forward without download."

>>I have yet to hear a convincing case for why the threat model is 
>>*worse* in this case. Please explain.
>
>Composing a message requires buffers.  The composer has to do 
>substantial reformatting in order to ensure that the text complies 
>with SMTP.  The reformatting can result in text that is 
>substantially larger than the source.  The composer also has to be 
>capable of negotiating SMTP, and of handling the error responses 
>(which also require buffers).
>
>All of these are places in which a single faulty consideration can 
>cause a buffer overflow.

And how is this in any way different in the other proposal? Aren't 
*those* security risks identical?

>A fundamental part of security is isolation of function.

Exactly right. There are three functions which have to be accomplished here:

1. Grab a bunch of parts
2. Take those parts and fit them into a template of an 822/MIME message
3. Send that message out through SMTP

An IMAP server already has #1, so sharing that function with  a 
submit server is worsening the isolation situation. Neither service 
has #2, and I would suggest that keeping it with the data retrieval 
engine is better than moving it over to the delivery end of things. 
So it really comes down to #3 being the one place where you have an 
de-isolation of function, and I think that's a pretty contained case.

>I also have to consider your comments in light of your past 
>statements with regard to IMAP.  I remember quite a bit of criticism 
>by you to the effect that IMAP has "too much" functionality compared 
>to POP.

[My apologies to the rest of you for popping out of "de-personalize" mode.]

Your silly characterization of my opinions of IMAP aside (of which 
you have scant little real knowledge), please *don't* try to predict 
what my statements mean in light of what you *think* my opinion of 
IMAP is. Let's have a technical discussion here, not some really bad 
attempt to divine each other's motives. Assume I mean what I say.

>Note that I am not claiming that your model won't work.  I am 
>claiming that your model is functionally limited (no way to 
>incorporate data from other sources)

A point with which I agree.

>puts a substantial added burden on IMAP servers

A point which I think is open for debate.

>with potential security implications

A point with which I complete disagree (insofar as we do a 
comparative analysis of the security risks of each model).

>and damages the IMAP architecture

I have now repeatedly asked for explanation of this supposed 
architectural damage and its impacts. I am still waiting for such an 
explanation.

>You on the other hand are going to great efforts to try to claim 
>that my model won't work, can't work, and shouldn't work.  For some 
>reason, you very much want to force this on IMAP.  You are refusing 
>to consider an alternative?

This is utter nonsense. I have never argued that the other model 
won't work. (I am quite confident it will.) I have only argued that 
it is fraught with security considerations that I don't think have 
been adequately addressed, that it is a much more complicated model 
that has many more changes to the architecture of a submission 
service than it does to an IMAP service, and that it is therefore not 
worth pursuing.

>Why?  You are getting the strongest possible pushback of "we don't 
>want to do it this way."

No, I am getting the strongest possible pushback that *you* don't 
want to do it this way. I have seen other feedback giving preferences 
for each model. (Please, just make the arguments. Don't try to 
justify them by trying to say that there is some collective "we". 
That's just hand-waving.)

>Why not consider another way?

I think that my extensive argument here gives ample evidence that I 
have given the other proposal a great deal of consideration.

>Why does this offend you?

It does not in the least offend me. I have serious technical concerns about it.

>I can tell you why your proposal offends us; it violates the 
>fundamental scope of IMAP.  And at least two of the major IMAP 
>server implementors are terrified of its implications.

I'm sorry, but who is this other IMAP implementor who is "terrified" 
and "offended". I find nothing on the list with such an indication.

>>>Your proposal would, for the first time, require that an IMAP 
>>>server be in the business of building RFC 2822/MIME compliant 
>>>mesages from input which is not strictly compliant,
>>"Not strictly compliant"? Explain please.
>
>By definition, a submit server can accept messages that lack such 
>things as Date:, From:, Message-ID:, etc.

And where would the IMAP server encounter such input in this 
scenario? Are you simply saying that the IMAP server might have to 
fix up the date and unqualified domain names?

>>>including assembly of those messages with data from the mail store.
>>Yup. Seems to me much simpler code to put into an IMAP server than 
>>to put into a submit server.
>
>At least two IMAP server developers don't agree with that assessment.

Well, at least one. I'm waiting to hear from another.

>Now, when you have message composition done by a server, that means 
>that that sensitive code has to be somewhere.  You seem to want it 
>to be in an IMAP server.

Yup.

>We...

You...

>...observing that the state of submit (as opposed to SMTP) is rather 
>embryonic, believe that it belongs in the submit server.

So your belief is that we should introduce an IMAP client and a 
message composition function into the submit service because it is a 
*less* mature and tested service? (Again, we're talking protocol 
here, not particular implementations.) I'd like some more explanation 
of why that makes it a good idea.

>Not only that, but we feel that the submit server is going to have 
>that capability sooner or later in any case.

So the bet is that submit servers are going to have to do full 
message composition anyway. An interesting wager, but I'm not 
convinced this is the direction things are going.

>So, the obvious question is, why duplicate the same thing in IMAP? 
>Is it as a temporary hack, to avoid having to think about building a 
>submit server (such as was done XSND or whatever it was called was 
>in qpopper)?

Instead of characterizing it as a "quick hack", let's try it in a 
less loaded way:

Is the desire to have a composition facility built on top of IMAP for 
the limited functionality of composing a message containing parts in 
the message store, or is the desire to have a full-blown composition 
facility that allows the composition of parts from various places? As 
I said above, I think the former is straightforward and the latter is 
trying to boil the ocean.

>Why bloat IMAP into such an unwieldy mess that it collapses under 
>its own weight?

Why resort to unsubstantiated hyperbole?

>>Again, what's the horrible impact here of not "keeping IMAP out of 
>>the MTA business"?
>
>Why, after 20 or so years of opposition by both the POP and IMAP 
>communities against being in the MTA business, are we still 
>discussing this?

Leaving POP out of this (since it doesn't have a facility for "upload 
this message to my server"), I'll again ask for an answer instead of 
the histrionics about the Democratic party.

>We don't need this to accomplish the requirement.

No, it's not necessary. It is sufficient. Why is it an architectural problem?

>>>There is also another security hole in your model that I just 
>>>realized. Any submit request from the mobile client which contains 
>>>incoming message data could contain IMAP-submit pointers.  Oops. 
>>>The client would have to be extremely careful to scan for this, 
>>>and the server would also have to have to be careful.
>>Or we could simply make the "auto-expand" part of this only work in 
>>the "Draft" or other special "Composition" mailbox. Not exactly a 
>>hard thing to avoid.
>
>That doesn't fix the problem.
>
>Consider "reply including replied-to text".  Consider that text being HTML.

I don't get it. Please explain.

pr
-- 
Pete Resnick <mailto:presnick@qualcomm.com>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Tue Jun 10 13:40:39 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10394
	for <lemonade-archive@odin.ietf.org>; Tue, 10 Jun 2003 13:40:39 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5AHeC511985
	for lemonade-archive@odin.ietf.org; Tue, 10 Jun 2003 13:40:12 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AHeCB11982
	for <lemonade-web-archive@optimus.ietf.org>; Tue, 10 Jun 2003 13:40:12 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10370
	for <lemonade-web-archive@ietf.org>; Tue, 10 Jun 2003 13:40:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pn4P-0000r2-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 13:38:05 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pn4O-0000qz-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 13:38:04 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AHe2B11952;
	Tue, 10 Jun 2003 13:40:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AHdBB11895
	for <lemonade@optimus.ietf.org>; Tue, 10 Jun 2003 13:39:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10337
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 13:39:07 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pn3Q-0000qT-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 13:37:04 -0400
Received: from mxout5.cac.washington.edu ([140.142.32.135])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pn3P-0000qN-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 13:37:03 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139])
	by mxout5.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h5AHd5t7014052;
	Tue, 10 Jun 2003 10:39:05 -0700
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
	(authenticated bits=0)
	by smtp.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h5AHd4Q0018424
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Tue, 10 Jun 2003 10:39:04 -0700
Date: Tue, 10 Jun 2003 10:39:06 -0700 (Pacific Daylight Time)
From: Mark Crispin <MRC@CAC.Washington.EDU>
To: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
cc: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: RE: [lemonade] Re: IMAP  as submit server and SPAM
In-Reply-To: <54E40201497DF142B06B27255953F79705BFD86E@il0015exch007u.ih.lucent.com>
Message-ID: <Pine.WNT.4.60.0306101036070.2760@Tomobiki-Cho.CAC.Washington.EDU>
References: <54E40201497DF142B06B27255953F79705BFD86E@il0015exch007u.ih.lucent.com>
Organization: Networks & Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Tue, 10 Jun 2003, Vaudreuil, Greg M (Greg) wrote:
> Comparing the two options in light of the Lemonade requirements for efficiency over costly, high-latency links.

You've given an argument for creating a better submit protocol than SMTP,
but not for making IMAP be that submit protocol.

-- 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 mailnull@www1.ietf.org  Tue Jun 10 13:42:39 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10489
	for <lemonade-archive@odin.ietf.org>; Tue, 10 Jun 2003 13:42:39 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5AHgDQ12132
	for lemonade-archive@odin.ietf.org; Tue, 10 Jun 2003 13:42:13 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AHgDB12127
	for <lemonade-web-archive@optimus.ietf.org>; Tue, 10 Jun 2003 13:42:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10446
	for <lemonade-web-archive@ietf.org>; Tue, 10 Jun 2003 13:42:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pn6L-0000sG-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 13:40:06 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pn6L-0000sD-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 13:40:05 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AHg1B12094;
	Tue, 10 Jun 2003 13:42:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AHffB12073
	for <lemonade@optimus.ietf.org>; Tue, 10 Jun 2003 13:41:41 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10433
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 13:41:37 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pn5q-0000rx-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 13:39:34 -0400
Received: from mxout1.cac.washington.edu ([140.142.32.134])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pn5p-0000ru-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 13:39:33 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9])
	by mxout1.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h5AHfYRG004357;
	Tue, 10 Jun 2003 10:41:35 -0700
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
	(authenticated bits=0)
	by smtp.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h5AHfY7k015176
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Tue, 10 Jun 2003 10:41:34 -0700
Date: Tue, 10 Jun 2003 10:41:36 -0700 (Pacific Daylight Time)
From: Mark Crispin <MRC@CAC.Washington.EDU>
To: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
cc: lemonade@ietf.org
Subject: RE: [lemonade] Re: IMAP as a submit server
In-Reply-To: <54E40201497DF142B06B27255953F79705BFD86F@il0015exch007u.ih.lucent.com>
Message-ID: <Pine.WNT.4.60.0306101039160.2760@Tomobiki-Cho.CAC.Washington.EDU>
References: <54E40201497DF142B06B27255953F79705BFD86F@il0015exch007u.ih.lucent.com>
Organization: Networks & Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Tue, 10 Jun 2003, Vaudreuil, Greg M (Greg) wrote:
> - What happens if the body is deleted off the IMAP server before the
> external component is resolved by the submit server?  How is this race
> condition resolved?  (use case: User forwards big message and then
> deletes the original)

IMAP-as-submit has the same race.

More specifically, the same thing that happens if the body is deleted from
the IMAP server between the time that the IMAP-as-submit client gets the
idea to make the request and the request is actually processed.  IMAP is
asynchronous, and there can be multiple simultaneous IMAP sessions.

-- 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 mailnull@www1.ietf.org  Tue Jun 10 13:49:40 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10727
	for <lemonade-archive@odin.ietf.org>; Tue, 10 Jun 2003 13:49:40 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5AHnE012489
	for lemonade-archive@odin.ietf.org; Tue, 10 Jun 2003 13:49:14 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AHnDB12486
	for <lemonade-web-archive@optimus.ietf.org>; Tue, 10 Jun 2003 13:49:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10710
	for <lemonade-web-archive@ietf.org>; Tue, 10 Jun 2003 13:49:09 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PnD8-0000w3-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 13:47:06 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PnD7-0000w0-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 13:47:05 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AHn2B12473;
	Tue, 10 Jun 2003 13:49:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AHmcB12454
	for <lemonade@optimus.ietf.org>; Tue, 10 Jun 2003 13:48:38 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10693
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 13:48:34 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PnCZ-0000vl-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 13:46:31 -0400
Received: from champdsl-25-66.mcleodusa.net ([216.43.25.66] helo=episteme-software.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PnCY-0000vU-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 13:46:30 -0400
Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with
 ESMTP (Eudora Internet Mail Server X 3.2.2b1);
 Tue, 10 Jun 2003 12:48:02 -0500
Mime-Version: 1.0
X-Sender: resnick@resnick1.qualcomm.com
Message-Id: <p06001419bb0bc963f08d@[216.43.25.67]>
In-Reply-To: 
 <Pine.WNT.4.60.0306101039160.2760@Tomobiki-Cho.CAC.Washington.EDU>
References: 
 <54E40201497DF142B06B27255953F79705BFD86F@il0015exch007u.ih.lucent.com>
 <Pine.WNT.4.60.0306101039160.2760@Tomobiki-Cho.CAC.Washington.EDU>
X-Mailer: Eudora [Macintosh version 6.0a15]
Date: Tue, 10 Jun 2003 12:48:01 -0500
To: Mark Crispin <MRC@CAC.Washington.EDU>
From: Pete Resnick <presnick@qualcomm.com>
Subject: RE: [lemonade] Re: IMAP as a submit server
Cc: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>, lemonade@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On 6/10/03 at 10:41 AM -0700, Mark Crispin wrote:

>On Tue, 10 Jun 2003, Vaudreuil, Greg M (Greg) wrote:
>>- What happens if the body is deleted off the IMAP server before 
>>the external component is resolved by the submit server?  How is 
>>this race condition resolved?  (use case: User forwards big message 
>>and then deletes the original)
>
>IMAP-as-submit has the same race.
>
>More specifically, the same thing that happens if the body is 
>deleted from the IMAP server between the time that the 
>IMAP-as-submit client gets the idea to make the request and the 
>request is actually processed.  IMAP is asynchronous, and there can 
>be multiple simultaneous IMAP sessions.

But an IMAP server could note the reference to the body from the 
to-be-sent message and not "really" delete that body until the 
reference count gets to zero. Or it could immediately copy the part 
upon upload of the to-be-sent message if it really had no other 
choice. But the submit server has no such knowledge and therefore is 
SOL if the body part disappears asynchronously.
-- 
Pete Resnick <mailto:presnick@qualcomm.com>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Tue Jun 10 14:28:41 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11697
	for <lemonade-archive@odin.ietf.org>; Tue, 10 Jun 2003 14:28:41 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5AISFI14930
	for lemonade-archive@odin.ietf.org; Tue, 10 Jun 2003 14:28:15 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AISFB14927
	for <lemonade-web-archive@optimus.ietf.org>; Tue, 10 Jun 2003 14:28:15 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11687
	for <lemonade-web-archive@ietf.org>; Tue, 10 Jun 2003 14:28:10 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pnot-0001Ad-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 14:26:08 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pnot-0001AY-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 14:26:07 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AIS2B14906;
	Tue, 10 Jun 2003 14:28:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AIRHB14872
	for <lemonade@optimus.ietf.org>; Tue, 10 Jun 2003 14:27:17 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11637
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 14:27:12 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pnnx-0001A4-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 14:25:09 -0400
Received: from iere.net.avaya.com ([198.152.12.101])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pnnw-0001A1-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 14:25:08 -0400
Received: from iere.net.avaya.com (localhost [127.0.0.1])
	by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id h5AIO1M07701
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 14:24:01 -0400 (EDT)
Received: from bighorn.dr.avaya.com (h135-9-1-59.avaya.com [135.9.1.59])
	by iere.net.avaya.com (8.11.2/8.9.3) with SMTP id h5AIO0f07692;
	Tue, 10 Jun 2003 14:24:00 -0400 (EDT)
Received: from avaya.com by bighorn.dr.avaya.com (SMI-8.6/EMS-1.5 sol2)
	id MAA28122; Tue, 10 Jun 2003 12:27:10 -0600
Message-ID: <3EE6229D.9050109@avaya.com>
Date: Tue, 10 Jun 2003 12:25:33 -0600
From: Rick Block <rickblock@avaya.com>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Pete Resnick <presnick@qualcomm.com>
CC: Mark Crispin <MRC@CAC.Washington.EDU>,
        "Vaudreuil, Greg M (Greg)"
 <gregv@lucent.com>, lemonade@ietf.org
Subject: Re: [lemonade] Re: IMAP as a submit server
References: <54E40201497DF142B06B27255953F79705BFD86F@il0015exch007u.ih.lucent.com> <Pine.WNT.4.60.0306101039160.2760@Tomobiki-Cho.CAC.Washington.EDU> <p06001419bb0bc963f08d@[216.43.25.67]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Does the "IMAP as submit protocol" proposal imply that clients
using it will use two different submit protocols, IMAP for
messages containing bits of others and SMTP for messages
originated in toto by the client?

It seems to me either the answer to this question is:

yes, in which case I would think the client developers would
not be very happy (two different protocols for submitting
messages, based on the context of the composition?)

or

no, in which case it would seem the IMAP "submit" capabilities
must be a superset of SMTP (for example, it would seem
IMAP submit would have to support the client side of quota
if not lemonade's quota by media)

In addition, what shall an IMAP server do if an SMTP submit
it's been requested to do (via some new IMAP operation) fails,
or will the IMAP server be required to do the resultant SMTP
submit synchronously so any SMTP error can be conveyed back
to the original client with an IMAP response?

I understand the appeal of an IMAP submit mechanism, but it
seems this effectively requires completely merging IMAP and SMTP.
Perhaps we should be talking about an entirely new protocol that
really is a combination of IMAP and SMTP and could be implemented
by a server that effectively proxies independent (regular) IMAP
and SMTP sessions.

Rick Block
Avaya Inc.

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



From mailnull@www1.ietf.org  Tue Jun 10 14:31:39 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11877
	for <lemonade-archive@odin.ietf.org>; Tue, 10 Jun 2003 14:31:39 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5AIVD715180
	for lemonade-archive@odin.ietf.org; Tue, 10 Jun 2003 14:31:13 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AIVDB15177
	for <lemonade-web-archive@optimus.ietf.org>; Tue, 10 Jun 2003 14:31:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11849
	for <lemonade-web-archive@ietf.org>; Tue, 10 Jun 2003 14:31:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pnrl-0001C8-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 14:29:05 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pnrl-0001C5-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 14:29:05 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AIV2B15155;
	Tue, 10 Jun 2003 14:31:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AIU0B15029
	for <lemonade@optimus.ietf.org>; Tue, 10 Jun 2003 14:30:00 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11733
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 14:29:55 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pnqa-0001BK-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 14:27:52 -0400
Received: from inet-consulting.com ([4.23.9.166] helo=royer.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PnqZ-0001BH-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 14:27:51 -0400
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h5AITfbt029619
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 11:29:50 -0700
Message-ID: <3EE62387.7000801@Royer.com>
Date: Tue, 10 Jun 2003 12:29:27 -0600
From: Doug Royer <Doug@Royer.com>
Reply-To: lemonade@ietf.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: lemonade@ietf.org
Subject: Re: [lemonade] Re: IMAP as a submit server
References: <54E40201497DF142B06B27255953F79705BFD86F@il0015exch007u.ih.lucent.com> <Pine.WNT.4.60.0306101039160.2760@Tomobiki-Cho.CAC.Washington.EDU>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060004030403000407010808"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This is a cryptographically signed message in MIME format.

--------------ms060004030403000407010808
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Mark Crispin wrote:
> On Tue, 10 Jun 2003, Vaudreuil, Greg M (Greg) wrote:
> 
>>- What happens if the body is deleted off the IMAP server before the
>>external component is resolved by the submit server?  How is this race
>>condition resolved?  (use case: User forwards big message and then
>>deletes the original)
> 
> 
> IMAP-as-submit has the same race.
 >
> More specifically, the same thing that happens if the body is deleted from
> the IMAP server between the time that the IMAP-as-submit client gets the
> idea to make the request and the request is actually processed.  IMAP is
> asynchronous, and there can be multiple simultaneous IMAP sessions.

Currently that problem already exists in IMAP servers. It has nothing
to do with if IMAP is also a submit server. Currently one session could
delete a message while another session uploads it. I'll bet all IMAP
servers have a instance counting or message locking code to deal with
this problem already.



-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  Doug@Royer.com                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

--------------ms060004030403000407010808
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC
A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j
cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB
MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T
BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN
VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre
qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+
5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA
MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg
TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD
QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx
ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz
IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq
hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34
1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA
gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK
YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd
SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC
AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF
BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl
cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl
IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs
MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq
1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2
TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail
MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE
AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO
b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG
MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD
VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV
BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv
43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y
lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP
D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn
0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK
bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg
hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT
IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI
AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t
L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk
OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW
yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1
MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl
ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTAxODI5MjhaMCMGCSqGSIb3DQEJBDEWBBRq
rY7N7TmV4TEb7qDgpdpBaGEruDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL
KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAajfyqt1aaW95
E2ux2Iz70ZT44e+zeCrVSrQVQLp9jQ0UNIfT3Pun/X+MtKRddTU/JA7rLuPpoGBm8yKPSJww
H+Lww3ptIrgmxSp2iBVBTD7d3thyrwIWPQ05UpYGsgwElK5thIR0XSJEUWNf6q7QT7n42eTk
/4ccuYcERrrECXviwGUI8+qlaktPrOuxhVtW1RK3Bljlkmyp/gpbbbRmrA+D4Ql60iUZ9dQ7
OKXRtnD80BUaO13kpZogoUoixUuiqhCWgF5xd+vj0DbNmxyIbLiNxL2DuDzMqP+03KS+LNGG
XZ0/DL5XpiAxub/vSLMkolh04nZb40dDN46bEnRPRwAAAAAAAA==
--------------ms060004030403000407010808--

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



From mailnull@www1.ietf.org  Tue Jun 10 15:00:41 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12704
	for <lemonade-archive@odin.ietf.org>; Tue, 10 Jun 2003 15:00:41 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5AJ0H017236
	for lemonade-archive@odin.ietf.org; Tue, 10 Jun 2003 15:00:17 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AJ0GB17233
	for <lemonade-web-archive@optimus.ietf.org>; Tue, 10 Jun 2003 15:00:16 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12693
	for <lemonade-web-archive@ietf.org>; Tue, 10 Jun 2003 15:00:10 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PoJs-0001NB-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 14:58:08 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PoJr-0001N8-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 14:58:07 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AJ03B17211;
	Tue, 10 Jun 2003 15:00:03 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AIxtB17166
	for <lemonade@optimus.ietf.org>; Tue, 10 Jun 2003 14:59:55 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12667
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 14:59:49 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PoJW-0001N4-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 14:57:46 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PoJV-0001N1-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 14:57:45 -0400
Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148])
	by ithilien.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h5AItwfE003450;
	Tue, 10 Jun 2003 11:55:58 -0700 (PDT)
Received: from [10.10.0.150] (vpn-10-50-0-75.qualcomm.com [10.50.0.75])
	by magus.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h5AIsmsh012351;
	Tue, 10 Jun 2003 11:55:14 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <a06001419bb0bd955d357@[10.10.0.150]>
In-Reply-To: <2147483647.1055248615@socrates.cyrusoft.com>
References: 
 <4A3384433CE2AB46A63468CB207E209D59E327@zoe.office.snowshore.com >
 <639142451.20030609110140@openwave.com>
 <1055187322.3665.2.camel@localhost.localdomain>
 <3EE4E2B5.49BB0A80@sun.com> <a0600140dbb0a9a3c75d7@[10.10.0.150]>
 <Pine.WNT.4.60.0306091407580.924@Tomobiki-Cho.CAC.Washington.EDU>
 <172316146.20030609151214@openwave.com> <3EE509D4.3040109@Royer.com>
 <a06001413bb0afefcd3bf@[10.10.0.150]>
 <2147483647.1055248615@socrates.cyrusoft.com>
X-Mailer: Eudora for Mac OS X v6.0a
Date: Tue, 10 Jun 2003 14:54:43 -0400
To: Cyrus Daboo <daboo@cyrusoft.com>, Randall Gellens <randy@qualcomm.com>,
        "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
From: Randall Gellens <randy@qualcomm.com>
Subject: Re: [lemonade] Re: Just 'ATTACH'
Cc: Doug Royer <Doug@royer.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b25
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

Hi Cyrus,

At 12:36 PM -0400 6/10/03, Cyrus Daboo wrote:

>  Hi Randall,
>
>  --On Monday, June 9, 2003 11:24 PM -0400 Randall Gellens 
> <randy@qualcomm.com> wrote:
>
>  |>  SMTP commands can not be embedded into the DATA stream. So I do not
>  |>  think an ATTACH SMTP command will work. Although most MUAs display
>  |>  'attachments' in a separate pane, they are inline in just about any
>  |>  random order.
>  |
>  | We would be creating a new Submit extension mechanism.  Such a mechanism
>  | could be as simple as saying 'expand references external body parts that
>  | have the "expand" flag set'.  Note that during the discussions on
>  | developing a separate SMTP submit service from the SMTP relay service, it
>  | was suggested that future Submit extensions that were only useful for
>  | message submission should perhaps look quite different from SMTP
>  | extensions, to prevent them from leaking into SMTP relay.  One example
>  | would be a kind of envelope wrapping the transaction.  At the time, there
>  | was discussion of using a Submit service for various sorts of helpful
>  | things, including transcoding of voice attachments, creating a proper
>  | message, etc.
>
>  Can we have a clear statement of what exactly needs to be expanded 
> for this application? The two possibilities I see right now are:
>
>  1) Expand entire MIME parts by substituting data from an outside 
> source: external-body expansion.

This is what has been discussed to date, as far as I recall.

>
>  2) Expand inline data (e.g. quotations in a reply or forward).

I don't recall hearing of this before the most recent series of 
emails.  As far as I know this type of detailed composition server is 
not a requirement, because presumably the client would be capable of 
at least this level of composition.

>  The former is relatively easy to do - just substituting one MIME 
> part for another.
>
>  The later is much more complicated as it requires detailed 
> knowledge of the data itself. This really requires a full-blown 
> 'composition agent' that knows how to deal with character set and 
> encoding issues for all components of the data being expanded, as 
> well as data format issues (e.g. knows how to put together HTML 
> fragments in a consistent manner). That definitely goes beyond 
> anything that either SMTP or IMAP has had to do up till now.
>
>  If (2) is a requirement then I'd be more inclined to go with a 
> third server option that has not been discussed much - namely 
> having a new type of server a 'message composition server' that has 
> all the logic and capability of a typical desktop MUA in terms of 
> building rfc2822/MIME messages as well as the ability to pull in 
> data from external sources (with an appropriate security model). As 
> well as providing pointers to the source components of the message, 
> the client of this server would also be able to specify the 
> destination, which might be an IMAP server or an SMTP server or 
> some other destination in a similar manner to IMAP CHANNEL. Has 
> this third server option been ruled out for any reason?

If this type of composition service is required, then I'd tend to 
agree with you that it goes far beyond current IMAP or Submission 
capabilities and would need a new server, part of a full-blown split 
client mode.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
There once was a hacker named Ken
Who inherited truckloads of Yen
        So he built him some chicks
        Of silicon chips
And hasn't been heard from since then.
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Tue Jun 10 15:02:37 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12830
	for <lemonade-archive@odin.ietf.org>; Tue, 10 Jun 2003 15:02:37 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5AJ2Do17435
	for lemonade-archive@odin.ietf.org; Tue, 10 Jun 2003 15:02:13 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AJ2DB17432
	for <lemonade-web-archive@optimus.ietf.org>; Tue, 10 Jun 2003 15:02:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12823
	for <lemonade-web-archive@ietf.org>; Tue, 10 Jun 2003 15:02:07 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PoLk-0001Om-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 15:00:04 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PoLj-0001Oj-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 15:00:03 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AJ21B17419;
	Tue, 10 Jun 2003 15:02:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AJ1xB17392
	for <lemonade@optimus.ietf.org>; Tue, 10 Jun 2003 15:01:59 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12809
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 15:01:52 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PoLW-0001OR-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 14:59:50 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PoLV-0001OO-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 14:59:49 -0400
Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151])
	by numenor.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h5AJ1nPM010913
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Tue, 10 Jun 2003 12:01:50 -0700 (PDT)
Received: from [10.10.0.150] (vpn-10-50-0-75.qualcomm.com [10.50.0.75])
	by crowley.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h5AJ16ix008137;
	Tue, 10 Jun 2003 12:01:19 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <a0600141abb0bda8f1cfa@[10.10.0.150]>
In-Reply-To: 
 <54E40201497DF142B06B27255953F79705BFD86E@il0015exch007u.ih.lucent.com
 >
References: 
 <54E40201497DF142B06B27255953F79705BFD86E@il0015exch007u.ih.lucent.com
 >
X-Mailer: Eudora for Mac OS X v6.0a
Date: Tue, 10 Jun 2003 15:01:01 -0400
To: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>,
        "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
From: Randall Gellens <randy@qualcomm.com>
Subject: RE: [lemonade] Re: IMAP  as submit server and SPAM
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b25
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

At 12:01 PM -0500 6/10/03, Greg M (Greg) Vaudreuil wrote:

>  Using IMAP-Submit
>
>  1) Client posts message to outbox, client annotates message with 
> SMTP envelope in pipeline, receives status in response (1 round 
> trip)

As I recall, we were considering models in which the client would 
append the draft message to the outbox or drafts folder (with 
annotations for desired Submit envelope), and then in a subsequent 
transaction, submit the draft.  This would allow the client to 
maintain the message in a draft state, and so give the user a chance 
to review it later, perhaps from another client.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Do not condemn the judgement of another because it differs from your
own.  You may both be wrong.                              --Dandemis
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Tue Jun 10 15:35:40 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14783
	for <lemonade-archive@odin.ietf.org>; Tue, 10 Jun 2003 15:35:40 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5AJZCn19677
	for lemonade-archive@odin.ietf.org; Tue, 10 Jun 2003 15:35:12 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AJZCB19674
	for <lemonade-web-archive@optimus.ietf.org>; Tue, 10 Jun 2003 15:35:12 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14775
	for <lemonade-web-archive@ietf.org>; Tue, 10 Jun 2003 15:35:10 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Porj-0001Za-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 15:33:08 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Porj-0001ZX-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 15:33:07 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AJZ2B19666;
	Tue, 10 Jun 2003 15:35:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AJYFB19630
	for <lemonade@optimus.ietf.org>; Tue, 10 Jun 2003 15:34:15 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14748
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 15:34:13 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Poqp-0001ZT-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 15:32:11 -0400
Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com)
	by ietf-mx with smtp (Exim 4.12)
	id 19Poqo-0001ZC-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 15:32:10 -0400
Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap 
	 id 24901; Tue, 10 Jun 2003 15:35:14 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Tue, 10 Jun 2003 15:33:43 -0400
Message-ID: <4A3384433CE2AB46A63468CB207E209D59E358@zoe.office.snowshore.com>
Thread-Topic: Internet Draft Important Dates and Working Session
Thread-Index: AcMvhzQPvMpL+Oj1QjCnG6GnwPpviA==
From: "Eric Burger" <eburger@snowshore.com>
To: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5AJYFB19631
Subject: [lemonade] Internet Draft Important Dates and Working Session
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Please be aware of looming Internet Draft dates:

June 23, Monday - Internet Draft Cut-off for initial document (-00) submission at 09:00 ET
June 30, Monday - Internet Draft final submission cut-off at 09:00 ET

* All times are in US Eastern Time 


You MUST have drafts in by that date for consideration in our working session.

I have requested a 2-hour working session in Vienna.  In the *unlikely* event you wish to make a presentation (it is, after all, a working session), please send it to me NO LATER than Tuesday, July 8.

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



From mailnull@www1.ietf.org  Tue Jun 10 15:39:42 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15041
	for <lemonade-archive@odin.ietf.org>; Tue, 10 Jun 2003 15:39:42 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5AJdEw20773
	for lemonade-archive@odin.ietf.org; Tue, 10 Jun 2003 15:39:14 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AJdEB20770
	for <lemonade-web-archive@optimus.ietf.org>; Tue, 10 Jun 2003 15:39:14 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14935
	for <lemonade-web-archive@ietf.org>; Tue, 10 Jun 2003 15:39:11 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Povd-0001bM-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 15:37:09 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Povc-0001bJ-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 15:37:08 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AJd1B20640;
	Tue, 10 Jun 2003 15:39:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AJcFB20607
	for <lemonade@optimus.ietf.org>; Tue, 10 Jun 2003 15:38:15 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14896
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 15:38:13 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Poug-0001ac-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 15:36:10 -0400
Received: from mxout1.cac.washington.edu ([140.142.32.134])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pouf-0001aZ-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 15:36:09 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9])
	by mxout1.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h5AJcBRG027819;
	Tue, 10 Jun 2003 12:38:11 -0700
Received: from Shimo-Tomobiki.Panda.COM (D-140-142-21-46.dhcp4.washington.edu [140.142.21.46])
	(authenticated bits=0)
	by smtp.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h5AJc47k022738
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Tue, 10 Jun 2003 12:38:08 -0700
Date: Tue, 10 Jun 2003 12:38:12 -0700 (Pacific Daylight Time)
From: Mark Crispin <MRC@CAC.Washington.EDU>
To: Pete Resnick <presnick@qualcomm.com>
cc: lemonade@ietf.org
Subject: RE: [lemonade] Life on the List, and Vienna
In-Reply-To: <p06001417bb0ba02445e7@[216.43.25.67]>
Message-ID: <Pine.WNT.4.60.0306101042020.2760@Tomobiki-Cho.CAC.Washington.EDU>
References: <3EE4C3EB.A8A32ABE@sun.com> <a06001406bb0a7f742ef1@[10.10.0.150]>
 <Pine.NXT.4.56.0306091132430.11845@Ikkoku-Kan.Panda.COM>
 <p06001410bb0a97292a4e@[216.43.25.67]> <Pine.WNT.4.60.0306091433020.924@Tomobiki-Cho.CAC.Washington.EDU>
 <p06001411bb0ae3b51b57@[216.43.25.67]> <Pine.NXT.4.56.0306092112530.11845@Ikkoku-Kan.Panda.COM>
 <p06001417bb0ba02445e7@[216.43.25.67]>
Organization: Networks & Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Tue, 10 Jun 2003, Pete Resnick wrote:
> - How does the message composer constitute a security hole?

A message composer, by its nature, has complex buffer management; it is,
in effect, a text editor.  Text in mail can expand (e.g. due to quoting)
to a much larger size than the original.

SMTP clients also have the issue of text that expands to a much larger
size than the original.  There is an additional complication in dealing
with SMTP server responses.

There are ample opportunities for buffer overflows in such a entity.  All
that is needed is for one of these to be missed.  In some IMAP servers,
that would just give access to all the user's mail; in others, it will
give access to all mail.

> - Having the SMTP client means that anything that already has access
> to the server can send its data through SMTP. How is this a
> significantly larger security hole than having IMAP access to the
> server? And how is it significantly larger compared to giving an
> entirely new process (i.e., the submit server) a completely different
> avenue to get data from the server?

First, we're not talking about SMTP; we're talking about submit.  The
current state of the art of submit uses SMTP, but that does not mean that
the two should be confused.

It is a larger security hole to have submit have unlimited access to all
the user's data (and potentially all data for all users) than it is for
submit to be restricted to specific pieces of the user's data.

When submit is part of IMAP, the same entity is both the message composer
and the gatekeeper that purports to restrict the message composer.

> We have been repeatedly beat up for having security considerations
> sections which allow for "insecure behavior so long as there is
> out-of-band trust". I don't think such a thing is going to fly
> (though perhaps it will be implemented that way.)

That is why we are proposing a way to do things securely, and strongly
encouraging that way.  That doesn't mean that it can not be shortcut when
appropriate.

One of the most common questions that I get is "How do I turn off
mandatory SSL/TLS between my web-based IMAP client and the IMAP server?"
And since the connection is going on a secure channel (and often
localhost), this is not an unreasonable request.

> >That is *exactly* what is being proposed.  These tokens will carry
> >their own access authorization credentials.
> So, the authorization for SMTP servers is going to be *weaker* than
> the authorization for users of the system. That seems like a bad plan.

How would it be weaker?  You are not authenticating the submit client as a
particular user with arbitrary data access; you are only authenticating
its access to a particular datum.  Only an entity which has undergone the
authentication with arbitrary data access is capable of creating the token
for particular-datum access.

This is stronger than sending the text over SMTP, and remember that's the
ultimate fate of that text.

> Unless this is simply referring to the ability to fix up the
> top-level headers of a message, many submit servers know *nothing*
> about how to build messages, so this would be entirely new code
> (along with the ability to retrieve parts from the IMAP server).

Submit would also be entirely new code in an IMAP server.

The difference is that it's appropriate for submit code to be added to a
submit server.  An IMAP server has currently nothing to do with submit.

We're not talking about SMTP vs. IMAP servers.  We're talking about submit
vs. IMAP servers.

> Furthermore, most submit server never do build messages (since they
> are often built correctly by submission clients anyway), hence the
> overhead differential (which is what this whole section is talking
> about) would be much greater.

IMAP servers never build messages either.  What overhead differential?

> I am
> willing to forgo that additional functionality in favor of what I
> view as a simpler model and better security.

So, what happens when after we've gone to the effort to do all this
submit-in-IMAP work, and then it turns out that the "simpler model" isn't
good enough?

> Somewhere in either proposal there is going to have to be an
> interface between IMAP and SMTP. For the "SMTP-server-does-the-work"
> proposal, it's when the SMTP server accesses the IMAP server. For the
> "IMAP-server-does-the-work" proposal, it's where the IMAP server uses
> it's SMTP client. Am I missing something in this question?

I reiterate: this is not SMTP.  It is submit.

In "submit-server-does-the-work", the submit server knows how to
access IMAP and other sources.

> >Are you trying to build a useful product, or is this something
> >useless like the cell phone web browsers?
> Please try to discuss and understand the issue before resorting to
> purposeful baiting like the above.

I'm serious.  This has nothing to do with the company where you work; but
it has everything to do with a related case of mobile devices doing what
is expedient rather than what is right.

I've used (or rather tried to use) several cell phone web browsers, and
they all fall short of their promise (to put it mildly).  Once the
"gee-whiz" aspect fades, it dawns on the user that it's cheaper, faster,
and more reliable to use the cell phone as a modem for a laptop to run IE.

I very much would like to see mobile devices fufill their promise rather
than be expensive toys.  I want to see mobile devices become practical
enterprise devices.

> It is yet to be determined how huge the changes are. And please
> separate out "changes to the IMAP protocol" from "changes to any
> particular implementation of an IMAP server".

See above about enterprise devices.  If this isn't widely-adopted, it
becomes restricted to one particular vendor or service provider.  That
isn't an enterprise device.

> >And what if the text isn't in IMAP?  Suppose it's on a POP3 server?
> >Or an NNTP server?
> Absolutely, those are not addressed by the proposal. I am inclined
> not to boil the ocean, especially when the requirement we are really
> trying to address is "forward without download."

I don't see this as boiling the ocean.  It's what people are already doing
today.

> >[Composition in IMAP security holes]
> And how is this in any way different in the other proposal? Aren't
> *those* security risks identical?

No.  Unlike a compromised IMAP server, a compromised submit server would
not have access to any of the other user's data, much less any other
user's data.

This isolation is of critical importance to many people.

> 1. Grab a bunch of parts
> 2. Take those parts and fit them into a template of an 822/MIME message
> 3. Send that message out through SMTP
>
> An IMAP server already has #1, so sharing that function with  a
> submit server is worsening the isolation situation.

No, it makes it better because the submit server loses access to the parts
it doesn't have a right to have.

> Neither service
> has #2

Correct.

> >I also have to consider your comments in light of your past
> >statements with regard to IMAP.  I remember quite a bit of criticism
> >by you to the effect that IMAP has "too much" functionality compared
> >to POP.
> Your silly characterization of my opinions of IMAP aside (of which
> you have scant little real knowledge), please *don't* try to predict
> what my statements mean in light of what you *think* my opinion of
> IMAP is. Let's have a technical discussion here, not some really bad
> attempt to divine each other's motives. Assume I mean what I say.

I am not trying to divine your motives.

I am asking you to reconcile your past statements about how IMAP was too
complex and had too much functionality, with your advocacy today of a
proposal to add substantial new complexity and functionality to IMAP.

I would have thought that you would be aggressively on my side on this,
saying "enough is enough, don't add anything new to IMAP."  I was hoping
that this would be the case; you were a person that I was counting on.  I
am bewildered to find that it isn't.

> >and damages the IMAP architecture
> I have now repeatedly asked for explanation of this supposed
> architectural damage and its impacts. I am still waiting for such an
> explanation.

IMAP is focused on accessing and processing message data.  This, for this
first time, is an operation that is focused on editing and transmitting
data.

The goal of this proposal seems to be to make IMAP be a server-based MUA
(in competition with webmail) fufilling all client needs, rather than an
MUA component.

The component nature of IMAP is desirable.  What goes into an MUA evolves
over time; and by making IMAP be a monolith that necessarily ties IMAP to
a particular state of evolution.

> I have only argued that
> it is fraught with security considerations that I don't think have
> been adequately addressed,

That is unfair.  It is a given that whatever type of token mechanism is
used has to satisfy a checklist of security requirements.  You're
complaining that the checklist hasn't been addressed, when the checklist
doesn't exist yet!

Let's build the checklist first, and then see if there is an answer that
addresses them.  If there isn't, then the proposal collapses.

> that it is a much more complicated model

More complicated, yes, but not much more complicated.

> that has many more changes to the architecture of a submission
> service than it does to an IMAP service

How can you say this?  An IMAP service has none of the aspects of message
composition and assembly.

You seem to be reacting to the idea to use MESSAGE/EXTERNAL-BODY and
saying "well, this requires MIME parsing, which IMAP has".

But what about if instead, it was defined as 0xff is a magic tag.  Two of
them means one 0xff in the message.  Otherwise, it's followed by a pointer
to "insert text using this pointer here".

At this point, IMAP and submit are on an even playing field.

Now, I'm not saying that 0xff magic tags are a good idea.  In fact, that's
a wretched idea.  It's just an example.

> >By definition, a submit server can accept messages that lack such
> >things as Date:, From:, Message-ID:, etc.
> And where would the IMAP server encounter such input in this
> scenario?

In submitted messages.  That's part of how submit differs from SMTP.

> Are you simply saying that the IMAP server might have to
> fix up the date and unqualified domain names?

It may also have to do 8->7 bit conversions, wrap excessively long lines,
and other things to render a submitted message into something that is
acceptable to RFC 2822, MIME, and SMTP.

> So your belief is that we should introduce an IMAP client and a
> message composition function into the submit service because it is a
> *less* mature and tested service?

Not really even an IMAP client.  The access would use SASL; so the client
would only need to know enough about IMAP to negotiate SASL with it.

> Is the desire to have a composition facility built on top of IMAP for
> the limited functionality of composing a message containing parts in
> the message store, or is the desire to have a full-blown composition
> facility that allows the composition of parts from various places? As
> I said above, I think the former is straightforward and the latter is
> trying to boil the ocean.

These are the correct questions to ask:

Is the latter going to happen?  Why or why not?

Will the IETF declare IMAP to be the one true message submission protocol,
and that all future work on message submission is to be done in IMAP?

Is it desirable to have multiple submission protocols in the IETF suite?
If so, how will functional enhancements be coordinated in the multiple
submission protocols?

What happens when users of mobile device email want to incorporate text
from a web page, or from an NNTP server?

What does a user who uses multiple IMAP servers (I am such a user) do?

How do you answer the objections that you are proposing a short-term
facility with acknowledged limitations?

> >Consider "reply including replied-to text".  Consider that text being HTML.
> I don't get it. Please explain.

The user does a reply.  The reply includes replied-to text, which is
interspersed in the reply under composition (thus the mobile device has
that text in its buffer).  The replied-to text contains evil instructions
to the submit server which are hidden in HTML using one of the well-known
tricks.

With an independent submit server, those evil instructions can't
accomplish much; the submit server only does submit and has no access to
data other than what it was specifically granted.  With a submit-in-IMAP
server, those evil instructions have full access to the user's entire mail
store.

There will need to be a major review taken of all aspects of
submit-in-IMAP to ensure that there is no path by which a bad guy's evil
instructions can be passed to a submit-in-IMAP server.  Since people do
things such as reply including replied-to text, this leaves a number of
potential paths open.

The bad guys are out there.  We have reports of cell phones being cracked
via evil SMS messages (of all things!).  We have to assume that they are
going to be far more creative than any of us in dreaming up ways to
subvert whatever facility we build.

Submit, no matter how it is done, will be a new facility.  In one
proposal, submit will have open and unlimited access to all of a user's
mail (and potentially, depending upon the nature of the server, to all
users' mail).  In the other proposal, submit runs in an isolated box, with
no access to any data other than what it was specifically granted.

Yet, the proposal which gives this new facility unlimited access is called
"secure", and the proposal which isolates this new facilty to no more data
than it needs to perform its task is called "boiling the ocean."  Beats me
how that makes sense.

-- 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 mailnull@www1.ietf.org  Tue Jun 10 15:48:39 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15220
	for <lemonade-archive@odin.ietf.org>; Tue, 10 Jun 2003 15:48:39 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5AJmC821227
	for lemonade-archive@odin.ietf.org; Tue, 10 Jun 2003 15:48:12 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AJmBB21224
	for <lemonade-web-archive@optimus.ietf.org>; Tue, 10 Jun 2003 15:48:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15212
	for <lemonade-web-archive@ietf.org>; Tue, 10 Jun 2003 15:48:09 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pp4J-0001f9-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 15:46:07 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pp4I-0001f6-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 15:46:06 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AJm2B21213;
	Tue, 10 Jun 2003 15:48:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AJl1B21179
	for <lemonade@optimus.ietf.org>; Tue, 10 Jun 2003 15:47:01 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15200
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 15:46:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pp3B-0001f0-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 15:44:57 -0400
Received: from mxout4.cac.washington.edu ([140.142.33.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pp3A-0001ex-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 15:44:56 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139])
	by mxout4.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h5AJkwTc029108;
	Tue, 10 Jun 2003 12:46:58 -0700
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
	(authenticated bits=0)
	by smtp.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h5AJkvQ0026791
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Tue, 10 Jun 2003 12:46:57 -0700
Date: Tue, 10 Jun 2003 12:46:59 -0700 (Pacific Daylight Time)
From: Mark Crispin <MRC@CAC.Washington.EDU>
To: Pete Resnick <presnick@qualcomm.com>
cc: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>, lemonade@ietf.org
Subject: RE: [lemonade] Re: IMAP as a submit server
In-Reply-To: <p06001419bb0bc963f08d@[216.43.25.67]>
Message-ID: <Pine.WNT.4.60.0306101239060.2408@Tomobiki-Cho.CAC.Washington.EDU>
References: <54E40201497DF142B06B27255953F79705BFD86F@il0015exch007u.ih.lucent.com>
 <Pine.WNT.4.60.0306101039160.2760@Tomobiki-Cho.CAC.Washington.EDU>
 <p06001419bb0bc963f08d@[216.43.25.67]>
Organization: Networks & Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Tue, 10 Jun 2003, Pete Resnick wrote:
> But an IMAP server could note the reference to the body from the
> to-be-sent message and not "really" delete that body until the
> reference count gets to zero. Or it could immediately copy the part
> upon upload of the to-be-sent message if it really had no other
> choice.

No it can't.  You're making the assumption that the deletion is occuring
in the same IMAP server session as the one doing the submit.  You can't
make that assumption.

Nor can you assume that separate IMAP server sessions can communicate this
information to each other.  There is nothing in the IMAP specification
that requires this.

There is nothing that you can do to prevent the timing race; refer to RFC
2180 for some of the gory details.  All you can do is make it less likely.

-- 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 mailnull@www1.ietf.org  Tue Jun 10 15:53:33 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15343
	for <lemonade-archive@odin.ietf.org>; Tue, 10 Jun 2003 15:53:33 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5AJr5G21455
	for lemonade-archive@odin.ietf.org; Tue, 10 Jun 2003 15:53:05 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AJr5B21452
	for <lemonade-web-archive@optimus.ietf.org>; Tue, 10 Jun 2003 15:53:05 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15330
	for <lemonade-web-archive@ietf.org>; Tue, 10 Jun 2003 15:53:02 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pp92-0001hB-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 15:51:00 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pp91-0001h8-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 15:50:59 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AJr1B21443;
	Tue, 10 Jun 2003 15:53:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AJq1B21360
	for <lemonade@optimus.ietf.org>; Tue, 10 Jun 2003 15:52:01 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15290
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 15:51:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pp80-0001g5-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 15:49:56 -0400
Received: from mxout3.cac.washington.edu ([140.142.32.166])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pp80-0001g2-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 15:49:56 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139])
	by mxout3.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h5AJpuSL001457;
	Tue, 10 Jun 2003 12:51:56 -0700
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
	(authenticated bits=0)
	by smtp.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h5AJpuQ0027082
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Tue, 10 Jun 2003 12:51:56 -0700
Date: Tue, 10 Jun 2003 12:51:58 -0700 (Pacific Daylight Time)
From: Mark Crispin <MRC@CAC.Washington.EDU>
To: Rick Block <rickblock@avaya.com>
cc: Pete Resnick <presnick@qualcomm.com>,
        "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>, lemonade@ietf.org
Subject: Re: [lemonade] Re: IMAP as a submit server
In-Reply-To: <3EE6229D.9050109@avaya.com>
Message-ID: <Pine.WNT.4.60.0306101247360.2408@Tomobiki-Cho.CAC.Washington.EDU>
References: <54E40201497DF142B06B27255953F79705BFD86F@il0015exch007u.ih.lucent.com>
 <Pine.WNT.4.60.0306101039160.2760@Tomobiki-Cho.CAC.Washington.EDU>
 <p06001419bb0bc963f08d@[216.43.25.67]> <3EE6229D.9050109@avaya.com>
Organization: Networks & Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Tue, 10 Jun 2003, Rick Block wrote:
> I understand the appeal of an IMAP submit mechanism, but it
> seems this effectively requires completely merging IMAP and SMTP.

I agree, and especially with the earlier observation that IMAP would have
to be a superset.

> Perhaps we should be talking about an entirely new protocol that
> really is a combination of IMAP and SMTP and could be implemented
> by a server that effectively proxies independent (regular) IMAP
> and SMTP sessions.

This is a possible solution, and actually becomes feasible if it is
specifically oriented towards mobile devices (IMHO it is pointless for
larger devices).

One very desirable aspect of this is that any piece of it (IMAP, SMTP, or
this new protocol) can be replaced without harm to the other two. Or, if
it turns out that a new generation of mobile devices needs something more
powerful, that another proxy protocol can be invented for those; once
again with no harm to IMAP or SMTP.

-- 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 mailnull@www1.ietf.org  Tue Jun 10 15:55:40 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15382
	for <lemonade-archive@odin.ietf.org>; Tue, 10 Jun 2003 15:55:40 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5AJtCs21605
	for lemonade-archive@odin.ietf.org; Tue, 10 Jun 2003 15:55:12 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AJtCB21602
	for <lemonade-web-archive@optimus.ietf.org>; Tue, 10 Jun 2003 15:55:12 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15377
	for <lemonade-web-archive@ietf.org>; Tue, 10 Jun 2003 15:55:10 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PpB5-0001i1-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 15:53:07 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PpB5-0001hy-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 15:53:07 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AJt1B21594;
	Tue, 10 Jun 2003 15:55:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AJsZB21541
	for <lemonade@optimus.ietf.org>; Tue, 10 Jun 2003 15:54:35 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15370
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 15:54:32 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PpAT-0001ht-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 15:52:30 -0400
Received: from mxout1.cac.washington.edu ([140.142.32.134])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PpAT-0001hq-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 15:52:29 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139])
	by mxout1.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h5AJsVRG030637
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 12:54:31 -0700
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
	(authenticated bits=0)
	by smtp.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h5AJsVQ0027205
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT)
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 12:54:31 -0700
Date: Tue, 10 Jun 2003 12:54:33 -0700 (Pacific Daylight Time)
From: Mark Crispin <MRC@CAC.Washington.EDU>
To: lemonade@ietf.org
Subject: Re: [lemonade] Re: IMAP as a submit server
In-Reply-To: <3EE62387.7000801@Royer.com>
Message-ID: <Pine.WNT.4.60.0306101252320.2408@Tomobiki-Cho.CAC.Washington.EDU>
References: <54E40201497DF142B06B27255953F79705BFD86F@il0015exch007u.ih.lucent.com>
 <Pine.WNT.4.60.0306101039160.2760@Tomobiki-Cho.CAC.Washington.EDU>
 <3EE62387.7000801@Royer.com>
Organization: Networks & Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Tue, 10 Jun 2003, Doug Royer wrote:
> > More specifically, the same thing that happens if the body is deleted from
> > the IMAP server between the time that the IMAP-as-submit client gets the
> > idea to make the request and the request is actually processed.  IMAP is
> > asynchronous, and there can be multiple simultaneous IMAP sessions.
> Currently that problem already exists in IMAP servers. It has nothing
> to do with if IMAP is also a submit server. Currently one session could
> delete a message while another session uploads it.

Correct.

> I'll bet all IMAP
> servers have a instance counting or message locking code to deal with
> this problem already.

Not correct, unfortunately (OK, *highly* unfortunately).  Refer to RFC
2180.

Some servers have this (mine does), but some others do not.

-- 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 mailnull@www1.ietf.org  Tue Jun 10 16:31:35 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16578
	for <lemonade-archive@odin.ietf.org>; Tue, 10 Jun 2003 16:31:35 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5AKV8623951
	for lemonade-archive@odin.ietf.org; Tue, 10 Jun 2003 16:31:08 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AKV8B23948
	for <lemonade-web-archive@optimus.ietf.org>; Tue, 10 Jun 2003 16:31:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16550
	for <lemonade-web-archive@ietf.org>; Tue, 10 Jun 2003 16:31:04 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Ppjq-0001u4-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 16:29:02 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Ppjq-0001u1-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 16:29:02 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AKV3B23938;
	Tue, 10 Jun 2003 16:31:03 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AKUuB23895
	for <lemonade@optimus.ietf.org>; Tue, 10 Jun 2003 16:30:56 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16537
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 16:30:52 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Ppje-0001tq-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 16:28:50 -0400
Received: from inet-consulting.com ([4.23.9.166] helo=royer.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Ppjd-0001tn-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 16:28:49 -0400
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h5AKUdbt030685
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 13:30:51 -0700
Message-ID: <3EE63FE4.904@Royer.com>
Date: Tue, 10 Jun 2003 14:30:28 -0600
From: Doug Royer <Doug@Royer.com>
Reply-To: lemonade@ietf.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: lemonade@ietf.org
Subject: Re: [lemonade] Re: IMAP as a submit server
References: <54E40201497DF142B06B27255953F79705BFD86F@il0015exch007u.ih.lucent.com> <Pine.WNT.4.60.0306101039160.2760@Tomobiki-Cho.CAC.Washington.EDU> <p06001419bb0bc963f08d@[216.43.25.67]> <Pine.WNT.4.60.0306101239060.2408@Tomobiki-Cho.CAC.Washington.EDU>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000503010305040508000003"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This is a cryptographically signed message in MIME format.

--------------ms000503010305040508000003
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Mark Crispin wrote:
> On Tue, 10 Jun 2003, Pete Resnick wrote:
> 
>>But an IMAP server could note the reference to the body from the
>>to-be-sent message and not "really" delete that body until the
>>reference count gets to zero. Or it could immediately copy the part
>>upon upload of the to-be-sent message if it really had no other
>>choice.
> 
> 
> No it can't.  You're making the assumption that the deletion is occuring
> in the same IMAP server session as the one doing the submit.  You can't
> make that assumption.

You pointed out in a similar response that your IMAP server does in fact
do locking or instance counting to solve these  exact issues across
multiple sessions. Why if it happens to be called 'submit' and
not 'fetch' would it make any difference to the locking?

> Nor can you assume that separate IMAP server sessions can communicate this
> information to each other.  There is nothing in the IMAP specification
> that requires this.
>
> There is nothing that you can do to prevent the timing race; refer to RFC
> 2180 for some of the gory details.  All you can do is make it less likely.
> 

There is no reason that a submit server could not add the requirement
that the server address this issue. Connecting to a separate server
and trying to maintain a lock or instance count across separate
servers seems much more complex than across sessions in the same
server.


-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  Doug@Royer.com                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

--------------ms000503010305040508000003
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC
A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j
cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB
MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T
BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN
VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre
qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+
5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA
MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg
TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD
QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx
ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz
IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq
hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34
1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA
gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK
YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd
SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC
AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF
BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl
cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl
IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs
MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq
1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2
TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail
MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE
AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO
b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG
MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD
VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV
BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv
43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y
lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP
D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn
0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK
bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg
hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT
IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI
AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t
L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk
OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW
yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1
MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl
ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTAyMDMwMjlaMCMGCSqGSIb3DQEJBDEWBBT6
EixYnVkGeVfR8+v71dA7oE7lKzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL
KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAHkBTJNJmXcNH
KMXTAWT9VDXpfclqNycRRSiRuO2fy6kkp/ZrIyJeoQdMHaNllMshEIIWy4kFd9ZFceLv5uFT
MH56G4KbyrWFSKWTpzrMmuZ+ZwMUuQt35XJROAhRoD232+sIGy5SN0hQYy7LgNLRCXhKOiFy
bCXkR5XbLetm2Dvjnten1ANJSyh42QVQSpEkPM62IeNi+tr2yHAMZ2PWYr3UYwn+S0apbCtF
+MgRenF1Df04zWxsINpCSIrqSUs4S79JwZqMeqgJ1KPpPJ0s3m4BUpi96cFxVLFaKQluJ7h1
q+abQKLl3/fGzUeOdwq1wdl8ZWFvuO5AOgrfXAKJhwAAAAAAAA==
--------------ms000503010305040508000003--

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



From mailnull@www1.ietf.org  Tue Jun 10 16:48:38 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17249
	for <lemonade-archive@odin.ietf.org>; Tue, 10 Jun 2003 16:48:38 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5AKmC425487
	for lemonade-archive@odin.ietf.org; Tue, 10 Jun 2003 16:48:12 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AKmBB25484
	for <lemonade-web-archive@optimus.ietf.org>; Tue, 10 Jun 2003 16:48:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17231
	for <lemonade-web-archive@ietf.org>; Tue, 10 Jun 2003 16:48:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pq0L-0001zX-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 16:46:05 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pq0L-0001zU-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 16:46:05 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AKm2B25450;
	Tue, 10 Jun 2003 16:48:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AKl5B25411
	for <lemonade@optimus.ietf.org>; Tue, 10 Jun 2003 16:47:05 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17202
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 16:47:01 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PpzH-0001zE-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 16:44:59 -0400
Received: from mxout4.cac.washington.edu ([140.142.33.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PpzG-0001zB-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 16:44:58 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9])
	by mxout4.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h5AKl0Tc008131
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 13:47:00 -0700
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
	(authenticated bits=0)
	by smtp.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h5AKl07k027061
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT)
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 13:47:00 -0700
Date: Tue, 10 Jun 2003 13:47:02 -0700 (Pacific Daylight Time)
From: Mark Crispin <MRC@CAC.Washington.EDU>
To: lemonade@ietf.org
Subject: Re: [lemonade] Re: IMAP as a submit server
In-Reply-To: <3EE63FE4.904@Royer.com>
Message-ID: <Pine.WNT.4.60.0306101334130.2408@Tomobiki-Cho.CAC.Washington.EDU>
References: <54E40201497DF142B06B27255953F79705BFD86F@il0015exch007u.ih.lucent.com>
 <Pine.WNT.4.60.0306101039160.2760@Tomobiki-Cho.CAC.Washington.EDU>
 <p06001419bb0bc963f08d@[216.43.25.67]> <Pine.WNT.4.60.0306101239060.2408@Tomobiki-Cho.CAC.Washington.EDU>
 <3EE63FE4.904@Royer.com>
Organization: Networks & Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Tue, 10 Jun 2003, Doug Royer wrote:
> You pointed out in a similar response that your IMAP server does in fact
> do locking or instance counting to solve these  exact issues across
> multiple sessions.

Be careful about reading too much into what I said.  My server does the
"ghosting" as described by RFC 2180.  However, that "ghosting" is only
guaranteed for sequence-number style access; whereas a submit server is
almost certainly going to do UID style access.

With UID style access, you don't can't count on there being any "ghosts";
you get holes.

> Why if it happens to be called 'submit' and
> not 'fetch' would it make any difference to the locking?

SUBMIT vs. FETCH does not matter.  Sequence number vs. UID matters.

Since SUBMIT is likely to use UIDs, you can't assume from one command to
the next that a message won't disappear.  The specification is quite firm
on that point.  Nor is there any aspect of IMAP that "locking" could hinge
on when UIDs are used.

> There is no reason that a submit server could not add the requirement
> that the server address this issue.

That's easier said than done.  It isn't just *adding* a requirement to
SUBMIT; it is *repealing* a requirement in IMAP.

> Connecting to a separate server
> and trying to maintain a lock or instance count across separate
> servers seems much more complex than across sessions in the same
> server.

Let's make this simple; there is no "lock" now that you can rely upon in
IMAP.

The best that there is in IMAP today is that, when sequence numbers are
used, an expunge can't come through except at certain commands.  If you
are lucky enough to use a server that "ghosts" *AND* if you use sequence
numbers instead of UIDs (meaning that you have to keep those sequence
numbers current -- you can't rely on a static value like UIDs), then you
can assume that the message won't go away between the last fetch and the
submit.  That's a lot of conditionals, and I don't think that you'll like
the implications if you have to implement it.

Frankly, if you want this kind of lock, you're better off using POP3 than
IMAP.  Unlike IMAP, POP3 gives you those guarantees.

-- 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 mailnull@www1.ietf.org  Tue Jun 10 17:35:43 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19027
	for <lemonade-archive@odin.ietf.org>; Tue, 10 Jun 2003 17:35:43 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5ALZI428996
	for lemonade-archive@odin.ietf.org; Tue, 10 Jun 2003 17:35:18 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ALZIB28993
	for <lemonade-web-archive@optimus.ietf.org>; Tue, 10 Jun 2003 17:35:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19023
	for <lemonade-web-archive@ietf.org>; Tue, 10 Jun 2003 17:35:13 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pqjv-0002Np-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 17:33:11 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pqju-0002Nm-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 17:33:10 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ALZ5B28985;
	Tue, 10 Jun 2003 17:35:05 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ALYrB28954
	for <lemonade@optimus.ietf.org>; Tue, 10 Jun 2003 17:34:53 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19019
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 17:34:48 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PqjW-0002Nj-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 17:32:46 -0400
Received: from champdsl-25-66.mcleodusa.net ([216.43.25.66] helo=episteme-software.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PqjW-0002Ng-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 17:32:46 -0400
Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with
 ESMTP (Eudora Internet Mail Server X 3.2.2b1);
 Tue, 10 Jun 2003 16:34:18 -0500
Mime-Version: 1.0
X-Sender: resnick@resnick1.qualcomm.com
Message-Id: <p0600141abb0bfec9749c@[216.43.25.67]>
In-Reply-To: 
 <Pine.WNT.4.60.0306101239060.2408@Tomobiki-Cho.CAC.Washington.EDU>
References: 
 <54E40201497DF142B06B27255953F79705BFD86F@il0015exch007u.ih.lucent.com>
 <Pine.WNT.4.60.0306101039160.2760@Tomobiki-Cho.CAC.Washington.EDU>
 <p06001419bb0bc963f08d@[216.43.25.67]>
 <Pine.WNT.4.60.0306101239060.2408@Tomobiki-Cho.CAC.Washington.EDU>
X-Mailer: Eudora [Macintosh version 6.0a15]
Date: Tue, 10 Jun 2003 16:34:16 -0500
To: Mark Crispin <MRC@CAC.Washington.EDU>
From: Pete Resnick <presnick@qualcomm.com>
Subject: RE: [lemonade] Re: IMAP as a submit server
Cc: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>, lemonade@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On 6/10/03 at 12:46 PM -0700, Mark Crispin wrote:

>On Tue, 10 Jun 2003, Pete Resnick wrote:
>>But an IMAP server could note the reference to the body from the 
>>to-be-sent message and not "really" delete that body until the 
>>reference count gets to zero. Or it could immediately copy the part 
>>upon upload of the to-be-sent message if it really had no other 
>>choice.
>
>No it can't.  You're making the assumption that the deletion is 
>occuring in the same IMAP server session as the one doing the 
>submit.  You can't make that assumption.

I am making no such assumption.

>Nor can you assume that separate IMAP server sessions can 
>communicate this information to each other.  There is nothing in the 
>IMAP specification that requires this.

But there is nothing in the IMAP specification that prevents it, and 
a server which would support such functionality would likely want to 
support this feature.

>There is nothing that you can do to prevent the timing race; refer 
>to RFC 2180 for some of the gory details.  All you can do is make it 
>less likely.

There is nothing preventing a server from implementing record locking 
on the bodies, and nothing preventing it from implementing reference 
counts or copies.

pr
-- 
Pete Resnick <mailto:presnick@qualcomm.com>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Tue Jun 10 17:51:40 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19465
	for <lemonade-archive@odin.ietf.org>; Tue, 10 Jun 2003 17:51:40 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5ALpFY30397
	for lemonade-archive@odin.ietf.org; Tue, 10 Jun 2003 17:51:15 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ALpFB30394
	for <lemonade-web-archive@optimus.ietf.org>; Tue, 10 Jun 2003 17:51:15 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19461
	for <lemonade-web-archive@ietf.org>; Tue, 10 Jun 2003 17:51:10 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PqzM-0002Ve-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 17:49:08 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PqzL-0002Vb-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 17:49:07 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ALp7B30382;
	Tue, 10 Jun 2003 17:51:07 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ALovB30364
	for <lemonade@optimus.ietf.org>; Tue, 10 Jun 2003 17:50:57 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19454
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 17:50:51 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pqz3-0002VQ-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 17:48:49 -0400
Received: from mxout1.cac.washington.edu ([140.142.32.134])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pqz2-0002VN-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 17:48:49 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139])
	by mxout1.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h5ALooRG022329;
	Tue, 10 Jun 2003 14:50:51 -0700
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
	(authenticated bits=0)
	by smtp.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h5ALooQ0002470
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Tue, 10 Jun 2003 14:50:50 -0700
Date: Tue, 10 Jun 2003 14:50:52 -0700 (Pacific Daylight Time)
From: Mark Crispin <MRC@CAC.Washington.EDU>
To: Pete Resnick <presnick@qualcomm.com>
cc: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>, lemonade@ietf.org
Subject: RE: [lemonade] Re: IMAP as a submit server
In-Reply-To: <p0600141abb0bfec9749c@[216.43.25.67]>
Message-ID: <Pine.WNT.4.60.0306101436010.2408@Tomobiki-Cho.CAC.Washington.EDU>
References: <54E40201497DF142B06B27255953F79705BFD86F@il0015exch007u.ih.lucent.com>
 <Pine.WNT.4.60.0306101039160.2760@Tomobiki-Cho.CAC.Washington.EDU>
 <p06001419bb0bc963f08d@[216.43.25.67]> <Pine.WNT.4.60.0306101239060.2408@Tomobiki-Cho.CAC.Washington.EDU>
 <p0600141abb0bfec9749c@[216.43.25.67]>
Organization: Networks & Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Tue, 10 Jun 2003, Pete Resnick wrote:
> >Nor can you assume that separate IMAP server sessions can
> >communicate this information to each other.  There is nothing in the
> >IMAP specification that requires this.
> But there is nothing in the IMAP specification that prevents it, and
> a server which would support such functionality would likely want to
> support this feature.

To the contrary; the IMAP specification is emphatic on the circumstances
in which an unsolicited EXPUNGE can occur.  You want to stop that form of
communication, and you need a way to communicate that, and it needs to
interoperate with existing software.

The only protection -- and even that is limited (see RFC 2180) -- is if
you use sequence numbers instead of UIDs and do NOT use any command other
than FETCH (not UID FETCH), STORE (not UID STORE), and SEARCH (not UID
SEARCH).  The proposed IMAP SUBMIT command could also have that
prohibition, although it's only necessary if you want to do multiple
SUBMITs.  However, this doesn't help if you use UIDs.

> >There is nothing that you can do to prevent the timing race; refer
> >to RFC 2180 for some of the gory details.  All you can do is make it
> >less likely.
> There is nothing preventing a server from implementing record locking
> on the bodies, and nothing preventing it from implementing reference
> counts or copies.

To accomplish this, there needs to be a new IMAP extension which creates
those semantics.  Since IMAP servers don't have clairvoyance, such an
extension is also needed to identify the areas to be locked.  There also
needs to be some means to unlock.

-- 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 mailnull@www1.ietf.org  Tue Jun 10 19:11:46 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22326
	for <lemonade-archive@odin.ietf.org>; Tue, 10 Jun 2003 19:11:46 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5ANBNM03402
	for lemonade-archive@odin.ietf.org; Tue, 10 Jun 2003 19:11:23 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ANBNB03399
	for <lemonade-web-archive@optimus.ietf.org>; Tue, 10 Jun 2003 19:11:23 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22308
	for <lemonade-web-archive@ietf.org>; Tue, 10 Jun 2003 19:11:15 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PsEs-0002yb-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 19:09:14 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PsEr-0002yX-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 19:09:13 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ANB7B03344;
	Tue, 10 Jun 2003 19:11:07 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ANAGB03291
	for <lemonade@optimus.ietf.org>; Tue, 10 Jun 2003 19:10:16 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22263
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 19:10:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PsDn-0002xB-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 19:08:07 -0400
Received: from inet-consulting.com ([4.23.9.166] helo=royer.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PsDl-0002x7-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 19:08:05 -0400
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h5ANA0bt031875
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 16:10:07 -0700
Message-ID: <3EE6653E.9020109@Royer.com>
Date: Tue, 10 Jun 2003 17:09:50 -0600
From: Doug Royer <Doug@Royer.com>
Reply-To: lemonade@ietf.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: lemonade@ietf.org
Subject: Re: [lemonade] Re: IMAP as a submit server
References: <54E40201497DF142B06B27255953F79705BFD86F@il0015exch007u.ih.lucent.com> <Pine.WNT.4.60.0306101039160.2760@Tomobiki-Cho.CAC.Washington.EDU> <p06001419bb0bc963f08d@[216.43.25.67]> <Pine.WNT.4.60.0306101239060.2408@Tomobiki-Cho.CAC.Washington.EDU> <p0600141abb0bfec9749c@[216.43.25.67]> <Pine.WNT.4.60.0306101436010.2408@Tomobiki-Cho.CAC.Washington.EDU>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080500020006070108090409"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This is a cryptographically signed message in MIME format.

--------------ms080500020006070108090409
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Mark Crispin wrote:
> On Tue, 10 Jun 2003, Pete Resnick wrote:

> 
> To accomplish this, there needs to be a new IMAP extension which creates
> those semantics.  Since IMAP servers don't have clairvoyance, such an
> extension is also needed to identify the areas to be locked.  There also
> needs to be some means to unlock.

With IMAP as the submit program, it simply has to not physically remove
any object until all operations on the object are complete. Currently
if I delete an object then try to access it with another session, I get
an error. I do not see anything is needed in the protocol, it would
all be new text in a new spec saying - do that.

With another non-IMAP program as the submit server, yes, but that
adds another round trip call from the client to the IMAP server
- 'lock this object'.

Perhaps a proxy service that sits on top of both IMAP and an SMTP
server that has been somewhat proposed is the solution. But clearly one
client application communicating to two servers to perform one unified act
of forwarding a message is going to be a much more complicated
protocol.

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  Doug@Royer.com                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

--------------ms080500020006070108090409
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC
A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j
cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB
MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T
BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN
VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre
qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+
5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA
MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg
TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD
QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx
ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz
IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq
hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34
1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA
gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK
YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd
SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC
AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF
BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl
cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl
IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs
MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq
1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2
TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail
MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE
AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO
b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG
MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD
VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV
BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv
43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y
lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP
D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn
0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK
bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg
hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT
IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI
AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t
L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk
OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW
yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1
MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl
ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTAyMzA5NTBaMCMGCSqGSIb3DQEJBDEWBBSM
X82M2JC13l+/BfiH6xHUQDwOhTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL
KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEASkoIK/pOxdmr
y1SUgTLAfDwvsg7NR5a8q1xtPWVo2Ja8LzurQn03aFdf9jGCk36qgGpwy89gcK0xu6a7h8eI
usshEjRqYqhDx1rerLXAx0kxcrZIyZxDH7U6yQE/6+va3pOziwrox/WyrVkN8zBXIqmzMX/s
9oX/b/Gtn0bPxreEezUwp8y6UVYT5nR1PmZcSKgYgSb1LKouFk9+xOcoMTsPJftYYNgwgS0k
VS0XCkFlhPqBHhXqH5v5XT/+HD7X+p0Z9yniU0sQI7prcnZ3k+r2diQX06vqioci7p7SKXXM
OwddSc7EayefpWznsCyx+mdIXtNP0t5GvbUcSicn2AAAAAAAAA==
--------------ms080500020006070108090409--

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



From mailnull@www1.ietf.org  Tue Jun 10 19:48:39 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23098
	for <lemonade-archive@odin.ietf.org>; Tue, 10 Jun 2003 19:48:39 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5ANmCu05545
	for lemonade-archive@odin.ietf.org; Tue, 10 Jun 2003 19:48:12 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ANmCB05542
	for <lemonade-web-archive@optimus.ietf.org>; Tue, 10 Jun 2003 19:48:12 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23094
	for <lemonade-web-archive@ietf.org>; Tue, 10 Jun 2003 19:48:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PsoZ-0003CT-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 19:46:07 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PsoZ-0003CQ-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 19:46:07 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ANm3B05532;
	Tue, 10 Jun 2003 19:48:03 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ANlwB05517
	for <lemonade@optimus.ietf.org>; Tue, 10 Jun 2003 19:47:58 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23090
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 19:47:55 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PsoL-0003CN-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 19:45:53 -0400
Received: from mxout4.cac.washington.edu ([140.142.33.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PsoK-0003CK-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 19:45:53 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9])
	by mxout4.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h5ANltTc011647
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 16:47:55 -0700
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
	(authenticated bits=0)
	by smtp.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h5ANlt7k007264
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT)
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 16:47:55 -0700
Date: Tue, 10 Jun 2003 16:47:57 -0700 (Pacific Daylight Time)
From: Mark Crispin <MRC@CAC.Washington.EDU>
To: lemonade@ietf.org
Subject: Re: [lemonade] Re: IMAP as a submit server
In-Reply-To: <3EE6653E.9020109@Royer.com>
Message-ID: <Pine.WNT.4.60.0306101611500.2408@Tomobiki-Cho.CAC.Washington.EDU>
References: <54E40201497DF142B06B27255953F79705BFD86F@il0015exch007u.ih.lucent.com>
 <Pine.WNT.4.60.0306101039160.2760@Tomobiki-Cho.CAC.Washington.EDU>
 <p06001419bb0bc963f08d@[216.43.25.67]> <Pine.WNT.4.60.0306101239060.2408@Tomobiki-Cho.CAC.Washington.EDU>
 <p0600141abb0bfec9749c@[216.43.25.67]> <Pine.WNT.4.60.0306101436010.2408@Tomobiki-Cho.CAC.Washington.EDU>
 <3EE6653E.9020109@Royer.com>
Organization: Networks & Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Tue, 10 Jun 2003, Doug Royer wrote:
> With IMAP as the submit program, it simply has to not physically remove
> any object until all operations on the object are complete. Currently
> if I delete an object then try to access it with another session, I get
> an error.

How is "it" supposed to know when "all operations on the object are
complete"?

> I do not see anything is needed in the protocol, it would
> all be new text in a new spec saying - do that.

Consider the following situation:

Client A and client B have simultaneous sessions to the same mailbox.
Client A identifies some text that it wants to forward.  In between the
time that it identifies that text, and issues the SUBMIT command, client B
expunges the text.

To prevent this, client A must instruct the IMAP server, via a locking
command, not to permit expunges of the data; and subsequently it must
release the lock when it no longer needs that data.

Unless aided by a human behind both client A and B knowing "I shouldn't do
that", client B does not have clairvoyance to know not to do the harmful
thing.  Nor does client B's IMAP server know what client A is up to, and
vice versa.

You could try to prohibit expunge in shared sessions.  Try convincing the
enterprises that a cell phone email client is worth breaking all their
Outlook users.

> With another non-IMAP program as the submit server, yes, but that
> adds another round trip call from the client to the IMAP server
> - 'lock this object'.

Sorry, you need the "lock this object" no matter what you do if you are
concerned about this problem.

> Perhaps a proxy service that sits on top of both IMAP and an SMTP
> server that has been somewhat proposed is the solution.

If we can settle upon this as the course of action, let's declare peace
and go home.  From here, it looks like a win-win situation for everybody.
Win-win is always good.

> But clearly one
> client application communicating to two servers to perform one unified act
> of forwarding a message is going to be a much more complicated
> protocol.

The complexity is there no matter what you do.  But the proxy service idea
has the advantage of moving the complexity away from the mobile device.

The proxy has an additional advantage in that its protocol can be tailored
explicitly for mobile device needs without having to do battle with the
SMTP and IMAP protocol guys.  That is a good thing from everybody's
perspective.

It also eliminates the locking question, solves SMTP and IMAP chattiness,
and solves the multiple-source problem.

Sounds like everybody should be happy.  Can we all sign off on this and
drink beer together?

-- 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 mailnull@www1.ietf.org  Tue Jun 10 20:12:40 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23687
	for <lemonade-archive@odin.ietf.org>; Tue, 10 Jun 2003 20:12:40 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5B0CCu07384
	for lemonade-archive@odin.ietf.org; Tue, 10 Jun 2003 20:12:12 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B0CCB07381
	for <lemonade-web-archive@optimus.ietf.org>; Tue, 10 Jun 2003 20:12:12 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23673
	for <lemonade-web-archive@ietf.org>; Tue, 10 Jun 2003 20:12:09 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PtBm-0003MB-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 20:10:06 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PtBm-0003M8-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 20:10:06 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B0C2B07349;
	Tue, 10 Jun 2003 20:12:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B0B3B07274
	for <lemonade@optimus.ietf.org>; Tue, 10 Jun 2003 20:11:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23632
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 20:11:00 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PtAf-0003L7-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 20:08:57 -0400
Received: from brmea-mail-2.sun.com ([192.18.98.43])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PtAe-0003L4-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 20:08:56 -0400
Received: from esunmail ([129.147.58.120])
	by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5B0B0YU029684
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 18:11:00 -0600 (MDT)
Received: from xpa-fe1 ([129.147.58.198]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003))
 with ESMTP id <0HGA00MC3J6BDQ@edgemail1.Central.Sun.COM> for
 lemonade@ietf.org; Tue, 10 Jun 2003 18:11:00 -0600 (MDT)
Received: from nifty-jr.west.sun.com ([129.153.12.95])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003))
 with ESMTPSA id <0HGA00GWJJ69ZE@mail.sun.net> for lemonade@ietf.org; Tue,
 10 Jun 2003 18:10:59 -0600 (MDT)
Date: Tue, 10 Jun 2003 17:07:43 -0700
From: Chris Newman <Chris.Newman@Sun.COM>
To: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Message-id: <2147483647.1055264863@nifty-jr.west.sun.com>
MIME-version: 1.0
X-Mailer: Mulberry/3.0.3 (Mac OS X)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-message-flag: Outlook: the best virus distribution system around
Content-Transfer-Encoding: 7BIT
Subject: [lemonade] Strawman for Submit based message composition
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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-Transfer-Encoding: 7BIT
Content-Transfer-Encoding: 7BIT

I'll start by defining message composition as the process of assembling
multiple byte-counted objects from potentially different locations into a
single byte stream.  IMAP has no such facility.

SMTP/Submit, however, already has 90% of this facility with the CHUNKING
extension.  In particular, it assembles a series of byte-counted objects into a
single byte stream.

Suppose we create a new Submit extension called "BURL" which can be interleaved
with "BDAT" commands.  So you can now compose a message as follows:

BDAT ....               headers and first part
BURL 8bit <imap-url>    forwarded 8bit content from IMAP
BDAT ....               MIME delimiters or whatever
BURL base64 <http-url>  get http content, base64 encode it and include it
BDAT ....               final data

This can all be pipelined into one round-trip.

The BURL extension should advertise what types of URLs it supports:

250-BURL http imap://trusted-host.example.com/

This extension alone would solve the forward-without-download extension for the
subset of the problem space where the submit server has pre-existing trust
relationship with the IMAP server.

Indeed since 99% of the world uses plain text passwords (with or without TLS)
for authentication.  Authenticating to the submit server will grant sufficient
rights for the user to access and forward their own mail from IMAP anyway.  So
why not use it when appropriate?

If we wanted to go for the additional case where there isn't a trust
relationship between the submit server and IMAP server, then we simply add two
extensions to IMAP:

1. a "GENURL" command which turns a message or body-part reference within the
selected mailbox into an extended IMAP URL with an authorization token.  This
could either have a time-limit or a number of use limit.  The authorization
token would likely be an HMAC-MD5 covering the URL, a nonce, a time-limit and
using a per-user random secret known only to the IMAP server.

2. a "GETURL" command which is accessible by any IMAP user (including
anonymous) which returns a literal of the the relevant message/body part if the
authorization token is valid.

This just doesn't seem complicated to me.  Indeed it seems much simpler than
any approach to extending IMAP with a redundant submission and composition
facility in addition to the one already present in CHUNKING Submit.

                - Chris

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



From mailnull@www1.ietf.org  Tue Jun 10 20:25:41 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23989
	for <lemonade-archive@odin.ietf.org>; Tue, 10 Jun 2003 20:25:41 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5B0PDo07791
	for lemonade-archive@odin.ietf.org; Tue, 10 Jun 2003 20:25:13 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B0PDB07788
	for <lemonade-web-archive@optimus.ietf.org>; Tue, 10 Jun 2003 20:25:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23982
	for <lemonade-web-archive@ietf.org>; Tue, 10 Jun 2003 20:25:10 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PtON-0003Ph-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 20:23:07 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PtOM-0003Pe-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 20:23:06 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B0P2B07759;
	Tue, 10 Jun 2003 20:25:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B0O8B07724
	for <lemonade@optimus.ietf.org>; Tue, 10 Jun 2003 20:24:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23954
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 20:24:05 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PtNK-0003PO-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 20:22:02 -0400
Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PtNJ-0003PE-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 20:22:02 -0400
Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83])
	by ihemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h5B0NWP08463
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 19:23:33 -0500 (CDT)
Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19)
	id <L2XMAVY1>; Tue, 10 Jun 2003 19:23:32 -0500
Message-ID: <54E40201497DF142B06B27255953F79705BFDBF6@il0015exch007u.ih.lucent.com>
From: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
To: Cyrus Daboo <daboo@cyrusoft.com>, Randall Gellens <randy@qualcomm.com>,
        "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Cc: Doug Royer <Doug@royer.com>
Subject: RE: [lemonade] Re: Just 'ATTACH'
Date: Tue, 10 Jun 2003 19:23:31 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>


I understand the requirements to be (1) below, the ability to forward one or more atomic messages, or for bonus points, to forward a single atomic body-part of a message.  Richer composition including inline quotation should be done on the client.   After all, download of text for re-composition is not generally expensive, and the client is likely to need the content anyway for the user to determine what needs to be quoted.

I don't see the requirement for submit server resolution of external documents and the like...  Maybe others have a need for that, but I see the resolution of an external URL as the obligation of the recipient UA.   

Greg V.

-----Original Message-----
From: Cyrus Daboo [mailto:daboo@cyrusoft.com]
Sent: Tuesday, June 10, 2003 11:37 AM
To: Randall Gellens; IETF LEMONADE (E-mail)
Cc: Doug Royer
Subject: Re: [lemonade] Re: Just 'ATTACH'


Hi Randall,

--On Monday, June 9, 2003 11:24 PM -0400 Randall Gellens 
<randy@qualcomm.com> wrote:

|>  SMTP commands can not be embedded into the DATA stream. So I do not
|>  think an ATTACH SMTP command will work. Although most MUAs display
|>  'attachments' in a separate pane, they are inline in just about any
|>  random order.
|
| We would be creating a new Submit extension mechanism.  Such a mechanism
| could be as simple as saying 'expand references external body parts that
| have the "expand" flag set'.  Note that during the discussions on
| developing a separate SMTP submit service from the SMTP relay service, it
| was suggested that future Submit extensions that were only useful for
| message submission should perhaps look quite different from SMTP
| extensions, to prevent them from leaking into SMTP relay.  One example
| would be a kind of envelope wrapping the transaction.  At the time, there
| was discussion of using a Submit service for various sorts of helpful
| things, including transcoding of voice attachments, creating a proper
| message, etc.

Can we have a clear statement of what exactly needs to be expanded for this 
application? The two possibilities I see right now are:

1) Expand entire MIME parts by substituting data from an outside source: 
external-body expansion.

2) Expand inline data (e.g. quotations in a reply or forward).

The former is relatively easy to do - just substituting one MIME part for 
another.

The later is much more complicated as it requires detailed knowledge of the 
data itself. This really requires a full-blown 'composition agent' that 
knows how to deal with character set and encoding issues for all components 
of the data being expanded, as well as data format issues (e.g. knows how 
to put together HTML fragments in a consistent manner). That definitely 
goes beyond anything that either SMTP or IMAP has had to do up till now.

If (2) is a requirement then I'd be more inclined to go with a third server 
option that has not been discussed much - namely having a new type of 
server a 'message composition server' that has all the logic and capability 
of a typical desktop MUA in terms of building rfc2822/MIME messages as well 
as the ability to pull in data from external sources (with an appropriate 
security model). As well as providing pointers to the source components of 
the message, the client of this server would also be able to specify the 
destination, which might be an IMAP server or an SMTP server or some other 
destination in a similar manner to IMAP CHANNEL. Has this third server 
option been ruled out for any reason?

-- 
Cyrus Daboo
_______________________________________________
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 mailnull@www1.ietf.org  Tue Jun 10 20:34:35 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24332
	for <lemonade-archive@odin.ietf.org>; Tue, 10 Jun 2003 20:34:35 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5B0Y8U08202
	for lemonade-archive@odin.ietf.org; Tue, 10 Jun 2003 20:34:08 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B0Y8B08199
	for <lemonade-web-archive@optimus.ietf.org>; Tue, 10 Jun 2003 20:34:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24294
	for <lemonade-web-archive@ietf.org>; Tue, 10 Jun 2003 20:34:05 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PtWz-0003Tz-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 20:32:01 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PtWz-0003Tw-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 20:32:01 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B0Y4B08191;
	Tue, 10 Jun 2003 20:34:04 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B0XlB08175
	for <lemonade@optimus.ietf.org>; Tue, 10 Jun 2003 20:33:47 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24289
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 20:33:44 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PtWf-0003Ts-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 20:31:41 -0400
Received: from inet-consulting.com ([4.23.9.166] helo=royer.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PtWd-0003Tp-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 20:31:40 -0400
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h5B0Xabt032511
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 17:33:41 -0700
Message-ID: <3EE678C1.1020000@Royer.com>
Date: Tue, 10 Jun 2003 18:33:05 -0600
From: Doug Royer <Doug@Royer.com>
Reply-To: lemonade@ietf.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: lemonade@ietf.org
Subject: Re: [lemonade] Re: IMAP as a submit server
References: <54E40201497DF142B06B27255953F79705BFD86F@il0015exch007u.ih.lucent.com> <Pine.WNT.4.60.0306101039160.2760@Tomobiki-Cho.CAC.Washington.EDU> <p06001419bb0bc963f08d@[216.43.25.67]> <Pine.WNT.4.60.0306101239060.2408@Tomobiki-Cho.CAC.Washington.EDU> <p0600141abb0bfec9749c@[216.43.25.67]> <Pine.WNT.4.60.0306101436010.2408@Tomobiki-Cho.CAC.Washington.EDU> <3EE6653E.9020109@Royer.com> <Pine.WNT.4.60.0306101611500.2408@Tomobiki-Cho.CAC.Washington.EDU>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000205060209050907050006"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This is a cryptographically signed message in MIME format.

--------------ms000205060209050907050006
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Mark Crispin wrote:
> On Tue, 10 Jun 2003, Doug Royer wrote:
> 
>>With IMAP as the submit program, it simply has to not physically remove
>>any object until all operations on the object are complete. Currently
>>if I delete an object then try to access it with another session, I get
>>an error.
> 
> 
> How is "it" supposed to know when "all operations on the object are
> complete"?

Simple reader/writer locks - that is the exact scenario they
were designed to solve. Nothing complex needed. And no protocol
changes needed.

Always do a write lock on an object if you are modifying/deleting.
Always do a read lock on an object if you are not modifying/deleting.
Allow only one writer lock per object.
Allow multiple reader locks per object.
All reader locks MUST wait for any writer lock to be done.
A writer lock MUST wait if there are any reader locks.
All reader locks MUST be prepared for no-longer-exists error.

No modifications to the protocol needed. It is all code.


-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  Doug@Royer.com                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

--------------ms000205060209050907050006
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC
A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j
cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB
MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T
BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN
VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre
qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+
5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA
MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg
TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD
QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx
ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz
IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq
hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34
1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA
gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK
YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd
SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC
AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF
BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl
cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl
IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs
MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq
1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2
TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail
MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE
AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO
b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG
MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD
VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV
BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv
43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y
lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP
D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn
0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK
bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg
hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT
IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI
AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t
L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk
OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW
yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1
MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl
ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTEwMDMzMDVaMCMGCSqGSIb3DQEJBDEWBBST
IcGHEw9BCJ9pl2dvtcCQLV5WGTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL
KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAmrgFDJTO0+yt
NjHPeXUlrWwX/wqIqFQ81HrnT7T6VFPgpODCElZFrE6pgbrk0OQ4GqXQVXl+FjqBbvS4JbwU
3aUXoJehkSh6VefMLyewpv/kFbDkRyshfTuFtnQmi+1CuyndqUMb5QW4v5wAg+1gsdHhKor/
R2AB7ac6Nq67KV4PsUHxFXk9ffyAAIAtMhmX3pRWHMQQXL9savxpivn0EVOJ9VIEM9frXvIa
PzIGsTIJDJQZgkgnF8po1VH7V6ZiCyUy5A7rSSOFSObjsd9LV9CLkPO69/a7GwcTuMVkttuc
zUmEmm7PAWxXXMjQiML+NsvIf7I/e151rDPZ0gLgTQAAAAAAAA==
--------------ms000205060209050907050006--

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



From mailnull@www1.ietf.org  Tue Jun 10 20:44:39 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24542
	for <lemonade-archive@odin.ietf.org>; Tue, 10 Jun 2003 20:44:39 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5B0iCf09444
	for lemonade-archive@odin.ietf.org; Tue, 10 Jun 2003 20:44:12 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B0iCB09441
	for <lemonade-web-archive@optimus.ietf.org>; Tue, 10 Jun 2003 20:44:12 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24538
	for <lemonade-web-archive@ietf.org>; Tue, 10 Jun 2003 20:44:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Ptgj-0003XH-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 20:42:05 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Ptgj-0003XE-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 20:42:05 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B0i1B09417;
	Tue, 10 Jun 2003 20:44:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B0hJB09383
	for <lemonade@optimus.ietf.org>; Tue, 10 Jun 2003 20:43:19 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24526
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 20:43:16 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Ptft-0003X4-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 20:41:13 -0400
Received: from inet-consulting.com ([4.23.9.166] helo=royer.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Ptfr-0003X1-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 20:41:12 -0400
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h5B0h8bt032607
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 17:43:14 -0700
Message-ID: <3EE67B17.7080208@Royer.com>
Date: Tue, 10 Jun 2003 18:43:03 -0600
From: Doug Royer <Doug@Royer.com>
Reply-To: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: lemonade@ietf.org
Subject: Re: [lemonade] Strawman for Submit based message composition
References: <2147483647.1055264863@nifty-jr.west.sun.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080009000908030709090901"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This is a cryptographically signed message in MIME format.

--------------ms080009000908030709090901
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


Interesting idea.

I think the GENRUL command could be eliminated:

  As the client is going to be sent something that tells it that
  a non-downloaded body part exits, why not make that something
  compatible with the 'BURL'? Now that round trip is eliminated.
  Generating some authentication token / UID or CID/MID / whatever
  can not be that complex for each non-downloaded body part or
  message.

Chris Newman wrote:
> I'll start by defining message composition as the process of assembling
> multiple byte-counted objects from potentially different locations into a
> single byte stream.  IMAP has no such facility.
> 
> SMTP/Submit, however, already has 90% of this facility with the CHUNKING
> extension.  In particular, it assembles a series of byte-counted objects into a
> single byte stream.
> 
> Suppose we create a new Submit extension called "BURL" which can be interleaved
> with "BDAT" commands.  So you can now compose a message as follows:
> 
> BDAT ....               headers and first part
> BURL 8bit <imap-url>    forwarded 8bit content from IMAP
> BDAT ....               MIME delimiters or whatever
> BURL base64 <http-url>  get http content, base64 encode it and include it
> BDAT ....               final data
> 
> This can all be pipelined into one round-trip.
> 
> The BURL extension should advertise what types of URLs it supports:
> 
> 250-BURL http imap://trusted-host.example.com/
> 
> This extension alone would solve the forward-without-download extension for the
> subset of the problem space where the submit server has pre-existing trust
> relationship with the IMAP server.
> 
> Indeed since 99% of the world uses plain text passwords (with or without TLS)
> for authentication.  Authenticating to the submit server will grant sufficient
> rights for the user to access and forward their own mail from IMAP anyway.  So
> why not use it when appropriate?
> 
> If we wanted to go for the additional case where there isn't a trust
> relationship between the submit server and IMAP server, then we simply add two
> extensions to IMAP:
> 
> 1. a "GENURL" command which turns a message or body-part reference within the
> selected mailbox into an extended IMAP URL with an authorization token.  This
> could either have a time-limit or a number of use limit.  The authorization
> token would likely be an HMAC-MD5 covering the URL, a nonce, a time-limit and
> using a per-user random secret known only to the IMAP server.
> 
> 2. a "GETURL" command which is accessible by any IMAP user (including
> anonymous) which returns a literal of the the relevant message/body part if the
> authorization token is valid.
> 
> This just doesn't seem complicated to me.  Indeed it seems much simpler than
> any approach to extending IMAP with a redundant submission and composition
> facility in addition to the one already present in CHUNKING Submit.
> 
>                 - Chris
> 
> _______________________________________________
> lemonade mailing list
> lemonade@ietf.org
> https://www1.ietf.org/mailman/listinfo/lemonade


-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  Doug@Royer.com                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

--------------ms080009000908030709090901
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC
A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j
cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB
MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T
BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN
VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre
qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+
5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA
MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg
TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD
QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx
ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz
IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq
hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34
1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA
gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK
YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd
SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC
AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF
BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl
cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl
IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs
MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq
1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2
TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail
MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE
AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO
b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG
MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD
VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV
BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv
43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y
lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP
D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn
0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK
bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg
hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT
IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI
AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t
L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk
OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW
yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1
MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl
ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTEwMDQzMDNaMCMGCSqGSIb3DQEJBDEWBBR4
RmAoqNhNBKMucq57E2z79lT9DTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL
KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAc6DHR5N/0EZr
a01CLT4FyXmoLFHqhFf5MoNFnMUCQ793YOXOfCbuSQuKvF+6+JXXNvsTLeDJPg5/9eqy8Rve
9qUvbkNjpSovvQjbzCjOz+O/CFYbhV8ExSZbhqKMA4CUktv06LiHNsOFL/iWZE4CWzZvXsJp
RO/VJPzFAJ4XYLDxzeIvCC4fOA9LvR2uk2XXyosykR7gQ9ktp6aK75Ql/DVJgJxK3wF/XDD/
bnSw9OstDkAEiAMD7lcixA8hUTR20unxrQ1NTHy5rRRPu+CdoMyALieanytZzsM6vOOGyyq4
nx/bnub61hMLmvnoQMwwbOvBW4fU8yJJOVFkwSSwdQAAAAAAAA==
--------------ms080009000908030709090901--

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



From mailnull@www1.ietf.org  Tue Jun 10 20:54:33 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24810
	for <lemonade-archive@odin.ietf.org>; Tue, 10 Jun 2003 20:54:33 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5B0s6r09709
	for lemonade-archive@odin.ietf.org; Tue, 10 Jun 2003 20:54:06 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B0s6B09706
	for <lemonade-web-archive@optimus.ietf.org>; Tue, 10 Jun 2003 20:54:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24802
	for <lemonade-web-archive@ietf.org>; Tue, 10 Jun 2003 20:54:02 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PtqJ-0003a1-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 20:51:59 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PtqJ-0003Zy-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 20:51:59 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B0s1B09698;
	Tue, 10 Jun 2003 20:54:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B0r4B09657
	for <lemonade@optimus.ietf.org>; Tue, 10 Jun 2003 20:53:04 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24708
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 20:53:00 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PtpJ-0003Z5-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 20:50:57 -0400
Received: from mxout4.cac.washington.edu ([140.142.33.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PtpI-0003Z2-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 20:50:57 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9])
	by mxout4.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h5B0qxTc020026
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 17:52:59 -0700
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
	(authenticated bits=0)
	by smtp.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h5B0qx7k010367
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT)
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 17:52:59 -0700
Date: Tue, 10 Jun 2003 17:53:00 -0700 (Pacific Daylight Time)
From: Mark Crispin <MRC@CAC.Washington.EDU>
To: lemonade@ietf.org
Subject: Re: [lemonade] Re: IMAP as a submit server
In-Reply-To: <3EE678C1.1020000@Royer.com>
Message-ID: <Pine.WNT.4.60.0306101736330.2408@Tomobiki-Cho.CAC.Washington.EDU>
References: <54E40201497DF142B06B27255953F79705BFD86F@il0015exch007u.ih.lucent.com>
 <Pine.WNT.4.60.0306101039160.2760@Tomobiki-Cho.CAC.Washington.EDU>
 <p06001419bb0bc963f08d@[216.43.25.67]> <Pine.WNT.4.60.0306101239060.2408@Tomobiki-Cho.CAC.Washington.EDU>
 <p0600141abb0bfec9749c@[216.43.25.67]> <Pine.WNT.4.60.0306101436010.2408@Tomobiki-Cho.CAC.Washington.EDU>
 <3EE6653E.9020109@Royer.com> <Pine.WNT.4.60.0306101611500.2408@Tomobiki-Cho.CAC.Washington.EDU>
 <3EE678C1.1020000@Royer.com>
Organization: Networks & Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Tue, 10 Jun 2003, Doug Royer wrote:
> Simple reader/writer locks - that is the exact scenario they
> were designed to solve. Nothing complex needed. And no protocol
> changes needed.

How are these locks to be applied without protocol changes?

> Always do a write lock on an object if you are modifying/deleting.

What is a "write lock" in the context of RFC 3501?

> Always do a read lock on an object if you are not modifying/deleting.

What is a "read lock" in the context of RFC 3501?

> Allow only one writer lock per object.
> Allow multiple reader locks per object.
> All reader locks MUST wait for any writer lock to be done.
> A writer lock MUST wait if there are any reader locks.
> All reader locks MUST be prepared for no-longer-exists error.

I know how locks work.  I've been using these sorts of locks for 25 years.
I also invented IMAP, and edited RFC 3501.

Please do not treat me like a ignorant person.

> No modifications to the protocol needed. It is all code.

I suspect that you have not studied RFC 3501 very carefully.  If you had,
you would have observed that:
 1) There may be multiple IMAP sessions operating on the same mailbox.
 2) IMAP sessions consist of multiple IMAP commands.
 3) Each IMAP command is an atomic operation.
 4) Between any two IMAP commands in a session, commands in another
     session -- on the same mailbox -- may take place.

IMAP is unlike POP3, which only permits a single session on a mailbox.
Consequently, there is *no* lock of the sort that you envision, nor is
there any way for there to be such a lock.

IMAP, by its definition, has no such locks; nor can such locking be done.
It is expressly authorized in the protocol to do simultaneous read/write
access.  Clients exploit this capability.

If you feel that it's a deficiency that IMAP lacks such locks, you may be
right.  But saying "it's just programming" doesn't make it so.  If you
want locks in IMAP, it has to be added at the protocol level.

-- 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 mailnull@www1.ietf.org  Tue Jun 10 21:08:38 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25179
	for <lemonade-archive@odin.ietf.org>; Tue, 10 Jun 2003 21:08:38 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5B18Cn11115
	for lemonade-archive@odin.ietf.org; Tue, 10 Jun 2003 21:08:12 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B18CB11112
	for <lemonade-web-archive@optimus.ietf.org>; Tue, 10 Jun 2003 21:08:12 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25157
	for <lemonade-web-archive@ietf.org>; Tue, 10 Jun 2003 21:08:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pu3x-0003hO-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 21:06:05 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pu3w-0003hL-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 21:06:04 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B182B11061;
	Tue, 10 Jun 2003 21:08:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B139B10015
	for <lemonade@optimus.ietf.org>; Tue, 10 Jun 2003 21:03:09 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25059
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 21:03:05 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Ptz4-0003fD-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 21:01:02 -0400
Received: from mxout5.cac.washington.edu ([140.142.32.135])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Ptz3-0003fA-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 21:01:01 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9])
	by mxout5.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h5B134t7031222
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 18:03:04 -0700
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
	(authenticated bits=0)
	by smtp.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h5B1337k010720
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT)
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 18:03:03 -0700
Date: Tue, 10 Jun 2003 18:03:04 -0700 (Pacific Daylight Time)
From: Mark Crispin <MRC@CAC.Washington.EDU>
To: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: Re: [lemonade] Strawman for Submit based message composition
In-Reply-To: <3EE67B17.7080208@Royer.com>
Message-ID: <Pine.WNT.4.60.0306101753331.2408@Tomobiki-Cho.CAC.Washington.EDU>
References: <2147483647.1055264863@nifty-jr.west.sun.com> <3EE67B17.7080208@Royer.com>
Organization: Networks & Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Tue, 10 Jun 2003, Doug Royer wrote:
> Interesting idea.

Golly gee.  Chris' strawman is essentially what I've been talking about.
The main new thing is the use of SMTP CHUNKING.  But I deliberately left
the mechanics of submission unspecified.

> I think the GENRUL command could be eliminated:
>
>   As the client is going to be sent something that tells it that
>   a non-downloaded body part exits, why not make that something
>   compatible with the 'BURL'?

Huh?  That's what GENURL creates.

>   Now that round trip is eliminated.
>   Generating some authentication token / UID or CID/MID / whatever
>   can not be that complex for each non-downloaded body part or
>   message.

If you're talking about the client generating the URL, then perhaps we can
have something returned at select time that allows the client to build
URLs for any data in the mailbox via a well-known algorithm.

All that's needed is something that the IMAP server, upon receiving the
URL, can validate that an authorized client generated it.  So it's
important that a bad guy can't use an valid URL to create one of his own.

Chris can probably come up with a way to do that.

-- 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 mailnull@www1.ietf.org  Tue Jun 10 21:09:38 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25228
	for <lemonade-archive@odin.ietf.org>; Tue, 10 Jun 2003 21:09:38 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5B19CB11190
	for lemonade-archive@odin.ietf.org; Tue, 10 Jun 2003 21:09:12 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B19CB11187
	for <lemonade-web-archive@optimus.ietf.org>; Tue, 10 Jun 2003 21:09:12 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25209
	for <lemonade-web-archive@ietf.org>; Tue, 10 Jun 2003 21:09:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pu4v-0003hw-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 21:07:05 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pu4u-0003ht-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 21:07:04 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B191B11171;
	Tue, 10 Jun 2003 21:09:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B18eB11135
	for <lemonade@optimus.ietf.org>; Tue, 10 Jun 2003 21:08:40 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25177
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 21:08:36 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pu4P-0003hY-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 21:06:33 -0400
Received: from inet-consulting.com ([4.23.9.166] helo=royer.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pu4O-0003hU-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 21:06:32 -0400
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h5B18Tbt000354
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 18:08:34 -0700
Message-ID: <3EE68104.4010409@Royer.com>
Date: Tue, 10 Jun 2003 19:08:20 -0600
From: Doug Royer <Doug@Royer.com>
Reply-To: lemonade@ietf.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: lemonade@ietf.org
Subject: Re: [lemonade] Re: IMAP as a submit server
References: <54E40201497DF142B06B27255953F79705BFD86F@il0015exch007u.ih.lucent.com> <Pine.WNT.4.60.0306101039160.2760@Tomobiki-Cho.CAC.Washington.EDU> <p06001419bb0bc963f08d@[216.43.25.67]> <Pine.WNT.4.60.0306101239060.2408@Tomobiki-Cho.CAC.Washington.EDU> <p0600141abb0bfec9749c@[216.43.25.67]> <Pine.WNT.4.60.0306101436010.2408@Tomobiki-Cho.CAC.Washington.EDU> <3EE6653E.9020109@Royer.com> <Pine.WNT.4.60.0306101611500.2408@Tomobiki-Cho.CAC.Washington.EDU> <3EE678C1.1020000@Royer.com> <Pine.WNT.4.60.0306101736330.2408@Tomobiki-Cho.CAC.Washington.EDU>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060905050703030002020105"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This is a cryptographically signed message in MIME format.

--------------ms060905050703030002020105
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Mark Crispin wrote:
> On Tue, 10 Jun 2003, Doug Royer wrote:
> 
>>Simple reader/writer locks - that is the exact scenario they
>>were designed to solve. Nothing complex needed. And no protocol
>>changes needed.
> 
> 
> How are these locks to be applied without protocol changes?

The need to share objects that can be deleted out from under
you is not unique to IMAP. It is an server implementaiton detail.
And it does not need to be in any existing IMAP or IMAP related
RFC to be discussed on this list.

This is not the IMAP mailing list. This is a mailing list
to discuss among other things ways of solving a problem for
clients that have somewhat low speed and expensive connections.

One option is to extend IMAP to allow it to submit. I am also
sure that you will not see this discussion or my comments
in an existing IMAP or IMAP related RFC.

 > ...


-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  Doug@Royer.com                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

--------------ms060905050703030002020105
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC
A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j
cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB
MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T
BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN
VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre
qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+
5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA
MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg
TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD
QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx
ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz
IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq
hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34
1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA
gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK
YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd
SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC
AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF
BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl
cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl
IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs
MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq
1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2
TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail
MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE
AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO
b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG
MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD
VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV
BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv
43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y
lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP
D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn
0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK
bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg
hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT
IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI
AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t
L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk
OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW
yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1
MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl
ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTEwMTA4MjBaMCMGCSqGSIb3DQEJBDEWBBTm
KpqnYAiLqLk3EL2LV1NB4aVmnDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL
KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAjOIq5CMAX2Rw
EdNtsH9DFSS+3o5IOVWXgvrTn2w0UqGIBPMlsoiR+M+Dq7C8hahQU3RA7MTh/C28QIxoAr+n
bGJmTJtB0+xrWyblVr5sWuJJgL4Ovp40ceRiTsQ+irLBWP7FmMuVGrNVhqGIAsFHPcO4owBz
J3wWb+yDrS0wRlDcAvJH8fgRyZ1RF/pdBQIaBd1i1QkBRh0SrSZQkzOPCdDt2fHPRse80cLc
Ay9ojUCnrMyma/MTWSjK/6ixF/zo1cFV0Zo+3g70sQdfoM4A35KE4dLfGOOQdfOI54qoDWXK
4/Tp/KZipPGl4lJBuOmgB/JqjGbHP4WhDG/9Ob84lgAAAAAAAA==
--------------ms060905050703030002020105--

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



From mailnull@www1.ietf.org  Tue Jun 10 21:24:40 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25583
	for <lemonade-archive@odin.ietf.org>; Tue, 10 Jun 2003 21:24:40 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5B1OEu11700
	for lemonade-archive@odin.ietf.org; Tue, 10 Jun 2003 21:24:14 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B1OEB11697
	for <lemonade-web-archive@optimus.ietf.org>; Tue, 10 Jun 2003 21:24:14 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25579
	for <lemonade-web-archive@ietf.org>; Tue, 10 Jun 2003 21:24:09 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PuJS-0003m5-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 21:22:06 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PuJS-0003m2-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 21:22:06 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B1O4B11688;
	Tue, 10 Jun 2003 21:24:04 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B1NeB11664
	for <lemonade@optimus.ietf.org>; Tue, 10 Jun 2003 21:23:40 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25576
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 21:23:35 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PuIu-0003lq-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 21:21:32 -0400
Received: from mxout5.cac.washington.edu ([140.142.32.135])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PuIu-0003lm-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 21:21:32 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9])
	by mxout5.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h5B1NZt7000316
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 18:23:35 -0700
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
	(authenticated bits=0)
	by smtp.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h5B1NY7k011365
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT)
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 18:23:34 -0700
Date: Tue, 10 Jun 2003 18:23:35 -0700 (Pacific Daylight Time)
From: Mark Crispin <MRC@CAC.Washington.EDU>
To: lemonade@ietf.org
Subject: Re: [lemonade] Re: IMAP as a submit server
In-Reply-To: <3EE68104.4010409@Royer.com>
Message-ID: <Pine.WNT.4.60.0306101811190.2408@Tomobiki-Cho.CAC.Washington.EDU>
References: <54E40201497DF142B06B27255953F79705BFD86F@il0015exch007u.ih.lucent.com>
 <Pine.WNT.4.60.0306101039160.2760@Tomobiki-Cho.CAC.Washington.EDU>
 <p06001419bb0bc963f08d@[216.43.25.67]> <Pine.WNT.4.60.0306101239060.2408@Tomobiki-Cho.CAC.Washington.EDU>
 <p0600141abb0bfec9749c@[216.43.25.67]> <Pine.WNT.4.60.0306101436010.2408@Tomobiki-Cho.CAC.Washington.EDU>
 <3EE6653E.9020109@Royer.com> <Pine.WNT.4.60.0306101611500.2408@Tomobiki-Cho.CAC.Washington.EDU>
 <3EE678C1.1020000@Royer.com> <Pine.WNT.4.60.0306101736330.2408@Tomobiki-Cho.CAC.Washington.EDU>
 <3EE68104.4010409@Royer.com>
Organization: Networks & Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Tue, 10 Jun 2003, Doug Royer wrote:
> The need to share objects that can be deleted out from under
> you is not unique to IMAP. It is an server implementaiton detail.

Sorry, you are wrong.

It is part of the IMAP protocol specification that shared objects can be
deleted out from under you.

Refer to RFC 2180, section 4.1, and RFC 3501, section 5.2.  Pay careful
attention to text related to the EXPUNGE response.

> And it does not need to be in any existing IMAP or IMAP related
> RFC to be discussed on this list.

The contents of IMAP and IMAP related RFCs are very relevant when you are
talking about *violating* the protocol without making a change to the
protocol to allow this violation.

In the case of locking, you are talking about adding new assumptions which
current do not exist, and deleting other assumptions that do exist.  Yet
you seem to think that this can be done without changing the protocol.

> This is not the IMAP mailing list. This is a mailing list
> to discuss among other things ways of solving a problem for
> clients that have somewhat low speed and expensive connections.

If you expect IMAP to be part of that solution, then you have to consider
the characteristics of IMAP.  You can't pretend that these considerations
don't exist.

It's too late to remove unsolicited EXPUNGE responses from the IMAP
protocol.  The time to do that was about 18 years ago.  It's there now,
clients use it, and users depend upon it.

> One option is to extend IMAP to allow it to submit. I am also
> sure that you will not see this discussion or my comments
> in an existing IMAP or IMAP related RFC.

If you expect IMAP to provide any form of locking, it will have to be in
an IMAP related RFC.

-- 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 mailnull@www1.ietf.org  Tue Jun 10 21:28:42 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25642
	for <lemonade-archive@odin.ietf.org>; Tue, 10 Jun 2003 21:28:42 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5B1SGk11859
	for lemonade-archive@odin.ietf.org; Tue, 10 Jun 2003 21:28:16 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B1SGB11856
	for <lemonade-web-archive@optimus.ietf.org>; Tue, 10 Jun 2003 21:28:16 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25634
	for <lemonade-web-archive@ietf.org>; Tue, 10 Jun 2003 21:28:12 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PuNN-0003nN-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 21:26:09 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PuNM-0003nK-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 21:26:08 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B1S7B11833;
	Tue, 10 Jun 2003 21:28:07 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B1RMB11790
	for <lemonade@optimus.ietf.org>; Tue, 10 Jun 2003 21:27:22 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25617
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 21:27:17 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PuMU-0003mx-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 21:25:14 -0400
Received: from iere.net.avaya.com ([198.152.12.101])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PuMU-0003mr-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 21:25:14 -0400
Received: from iere.net.avaya.com (localhost [127.0.0.1])
	by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id h5B1O7213959
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 21:24:07 -0400 (EDT)
Received: from bighorn.dr.avaya.com (h135-9-1-59.avaya.com [135.9.1.59])
	by iere.net.avaya.com (8.11.2/8.9.3) with SMTP id h5B1O6R13939;
	Tue, 10 Jun 2003 21:24:06 -0400 (EDT)
Received: from avaya.com by bighorn.dr.avaya.com (SMI-8.6/EMS-1.5 sol2)
	id TAA27914; Tue, 10 Jun 2003 19:27:15 -0600
Message-ID: <3EE68474.1000409@avaya.com>
Date: Tue, 10 Jun 2003 19:23:00 -0600
From: Rick Block <rickblock@avaya.com>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
CC: Cyrus Daboo <daboo@cyrusoft.com>, Randall Gellens
 <randy@qualcomm.com>,
        "IETF LEMONADE (E-mail)" <lemonade@ietf.org>,
        Doug
 Royer <Doug@royer.com>
Subject: Re: [lemonade] Re: Just 'ATTACH'
References: <54E40201497DF142B06B27255953F79705BFDBF6@il0015exch007u.ih.lucent.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


Vaudreuil, Greg M (Greg) wrote:
> I don't see the requirement for submit server resolution
 > of external documents and the like...  Maybe others have
 > a need for that, but I see the resolution of an external
 > URL as the obligation of the recipient UA.

Obligation of the recipient UA?  I have a message from
anyone@anywhere.com, I reply from my wireless device (with
original attached) and my friend anyone's UA is responsible
for putting the message together again (using pieces
of the original message sent to me obtained from my imap4
server)?  I must be misunderstanding this since it would
seem to require upgrading every UA everywhere in the world
and even if this could happen then requires my imap4 server
be accessible from anywhere.

Rick Block
Avaya Inc.


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



From mailnull@www1.ietf.org  Tue Jun 10 21:37:44 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25832
	for <lemonade-archive@odin.ietf.org>; Tue, 10 Jun 2003 21:37:44 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5B1bIH12707
	for lemonade-archive@odin.ietf.org; Tue, 10 Jun 2003 21:37:18 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B1bIB12704
	for <lemonade-web-archive@optimus.ietf.org>; Tue, 10 Jun 2003 21:37:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25826
	for <lemonade-web-archive@ietf.org>; Tue, 10 Jun 2003 21:37:13 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PuW7-0003qJ-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 21:35:11 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PuW6-0003qG-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 21:35:10 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B1b5B12305;
	Tue, 10 Jun 2003 21:37:05 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B1ajB12151
	for <lemonade@optimus.ietf.org>; Tue, 10 Jun 2003 21:36:45 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25820
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 21:36:41 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PuVa-0003q6-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 21:34:38 -0400
Received: from mxout1.cac.washington.edu ([140.142.32.134])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PuVZ-0003pr-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 21:34:37 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139])
	by mxout1.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h5B1aaRG024051
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 18:36:36 -0700
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
	(authenticated bits=0)
	by smtp.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h5B1aaQ0013968
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT)
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 18:36:36 -0700
Date: Tue, 10 Jun 2003 18:36:37 -0700 (Pacific Daylight Time)
From: Mark Crispin <MRC@CAC.Washington.EDU>
To: lemonade@ietf.org
Subject: Re: [lemonade] Re: IMAP as a submit server
In-Reply-To: <Pine.WNT.4.60.0306101811190.2408@Tomobiki-Cho.CAC.Washington.EDU>
Message-ID: <Pine.WNT.4.60.0306101827080.2408@Tomobiki-Cho.CAC.Washington.EDU>
References: <54E40201497DF142B06B27255953F79705BFD86F@il0015exch007u.ih.lucent.com>
 <Pine.WNT.4.60.0306101039160.2760@Tomobiki-Cho.CAC.Washington.EDU>
 <p06001419bb0bc963f08d@[216.43.25.67]> <Pine.WNT.4.60.0306101239060.2408@Tomobiki-Cho.CAC.Washington.EDU>
 <p0600141abb0bfec9749c@[216.43.25.67]> <Pine.WNT.4.60.0306101436010.2408@Tomobiki-Cho.CAC.Washington.EDU>
 <3EE6653E.9020109@Royer.com> <Pine.WNT.4.60.0306101611500.2408@Tomobiki-Cho.CAC.Washington.EDU>
 <3EE678C1.1020000@Royer.com> <Pine.WNT.4.60.0306101736330.2408@Tomobiki-Cho.CAC.Washington.EDU>
 <3EE68104.4010409@Royer.com> <Pine.WNT.4.60.0306101811190.2408@Tomobiki-Cho.CAC.Washington.EDU>
Organization: Networks & Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Tue, 10 Jun 2003, Mark Crispin wrote:
> It is part of the IMAP protocol specification that shared objects can be
> deleted out from under you.

Not only is it a part of the protocol, it is a *feature* of the protocol.

Like other features, it is sometimes a good thing and sometimes a bad
thing.  The important thing is that it *is*.

We have a timing race, in which data may disappear between the time that
it is identified for submission and when the submission entity actually
gets around to fetching it.

One possible response is to ignore the problem.  That isn't as
unreasonable as it sounds.  It will almost never happen except in the case
of user error.  There is ample precedent for "we aren't going to bend over
backwards to stop someone, who is determined to lose, from losing."

Another possible response is to create a mechanism to solve the problem.
That mechanism will require the introduction of locking semantics into the
IMAP protocol; at a minimum, it is necessary to have a means to disable
shared expunge, and subsequently to re-enable it.

Yet another possible response is to do an end run around the problem, by
using a proxy server.

-- 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 mailnull@www1.ietf.org  Tue Jun 10 23:11:37 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27773
	for <lemonade-archive@odin.ietf.org>; Tue, 10 Jun 2003 23:11:37 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5B3BEV19553
	for lemonade-archive@odin.ietf.org; Tue, 10 Jun 2003 23:11:14 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B3BDB19550
	for <lemonade-web-archive@optimus.ietf.org>; Tue, 10 Jun 2003 23:11:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27763
	for <lemonade-web-archive@ietf.org>; Tue, 10 Jun 2003 23:11:06 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pvyy-0004HJ-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 23:09:04 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pvyx-0004HG-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 23:09:03 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B3B4B19542;
	Tue, 10 Jun 2003 23:11:04 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B3AmB19524
	for <lemonade@optimus.ietf.org>; Tue, 10 Jun 2003 23:10:48 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27747
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 23:10:41 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PvyY-0004Gu-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 23:08:38 -0400
Received: from smtp6.andrew.cmu.edu ([128.2.10.86])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PvyX-0004Gr-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 23:08:37 -0400
Received: from dunbar.rem.cmu.edu (DUNBAR.REM.cmu.edu [128.2.4.197])
	by smtp6.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h5B3Aenw001638;
	Tue, 10 Jun 2003 23:10:40 -0400
Date: Tue, 10 Jun 2003 23:10:40 -0400
Message-Id: <200306110310.h5B3Aenw001638@smtp6.andrew.cmu.edu>
From: Lawrence Greenfield <leg+@andrew.cmu.edu>
X-Mailer: BatIMail version 3.3
To: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>,
        Chris Newman <Chris.Newman@Sun.COM>
In-reply-to: <2147483647.1055264863@nifty-jr.west.sun.com>
Subject: Re: [lemonade] Strawman for Submit based message composition
References: <2147483647.1055264863@nifty-jr.west.sun.com>
User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory?=
 =?ISO-8859-4?Q?=F2mae?=) Emacs/21.2 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

   Date: Tue, 10 Jun 2003 17:07:43 -0700
   From: Chris Newman <Chris.Newman@Sun.COM>

   This extension alone would solve the forward-without-download
   extension for the subset of the problem space where the submit
   server has pre-existing trust relationship with the IMAP server.

   Indeed since 99% of the world uses plain text passwords (with or
   without TLS) for authentication.  Authenticating to the submit
   server will grant sufficient rights for the user to access and
   forward their own mail from IMAP anyway.  So why not use it when
   appropriate?

I'd rather not see these sort of trust relationships
supported. Implementations relying on receiving sufficient credentials
for further authentication just puts yet another burden on places that
want to avoid plaintext passwords. I'd rather see everyone use
something like GENURL/GETURL; if the "plaintext trust" mechanism is
supported, that's what everyone will test and the GENURL/GETURL won't
work with a substantial number of clients and servers.

Note that Chris's strawman does not address a couple of somewhat
interesting things:

. the setup costs of an SMTP session 

  I'm sure some people would get grumpy if the clients just had
  long-running SMTP connections to amortize the cost.

. a carbon copies folder

  One possible solution for carbon copies would be to standardize an
  IMAP annotation for "give me an e-mail address that will post
  directly to this mailbox". (This is also desirable for shared
  mailboxes.)

. synchronity of the submission server

  Does the submission server have to fetch external parts
  synchronously before returning success or failure to the client?

Larry

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



From mailnull@www1.ietf.org  Tue Jun 10 23:21:43 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27924
	for <lemonade-archive@odin.ietf.org>; Tue, 10 Jun 2003 23:21:43 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5B3LFY19910
	for lemonade-archive@odin.ietf.org; Tue, 10 Jun 2003 23:21:15 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B3LFB19907
	for <lemonade-web-archive@optimus.ietf.org>; Tue, 10 Jun 2003 23:21:15 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27919
	for <lemonade-web-archive@ietf.org>; Tue, 10 Jun 2003 23:21:13 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pw8k-0004K1-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 23:19:10 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pw8k-0004Jy-00
	for lemonade-web-archive@ietf.org; Tue, 10 Jun 2003 23:19:10 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B3L1B19891;
	Tue, 10 Jun 2003 23:21:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B3KgB19872
	for <lemonade@optimus.ietf.org>; Tue, 10 Jun 2003 23:20:42 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27907
	for <lemonade@ietf.org>; Tue, 10 Jun 2003 23:20:40 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pw8D-0004Jk-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 23:18:37 -0400
Received: from panda.com
	([206.124.149.114] helo=Ikkoku-Kan.Panda.COM ident=v92ti)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pw8C-0004Jh-00
	for lemonade@ietf.org; Tue, 10 Jun 2003 23:18:36 -0400
Received: from localhost (mrc@localhost) by Ikkoku-Kan.Panda.COM id UAA20390; Tue, 10 Jun 2003 20:20:35 -0700 (PDT)
Date: Tue, 10 Jun 2003 20:20:35 -0700 (PDT)
From: Mark Crispin <mrc@CAC.Washington.EDU>
To: Lawrence Greenfield <leg+@andrew.cmu.edu>
cc: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>,
        Chris Newman <Chris.Newman@Sun.COM>
Subject: Re: [lemonade] Strawman for Submit based message composition
In-Reply-To: <200306110310.h5B3Aenw001638@smtp6.andrew.cmu.edu>
Message-ID: <Pine.NXT.4.56.0306102018520.11845@Ikkoku-Kan.Panda.COM>
References: <2147483647.1055264863@nifty-jr.west.sun.com>
 <200306110310.h5B3Aenw001638@smtp6.andrew.cmu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Tue, 10 Jun 2003, Lawrence Greenfield wrote:
>   One possible solution for carbon copies would be to standardize an
>   IMAP annotation for "give me an e-mail address that will post
>   directly to this mailbox". (This is also desirable for shared
>   mailboxes.)

I agree; we really need something like this.

However, it's a non-issue with the proxy server approach.

-- 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 mailnull@www1.ietf.org  Wed Jun 11 04:46:34 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29669
	for <lemonade-archive@odin.ietf.org>; Wed, 11 Jun 2003 04:46:34 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5B8k8x19620
	for lemonade-archive@odin.ietf.org; Wed, 11 Jun 2003 04:46:08 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B8k8B19617
	for <lemonade-web-archive@optimus.ietf.org>; Wed, 11 Jun 2003 04:46:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29657
	for <lemonade-web-archive@ietf.org>; Wed, 11 Jun 2003 04:46:04 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q1D7-0005vL-00
	for lemonade-web-archive@ietf.org; Wed, 11 Jun 2003 04:44:01 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q1D6-0005vI-00
	for lemonade-web-archive@ietf.org; Wed, 11 Jun 2003 04:44:00 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B8k3B19603;
	Wed, 11 Jun 2003 04:46:03 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B8jvB19589
	for <lemonade@optimus.ietf.org>; Wed, 11 Jun 2003 04:45:57 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29653
	for <lemonade@ietf.org>; Wed, 11 Jun 2003 04:45:52 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q1Cv-0005vF-00
	for lemonade@ietf.org; Wed, 11 Jun 2003 04:43:49 -0400
Received: from comversegw.icomverse.com ([192.118.48.248] helo=il-tlv-smtpout1.icomverse.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q1Cu-0005vC-00
	for lemonade@ietf.org; Wed, 11 Jun 2003 04:43:48 -0400
Received: from il-tlv-mbdg1.comverse.com (localhost.localdomain [127.0.0.1])
	by il-tlv-smtpout1.icomverse.com (8.11.6/8.11.6) with ESMTP id h5B8jT906003;
	Wed, 11 Jun 2003 11:45:29 +0300
Received: by il-tlv-mbdg1.comverse.com with Internet Mail Service (5.5.2655.55)
	id <M2S5JSYQ>; Wed, 11 Jun 2003 11:45:36 +0300
Message-ID: <7D4344E32B34D511A6500002A560C60204D892F5@il-tlv-mail4.comverse.com>
From: Erev Ari <Ari.Erev@comverse.com>
To: "'Chris Newman'" <Chris.Newman@sun.com>,
        "IETF LEMONADE (E-mail)"
	 <lemonade@ietf.org>
Subject: RE: [lemonade] Strawman for Submit based message composition
Date: Wed, 11 Jun 2003 11:45:34 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C32FF5.D24D9A60"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C32FF5.D24D9A60
Content-Type: text/plain;
	charset="iso-8859-1"

Chris,

Isn't the GENURL/GETURL very similar to the proposed IMAP CHANNEL extension?
http://www.ietf.org/internet-drafts/draft-nerenberg-imap-channel-03.txt (now
expired)

As far as I remember with CHANNEL you could ask the IMAP server for a "URL"
for a specific MIME part of a message (or to the whole message)

Ari

> -----Original Message-----
> From: Chris Newman [mailto:Chris.Newman@sun.com]
> Sent: Wednesday, June 11, 2003 3:08 AM
> To: IETF LEMONADE (E-mail)
> Subject: [lemonade] Strawman for Submit based message composition
> 
> 
> I'll start by defining message composition as the process of 
> assembling
> multiple byte-counted objects from potentially different 
> locations into a
> single byte stream.  IMAP has no such facility.
> 
> SMTP/Submit, however, already has 90% of this facility with 
> the CHUNKING
> extension.  In particular, it assembles a series of 
> byte-counted objects into a
> single byte stream.
> 
> Suppose we create a new Submit extension called "BURL" which 
> can be interleaved
> with "BDAT" commands.  So you can now compose a message as follows:
> 
> BDAT ....               headers and first part
> BURL 8bit <imap-url>    forwarded 8bit content from IMAP
> BDAT ....               MIME delimiters or whatever
> BURL base64 <http-url>  get http content, base64 encode it 
> and include it
> BDAT ....               final data
> 
> This can all be pipelined into one round-trip.
> 
> The BURL extension should advertise what types of URLs it supports:
> 
> 250-BURL http imap://trusted-host.example.com/
> 
> This extension alone would solve the forward-without-download 
> extension for the
> subset of the problem space where the submit server has 
> pre-existing trust
> relationship with the IMAP server.
> 
> Indeed since 99% of the world uses plain text passwords (with 
> or without TLS)
> for authentication.  Authenticating to the submit server will 
> grant sufficient
> rights for the user to access and forward their own mail from 
> IMAP anyway.  So
> why not use it when appropriate?
> 
> If we wanted to go for the additional case where there isn't a trust
> relationship between the submit server and IMAP server, then 
> we simply add two
> extensions to IMAP:
> 
> 1. a "GENURL" command which turns a message or body-part 
> reference within the
> selected mailbox into an extended IMAP URL with an 
> authorization token.  This
> could either have a time-limit or a number of use limit.  The 
> authorization
> token would likely be an HMAC-MD5 covering the URL, a nonce, 
> a time-limit and
> using a per-user random secret known only to the IMAP server.
> 
> 2. a "GETURL" command which is accessible by any IMAP user (including
> anonymous) which returns a literal of the the relevant 
> message/body part if the
> authorization token is valid.
> 
> This just doesn't seem complicated to me.  Indeed it seems 
> much simpler than
> any approach to extending IMAP with a redundant submission 
> and composition
> facility in addition to the one already present in CHUNKING Submit.
> 
>                 - Chris
> 
> _______________________________________________
> lemonade mailing list
> lemonade@ietf.org
> https://www1.ietf.org/mailman/listinfo/lemonade
> 

------_=_NextPart_001_01C32FF5.D24D9A60
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: [lemonade] Strawman for Submit based message =
composition</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Chris,</FONT>
</P>

<P><FONT SIZE=3D2>Isn't the GENURL/GETURL very similar to the proposed =
IMAP CHANNEL extension?</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-nerenberg-imap-channel=
-03.txt" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-nerenberg-im=
ap-channel-03.txt</A> (now expired)</FONT>
</P>

<P><FONT SIZE=3D2>As far as I remember with CHANNEL you could ask the =
IMAP server for a &quot;URL&quot; for a specific MIME part of a message =
(or to the whole message)</FONT></P>

<P><FONT SIZE=3D2>Ari</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Chris Newman [<A =
HREF=3D"mailto:Chris.Newman@sun.com">mailto:Chris.Newman@sun.com</A>]</F=
ONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, June 11, 2003 3:08 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: IETF LEMONADE (E-mail)</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: [lemonade] Strawman for Submit based =
message composition</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I'll start by defining message composition as =
the process of </FONT>
<BR><FONT SIZE=3D2>&gt; assembling</FONT>
<BR><FONT SIZE=3D2>&gt; multiple byte-counted objects from potentially =
different </FONT>
<BR><FONT SIZE=3D2>&gt; locations into a</FONT>
<BR><FONT SIZE=3D2>&gt; single byte stream.&nbsp; IMAP has no such =
facility.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; SMTP/Submit, however, already has 90% of this =
facility with </FONT>
<BR><FONT SIZE=3D2>&gt; the CHUNKING</FONT>
<BR><FONT SIZE=3D2>&gt; extension.&nbsp; In particular, it assembles a =
series of </FONT>
<BR><FONT SIZE=3D2>&gt; byte-counted objects into a</FONT>
<BR><FONT SIZE=3D2>&gt; single byte stream.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Suppose we create a new Submit extension called =
&quot;BURL&quot; which </FONT>
<BR><FONT SIZE=3D2>&gt; can be interleaved</FONT>
<BR><FONT SIZE=3D2>&gt; with &quot;BDAT&quot; commands.&nbsp; So you =
can now compose a message as follows:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; BDAT =
....&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp; headers and first part</FONT>
<BR><FONT SIZE=3D2>&gt; BURL 8bit &lt;imap-url&gt;&nbsp;&nbsp;&nbsp; =
forwarded 8bit content from IMAP</FONT>
<BR><FONT SIZE=3D2>&gt; BDAT =
....&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp; MIME delimiters or whatever</FONT>
<BR><FONT SIZE=3D2>&gt; BURL base64 &lt;http-url&gt;&nbsp; get http =
content, base64 encode it </FONT>
<BR><FONT SIZE=3D2>&gt; and include it</FONT>
<BR><FONT SIZE=3D2>&gt; BDAT =
....&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp; final data</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; This can all be pipelined into one =
round-trip.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The BURL extension should advertise what types =
of URLs it supports:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 250-BURL http =
imap://trusted-host.example.com/</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; This extension alone would solve the =
forward-without-download </FONT>
<BR><FONT SIZE=3D2>&gt; extension for the</FONT>
<BR><FONT SIZE=3D2>&gt; subset of the problem space where the submit =
server has </FONT>
<BR><FONT SIZE=3D2>&gt; pre-existing trust</FONT>
<BR><FONT SIZE=3D2>&gt; relationship with the IMAP server.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Indeed since 99% of the world uses plain text =
passwords (with </FONT>
<BR><FONT SIZE=3D2>&gt; or without TLS)</FONT>
<BR><FONT SIZE=3D2>&gt; for authentication.&nbsp; Authenticating to the =
submit server will </FONT>
<BR><FONT SIZE=3D2>&gt; grant sufficient</FONT>
<BR><FONT SIZE=3D2>&gt; rights for the user to access and forward their =
own mail from </FONT>
<BR><FONT SIZE=3D2>&gt; IMAP anyway.&nbsp; So</FONT>
<BR><FONT SIZE=3D2>&gt; why not use it when appropriate?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If we wanted to go for the additional case =
where there isn't a trust</FONT>
<BR><FONT SIZE=3D2>&gt; relationship between the submit server and IMAP =
server, then </FONT>
<BR><FONT SIZE=3D2>&gt; we simply add two</FONT>
<BR><FONT SIZE=3D2>&gt; extensions to IMAP:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 1. a &quot;GENURL&quot; command which turns a =
message or body-part </FONT>
<BR><FONT SIZE=3D2>&gt; reference within the</FONT>
<BR><FONT SIZE=3D2>&gt; selected mailbox into an extended IMAP URL with =
an </FONT>
<BR><FONT SIZE=3D2>&gt; authorization token.&nbsp; This</FONT>
<BR><FONT SIZE=3D2>&gt; could either have a time-limit or a number of =
use limit.&nbsp; The </FONT>
<BR><FONT SIZE=3D2>&gt; authorization</FONT>
<BR><FONT SIZE=3D2>&gt; token would likely be an HMAC-MD5 covering the =
URL, a nonce, </FONT>
<BR><FONT SIZE=3D2>&gt; a time-limit and</FONT>
<BR><FONT SIZE=3D2>&gt; using a per-user random secret known only to =
the IMAP server.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 2. a &quot;GETURL&quot; command which is =
accessible by any IMAP user (including</FONT>
<BR><FONT SIZE=3D2>&gt; anonymous) which returns a literal of the the =
relevant </FONT>
<BR><FONT SIZE=3D2>&gt; message/body part if the</FONT>
<BR><FONT SIZE=3D2>&gt; authorization token is valid.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; This just doesn't seem complicated to me.&nbsp; =
Indeed it seems </FONT>
<BR><FONT SIZE=3D2>&gt; much simpler than</FONT>
<BR><FONT SIZE=3D2>&gt; any approach to extending IMAP with a redundant =
submission </FONT>
<BR><FONT SIZE=3D2>&gt; and composition</FONT>
<BR><FONT SIZE=3D2>&gt; facility in addition to the one already present =
in CHUNKING Submit.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Chris</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; lemonade mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; lemonade@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/lemonade" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/lemonade</A></F=
ONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C32FF5.D24D9A60--
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Wed Jun 11 10:00:49 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09302
	for <lemonade-archive@odin.ietf.org>; Wed, 11 Jun 2003 10:00:49 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5BE0O710394
	for lemonade-archive@odin.ietf.org; Wed, 11 Jun 2003 10:00:24 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BE0OB10391
	for <lemonade-web-archive@optimus.ietf.org>; Wed, 11 Jun 2003 10:00:24 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09288
	for <lemonade-web-archive@ietf.org>; Wed, 11 Jun 2003 10:00:19 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q67D-0000Yc-00
	for lemonade-web-archive@ietf.org; Wed, 11 Jun 2003 09:58:15 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q67C-0000YX-00
	for lemonade-web-archive@ietf.org; Wed, 11 Jun 2003 09:58:14 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BE05B10367;
	Wed, 11 Jun 2003 10:00:05 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BDxNB09764
	for <lemonade@optimus.ietf.org>; Wed, 11 Jun 2003 09:59:23 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09249
	for <lemonade@ietf.org>; Wed, 11 Jun 2003 09:59:18 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q66E-0000YI-00
	for lemonade@ietf.org; Wed, 11 Jun 2003 09:57:14 -0400
Received: from iere.net.avaya.com ([198.152.12.101])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q66D-0000YB-00
	for lemonade@ietf.org; Wed, 11 Jun 2003 09:57:13 -0400
Received: from iere.net.avaya.com (localhost [127.0.0.1])
	by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id h5BDu7c29194
	for <lemonade@ietf.org>; Wed, 11 Jun 2003 09:56:07 -0400 (EDT)
Received: from bighorn.dr.avaya.com (h135-9-1-59.avaya.com [135.9.1.59])
	by iere.net.avaya.com (8.11.2/8.9.3) with SMTP id h5BDu6b29144;
	Wed, 11 Jun 2003 09:56:06 -0400 (EDT)
Received: from avaya.com by bighorn.dr.avaya.com (SMI-8.6/EMS-1.5 sol2)
	id HAA11020; Wed, 11 Jun 2003 07:59:15 -0600
Message-ID: <3EE735D3.6020709@avaya.com>
Date: Wed, 11 Jun 2003 07:59:47 -0600
From: Rick Block <rickblock@avaya.com>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mark Crispin <mrc@CAC.Washington.EDU>
CC: Lawrence Greenfield <leg+@andrew.cmu.edu>,
        "IETF LEMONADE (E-mail)"
 <lemonade@ietf.org>,
        Chris Newman <Chris.Newman@sun.com>
Subject: Re: [lemonade] Strawman for Submit based message composition
References: <2147483647.1055264863@nifty-jr.west.sun.com> <200306110310.h5B3Aenw001638@smtp6.andrew.cmu.edu> <Pine.NXT.4.56.0306102018520.11845@Ikkoku-Kan.Panda.COM>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


Mark Crispin wrote:
> On Tue, 10 Jun 2003, Lawrence Greenfield wrote:
> 
>>  One possible solution for carbon copies would be to standardize an
>>  IMAP annotation for "give me an e-mail address that will post
>>  directly to this mailbox".
> 
>
> However, it's a non-issue with the proxy server approach.
> 

Non-issue meaning both the (SMTP-ish) submit and the (IMAP-ish)
append to "sent" folder would be handled by the proxy which is
in a position to expand any external references for each of
these operations.  On the other hand, if bandwidth is so precious
and latency so high perhaps the proxy server should be doing
the copy to sent folder operation itself rather than the
ultimate client, which makes the submit operation a little less
SMTP-ish.

Rick Block
Avaya Inc.

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



From mailnull@www1.ietf.org  Wed Jun 11 10:44:58 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11890
	for <lemonade-archive@odin.ietf.org>; Wed, 11 Jun 2003 10:44:57 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5BEiX904792
	for lemonade-archive@odin.ietf.org; Wed, 11 Jun 2003 10:44:33 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BEiXm04789
	for <lemonade-web-archive@optimus.ietf.org>; Wed, 11 Jun 2003 10:44:33 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11854
	for <lemonade-web-archive@ietf.org>; Wed, 11 Jun 2003 10:44:27 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q6nw-0000pg-00
	for lemonade-web-archive@ietf.org; Wed, 11 Jun 2003 10:42:24 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q6nv-0000pa-00
	for lemonade-web-archive@ietf.org; Wed, 11 Jun 2003 10:42:23 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BEiJm04708;
	Wed, 11 Jun 2003 10:44:19 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BEcBm04456
	for <lemonade@optimus.ietf.org>; Wed, 11 Jun 2003 10:38:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11665
	for <lemonade@ietf.org>; Wed, 11 Jun 2003 10:38:05 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q6hm-0000nQ-00
	for lemonade@ietf.org; Wed, 11 Jun 2003 10:36:02 -0400
Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q6hl-0000mu-00
	for lemonade@ietf.org; Wed, 11 Jun 2003 10:36:01 -0400
Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83])
	by ihemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h5BEbXP25917
	for <lemonade@ietf.org>; Wed, 11 Jun 2003 09:37:33 -0500 (CDT)
Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19)
	id <L2XMBY4M>; Wed, 11 Jun 2003 09:37:33 -0500
Message-ID: <54E40201497DF142B06B27255953F79705BFDF0B@il0015exch007u.ih.lucent.com>
From: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
To: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Date: Wed, 11 Jun 2003 09:37:30 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [lemonade] Call for requirement consensus
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>


Do we all agree that lemonade requirements should specify a basic forward of message or atomic message part without download and not a remote composition service?

I am interested in hearing objections and reasons or examples of where a remote composition service would be of material benefit in scope of the lemonade charter goals.

Greg V.

-----Original Message-----
From: Randall Gellens [mailto:randy@qualcomm.com]
Sent: Tuesday, June 10, 2003 1:55 PM
To: Cyrus Daboo; Randall Gellens; IETF LEMONADE (E-mail)
Cc: Doug Royer
Subject: Re: [lemonade] Re: Just 'ATTACH'


Hi Cyrus,

At 12:36 PM -0400 6/10/03, Cyrus Daboo wrote:

>  Hi Randall,
>
>  --On Monday, June 9, 2003 11:24 PM -0400 Randall Gellens 
> <randy@qualcomm.com> wrote:
>
>  |>  SMTP commands can not be embedded into the DATA stream. So I do not
>  |>  think an ATTACH SMTP command will work. Although most MUAs display
>  |>  'attachments' in a separate pane, they are inline in just about any
>  |>  random order.
>  |
>  | We would be creating a new Submit extension mechanism.  Such a mechanism
>  | could be as simple as saying 'expand references external body parts that
>  | have the "expand" flag set'.  Note that during the discussions on
>  | developing a separate SMTP submit service from the SMTP relay service, it
>  | was suggested that future Submit extensions that were only useful for
>  | message submission should perhaps look quite different from SMTP
>  | extensions, to prevent them from leaking into SMTP relay.  One example
>  | would be a kind of envelope wrapping the transaction.  At the time, there
>  | was discussion of using a Submit service for various sorts of helpful
>  | things, including transcoding of voice attachments, creating a proper
>  | message, etc.
>
>  Can we have a clear statement of what exactly needs to be expanded 
> for this application? The two possibilities I see right now are:
>
>  1) Expand entire MIME parts by substituting data from an outside 
> source: external-body expansion.

This is what has been discussed to date, as far as I recall.

>
>  2) Expand inline data (e.g. quotations in a reply or forward).

I don't recall hearing of this before the most recent series of 
emails.  As far as I know this type of detailed composition server is 
not a requirement, because presumably the client would be capable of 
at least this level of composition.

>  The former is relatively easy to do - just substituting one MIME 
> part for another.
>
>  The later is much more complicated as it requires detailed 
> knowledge of the data itself. This really requires a full-blown 
> 'composition agent' that knows how to deal with character set and 
> encoding issues for all components of the data being expanded, as 
> well as data format issues (e.g. knows how to put together HTML 
> fragments in a consistent manner). That definitely goes beyond 
> anything that either SMTP or IMAP has had to do up till now.
>
>  If (2) is a requirement then I'd be more inclined to go with a 
> third server option that has not been discussed much - namely 
> having a new type of server a 'message composition server' that has 
> all the logic and capability of a typical desktop MUA in terms of 
> building rfc2822/MIME messages as well as the ability to pull in 
> data from external sources (with an appropriate security model). As 
> well as providing pointers to the source components of the message, 
> the client of this server would also be able to specify the 
> destination, which might be an IMAP server or an SMTP server or 
> some other destination in a similar manner to IMAP CHANNEL. Has 
> this third server option been ruled out for any reason?

If this type of composition service is required, then I'd tend to 
agree with you that it goes far beyond current IMAP or Submission 
capabilities and would need a new server, part of a full-blown split 
client mode.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
There once was a hacker named Ken
Who inherited truckloads of Yen
        So he built him some chicks
        Of silicon chips
And hasn't been heard from since then.
_______________________________________________
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 mailnull@www1.ietf.org  Wed Jun 11 10:45:00 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11905
	for <lemonade-archive@odin.ietf.org>; Wed, 11 Jun 2003 10:45:00 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5BEiaN04808
	for lemonade-archive@odin.ietf.org; Wed, 11 Jun 2003 10:44:36 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BEiam04805
	for <lemonade-web-archive@optimus.ietf.org>; Wed, 11 Jun 2003 10:44:36 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11862
	for <lemonade-web-archive@ietf.org>; Wed, 11 Jun 2003 10:44:30 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q6ny-0000ps-00
	for lemonade-web-archive@ietf.org; Wed, 11 Jun 2003 10:42:26 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q6ny-0000pm-00
	for lemonade-web-archive@ietf.org; Wed, 11 Jun 2003 10:42:26 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BEiIm04692;
	Wed, 11 Jun 2003 10:44:18 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BEc3m04450
	for <lemonade@optimus.ietf.org>; Wed, 11 Jun 2003 10:38:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11636
	for <lemonade@ietf.org>; Wed, 11 Jun 2003 10:37:57 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q6hd-0000nE-00
	for lemonade@ietf.org; Wed, 11 Jun 2003 10:35:53 -0400
Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q6hd-0000mj-00
	for lemonade@ietf.org; Wed, 11 Jun 2003 10:35:53 -0400
Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83])
	by ihemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h5BEbOP25805
	for <lemonade@ietf.org>; Wed, 11 Jun 2003 09:37:24 -0500 (CDT)
Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19)
	id <L2XMBYT7>; Wed, 11 Jun 2003 09:37:24 -0500
Message-ID: <54E40201497DF142B06B27255953F79705BFDF08@il0015exch007u.ih.lucent.com>
From: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
To: Erev Ari <Ari.Erev@comverse.com>
Cc: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Date: Wed, 11 Jun 2003 09:37:23 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C33026.EF1E2DAE"
Subject: [lemonade] Channel gaps?
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C33026.EF1E2DAE
Content-Type: text/plain;
	charset="iso-8859-1"

Speaking of Channel,
 
I agree that there does seem there is common technology between channel and an external submission service.
 
Unless I mis-understand the current draft (-02 I believe in my disconnected state), there is an incompleteness with respect to security.  The IMAP server is requested to deliver a content via an external transport such as IMAP, HTTP, or RTP.  The specification does not deal with the authentication of the requesting client connection (a submit server?) on that port.  It seems there are two cases, both have some problems.
 
    1) the external mechanism supports authentication using the same credentials as the primary IMAP connection
            - This requires extra overhead and latency to do the authentication, or mechanism to transport credentials
            - It may also introduce complexity when using 3rd party servers such as a transcode server in the data-path
    2) the external mechanism does not inherently support authentication... HTTP, RTP
            - The content is made available on a random port or URL for the taking, and a client with a good guessing 
                algorithm could go looking for unprotected content.  This risk is higher for protocols like RTP 
                than HTTP URLs  (fewer ports to guess than possible URLs).
 
Mark's proposed but unspecified token scheme would seem to be a necessary addition to channel for the second class of access mechanisms to ensure that the channel can be authenticated for that specific message or body part.   It may even be desirable for the set of protocols in the first set in cases where the content needs to flow through a third party for content conversion and the like, and it would be undesirable to send the users credentials through that server.
 
I note that the use of a hash or token is implied by the examples in Eric Burgers channel use case document, but they are not discussed in the standard document.
 
Do we need to write channel-specific documents as companion to the base channel spec?  In places it seems the channel use case document is trying to do just that for some channels such as MailTo.
 
Comments?
 
Greg V.
 
 
-----Original Message-----
From: Erev Ari [mailto:Ari.Erev@comverse.com]
Sent: Wednesday, June 11, 2003 3:46 AM
To: 'Chris Newman'; IETF LEMONADE (E-mail)
Subject: RE: [lemonade] Strawman for Submit based message composition



Chris, 

Isn't the GENURL/GETURL very similar to the proposed IMAP CHANNEL extension? 
http://www.ietf.org/internet-drafts/draft-nerenberg-imap-channel-03.txt <http://www.ietf.org/internet-drafts/draft-nerenberg-imap-channel-03.txt>  (now expired) 

As far as I remember with CHANNEL you could ask the IMAP server for a "URL" for a specific MIME part of a message (or to the whole message)

Ari 

> -----Original Message----- 
> From: Chris Newman [ mailto:Chris.Newman@sun.com <mailto:Chris.Newman@sun.com> ] 
> Sent: Wednesday, June 11, 2003 3:08 AM 
> To: IETF LEMONADE (E-mail) 
> Subject: [lemonade] Strawman for Submit based message composition 
> 
> 
> I'll start by defining message composition as the process of 
> assembling 
> multiple byte-counted objects from potentially different 
> locations into a 
> single byte stream.  IMAP has no such facility. 
> 
> SMTP/Submit, however, already has 90% of this facility with 
> the CHUNKING 
> extension.  In particular, it assembles a series of 
> byte-counted objects into a 
> single byte stream. 
> 
> Suppose we create a new Submit extension called "BURL" which 
> can be interleaved 
> with "BDAT" commands.  So you can now compose a message as follows: 
> 
> BDAT ....               headers and first part 
> BURL 8bit <imap-url>    forwarded 8bit content from IMAP 
> BDAT ....               MIME delimiters or whatever 
> BURL base64 <http-url>  get http content, base64 encode it 
> and include it 
> BDAT ....               final data 
> 
> This can all be pipelined into one round-trip. 
> 
> The BURL extension should advertise what types of URLs it supports: 
> 
> 250-BURL http imap://trusted-host.example.com/ 
> 
> This extension alone would solve the forward-without-download 
> extension for the 
> subset of the problem space where the submit server has 
> pre-existing trust 
> relationship with the IMAP server. 
> 
> Indeed since 99% of the world uses plain text passwords (with 
> or without TLS) 
> for authentication.  Authenticating to the submit server will 
> grant sufficient 
> rights for the user to access and forward their own mail from 
> IMAP anyway.  So 
> why not use it when appropriate? 
> 
> If we wanted to go for the additional case where there isn't a trust 
> relationship between the submit server and IMAP server, then 
> we simply add two 
> extensions to IMAP: 
> 
> 1. a "GENURL" command which turns a message or body-part 
> reference within the 
> selected mailbox into an extended IMAP URL with an 
> authorization token.  This 
> could either have a time-limit or a number of use limit.  The 
> authorization 
> token would likely be an HMAC-MD5 covering the URL, a nonce, 
> a time-limit and 
> using a per-user random secret known only to the IMAP server. 
> 
> 2. a "GETURL" command which is accessible by any IMAP user (including 
> anonymous) which returns a literal of the the relevant 
> message/body part if the 
> authorization token is valid. 
> 
> This just doesn't seem complicated to me.  Indeed it seems 
> much simpler than 
> any approach to extending IMAP with a redundant submission 
> and composition 
> facility in addition to the one already present in CHUNKING Submit. 
> 
>                 - Chris 
> 
> _______________________________________________ 
> lemonade mailing list 
> lemonade@ietf.org 
> https://www1.ietf.org/mailman/listinfo/lemonade <https://www1.ietf.org/mailman/listinfo/lemonade>  
> 


------_=_NextPart_001_01C33026.EF1E2DAE
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: [lemonade] Strawman for Submit based message composition</TITLE>

<META content="MSHTML 5.50.4919.2200" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=630252213-11062003><FONT face=Arial color=#0000ff 
size=2>Speaking of Channel,</FONT></SPAN></DIV>
<DIV><SPAN class=630252213-11062003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=630252213-11062003>
<DIV><SPAN class=630252213-11062003><FONT face=Arial color=#0000ff size=2>I 
agree that there does seem there is common technology between channel and an 
external submission service.</FONT></SPAN></DIV>
<DIV><SPAN class=630252213-11062003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV></SPAN></DIV>
<DIV><SPAN class=630252213-11062003><FONT face=Arial color=#0000ff size=2>Unless 
I mis-understand the current draft (-02 I believe in my disconnected state), 
there is an incompleteness with respect to&nbsp;security.&nbsp; The IMAP server 
is requested to deliver a content via an external transport such as IMAP, HTTP, 
or RTP.&nbsp; The specification does not deal with the authentication of the 
requesting client connection (a submit server?) on that port.&nbsp; It seems 
there are two cases, both have some problems.</FONT></SPAN></DIV>
<DIV><SPAN class=630252213-11062003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=630252213-11062003><FONT face=Arial color=#0000ff 
size=2>&nbsp;&nbsp;&nbsp; 1) the external mechanism supports authentication 
using the same credentials as the primary IMAP connection</FONT></SPAN></DIV>
<DIV><SPAN 
class=630252213-11062003>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
<FONT face=Arial color=#0000ff size=2>- This&nbsp;requires extra overhead and 
latency&nbsp;to do the authentication, or mechanism to transport 
credentials</FONT></SPAN></DIV>
<DIV><SPAN 
class=630252213-11062003>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
<FONT face=Arial color=#0000ff size=2>- It may also introduce complexity when 
using 3rd party&nbsp;servers such as a transcode server&nbsp;in the 
data-path</FONT></SPAN></DIV>
<DIV><SPAN class=630252213-11062003>&nbsp;&nbsp;&nbsp; <FONT face=Arial 
color=#0000ff size=2>2) the external mechanism does not inherently support 
authentication... HTTP, RTP</FONT></SPAN></DIV>
<DIV><SPAN class=630252213-11062003>&nbsp;&nbsp;&nbsp;<FONT face=Arial 
color=#0000ff size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - The 
content is made available on a random port&nbsp;or&nbsp;URL for the taking, and 
</FONT></SPAN><SPAN class=630252213-11062003><FONT face=Arial color=#0000ff 
size=2>a client with a good guessing </FONT></SPAN></DIV>
<DIV><SPAN class=630252213-11062003><FONT face=Arial color=#0000ff 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
algorithm could go looking for&nbsp;unprotected content.&nbsp; This risk is 
higher for protocols like RTP </FONT></SPAN></DIV>
<DIV><SPAN class=630252213-11062003><FONT face=Arial color=#0000ff 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
than HTTP URLs&nbsp; (fewer ports to guess than possible 
URLs).</FONT></SPAN></DIV>
<DIV><SPAN class=630252213-11062003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV><SPAN class=630252213-11062003><FONT face=Arial 
color=#0000ff size=2>
<DIV>Mark's proposed but unspecified token scheme would seem to be a necessary 
addition to channel for the second class of access mechanisms to ensure that 
the&nbsp;channel can be authenticated for that specific message or body 
part.&nbsp;&nbsp; It may even be desirable for the set of protocols in the first 
set in cases where the content needs to flow through a third party for content 
conversion and the like, and it would be undesirable to send the users 
credentials through that server.</FONT></SPAN></DIV>
<DIV><SPAN class=630252213-11062003><SPAN class=630252213-11062003><FONT 
face=Arial color=#0000ff size=2>&nbsp;</DIV>
<DIV>
<DIV><SPAN class=630252213-11062003><FONT face=Arial color=#0000ff size=2>I note 
that the use of a hash or token is implied by the&nbsp;examples in Eric Burgers 
channel use case document, but they are not discussed in the standard 
document.</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV></FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=630252213-11062003><FONT face=Arial color=#0000ff size=2>Do we 
need to write channel-specific documents as companion to the base channel 
spec?&nbsp; In places it seems the channel use case document is trying to do 
just that for some&nbsp;channels such as MailTo.</FONT></SPAN></DIV>
<DIV><SPAN class=630252213-11062003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=630252213-11062003><FONT face=Arial color=#0000ff 
size=2>Comments?</FONT></SPAN></DIV>
<DIV><SPAN class=630252213-11062003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=630252213-11062003><FONT face=Arial color=#0000ff size=2>Greg 
V.</FONT></SPAN></DIV>
<DIV><SPAN class=630252213-11062003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=630252213-11062003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=630252213-11062003></SPAN><FONT face=Tahoma 
size=2>-----Original Message-----<BR><B>From:</B> Erev Ari 
[mailto:Ari.Erev@comverse.com]<BR><B>Sent:</B> Wednesday, June 11, 2003 3:46 
AM<BR><B>To:</B> 'Chris Newman'; IETF LEMONADE (E-mail)<BR><B>Subject:</B> RE: 
[lemonade] Strawman for Submit based message composition<BR><BR></DIV></FONT>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <P><FONT size=2>Chris,</FONT> </P>
  <P><FONT size=2>Isn't the GENURL/GETURL very similar to the proposed IMAP 
  CHANNEL extension?</FONT> <BR><FONT size=2><A target=_blank 
  href="http://www.ietf.org/internet-drafts/draft-nerenberg-imap-channel-03.txt">http://www.ietf.org/internet-drafts/draft-nerenberg-imap-channel-03.txt</A> 
  (now expired)</FONT> </P>
  <P><FONT size=2>As far as I remember with CHANNEL you could ask the IMAP 
  server for a "URL" for a specific MIME part of a message (or to the whole 
  message)</FONT></P>
  <P><FONT size=2>Ari</FONT> </P>
  <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; 
  From: Chris Newman [<A 
  href="mailto:Chris.Newman@sun.com">mailto:Chris.Newman@sun.com</A>]</FONT> 
  <BR><FONT size=2>&gt; Sent: Wednesday, June 11, 2003 3:08 AM</FONT> <BR><FONT 
  size=2>&gt; To: IETF LEMONADE (E-mail)</FONT> <BR><FONT size=2>&gt; Subject: 
  [lemonade] Strawman for Submit based message composition</FONT> <BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; I'll 
  start by defining message composition as the process of </FONT><BR><FONT 
  size=2>&gt; assembling</FONT> <BR><FONT size=2>&gt; multiple byte-counted 
  objects from potentially different </FONT><BR><FONT size=2>&gt; locations into 
  a</FONT> <BR><FONT size=2>&gt; single byte stream.&nbsp; IMAP has no such 
  facility.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  SMTP/Submit, however, already has 90% of this facility with </FONT><BR><FONT 
  size=2>&gt; the CHUNKING</FONT> <BR><FONT size=2>&gt; extension.&nbsp; In 
  particular, it assembles a series of </FONT><BR><FONT size=2>&gt; byte-counted 
  objects into a</FONT> <BR><FONT size=2>&gt; single byte stream.</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Suppose we create a new 
  Submit extension called "BURL" which </FONT><BR><FONT size=2>&gt; can be 
  interleaved</FONT> <BR><FONT size=2>&gt; with "BDAT" commands.&nbsp; So you 
  can now compose a message as follows:</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; BDAT 
  ....&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  headers and first part</FONT> <BR><FONT size=2>&gt; BURL 8bit 
  &lt;imap-url&gt;&nbsp;&nbsp;&nbsp; forwarded 8bit content from IMAP</FONT> 
  <BR><FONT size=2>&gt; BDAT 
  ....&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  MIME delimiters or whatever</FONT> <BR><FONT size=2>&gt; BURL base64 
  &lt;http-url&gt;&nbsp; get http content, base64 encode it </FONT><BR><FONT 
  size=2>&gt; and include it</FONT> <BR><FONT size=2>&gt; BDAT 
  ....&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  final data</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; This can 
  all be pipelined into one round-trip.</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; The BURL extension should advertise what types of 
  URLs it supports:</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  250-BURL http imap://trusted-host.example.com/</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; This extension alone would solve the 
  forward-without-download </FONT><BR><FONT size=2>&gt; extension for the</FONT> 
  <BR><FONT size=2>&gt; subset of the problem space where the submit server has 
  </FONT><BR><FONT size=2>&gt; pre-existing trust</FONT> <BR><FONT size=2>&gt; 
  relationship with the IMAP server.</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; Indeed since 99% of the world uses plain text 
  passwords (with </FONT><BR><FONT size=2>&gt; or without TLS)</FONT> <BR><FONT 
  size=2>&gt; for authentication.&nbsp; Authenticating to the submit server will 
  </FONT><BR><FONT size=2>&gt; grant sufficient</FONT> <BR><FONT size=2>&gt; 
  rights for the user to access and forward their own mail from </FONT><BR><FONT 
  size=2>&gt; IMAP anyway.&nbsp; So</FONT> <BR><FONT size=2>&gt; why not use it 
  when appropriate?</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; If 
  we wanted to go for the additional case where there isn't a trust</FONT> 
  <BR><FONT size=2>&gt; relationship between the submit server and IMAP server, 
  then </FONT><BR><FONT size=2>&gt; we simply add two</FONT> <BR><FONT 
  size=2>&gt; extensions to IMAP:</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; 1. a "GENURL" command which turns a message or body-part 
  </FONT><BR><FONT size=2>&gt; reference within the</FONT> <BR><FONT size=2>&gt; 
  selected mailbox into an extended IMAP URL with an </FONT><BR><FONT 
  size=2>&gt; authorization token.&nbsp; This</FONT> <BR><FONT size=2>&gt; could 
  either have a time-limit or a number of use limit.&nbsp; The </FONT><BR><FONT 
  size=2>&gt; authorization</FONT> <BR><FONT size=2>&gt; token would likely be 
  an HMAC-MD5 covering the URL, a nonce, </FONT><BR><FONT size=2>&gt; a 
  time-limit and</FONT> <BR><FONT size=2>&gt; using a per-user random secret 
  known only to the IMAP server.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; 2. a "GETURL" command which is accessible by any IMAP user 
  (including</FONT> <BR><FONT size=2>&gt; anonymous) which returns a literal of 
  the the relevant </FONT><BR><FONT size=2>&gt; message/body part if the</FONT> 
  <BR><FONT size=2>&gt; authorization token is valid.</FONT> <BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; This just doesn't seem complicated to 
  me.&nbsp; Indeed it seems </FONT><BR><FONT size=2>&gt; much simpler 
  than</FONT> <BR><FONT size=2>&gt; any approach to extending IMAP with a 
  redundant submission </FONT><BR><FONT size=2>&gt; and composition</FONT> 
  <BR><FONT size=2>&gt; facility in addition to the one already present in 
  CHUNKING Submit.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  - Chris</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  _______________________________________________</FONT> <BR><FONT size=2>&gt; 
  lemonade mailing list</FONT> <BR><FONT size=2>&gt; lemonade@ietf.org</FONT> 
  <BR><FONT size=2>&gt; <A target=_blank 
  href="https://www1.ietf.org/mailman/listinfo/lemonade">https://www1.ietf.org/mailman/listinfo/lemonade</A></FONT> 
  <BR><FONT size=2>&gt; </FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C33026.EF1E2DAE--
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Wed Jun 11 10:45:00 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11907
	for <lemonade-archive@odin.ietf.org>; Wed, 11 Jun 2003 10:45:00 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5BEiaf04824
	for lemonade-archive@odin.ietf.org; Wed, 11 Jun 2003 10:44:36 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BEiam04821
	for <lemonade-web-archive@optimus.ietf.org>; Wed, 11 Jun 2003 10:44:36 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11865
	for <lemonade-web-archive@ietf.org>; Wed, 11 Jun 2003 10:44:30 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q6ny-0000pp-00
	for lemonade-web-archive@ietf.org; Wed, 11 Jun 2003 10:42:27 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q6ny-0000pl-00
	for lemonade-web-archive@ietf.org; Wed, 11 Jun 2003 10:42:26 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BEiDm04672;
	Wed, 11 Jun 2003 10:44:16 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BEZWm03509
	for <lemonade@optimus.ietf.org>; Wed, 11 Jun 2003 10:35:32 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11534
	for <lemonade@ietf.org>; Wed, 11 Jun 2003 10:35:25 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q6fC-0000lm-00
	for lemonade@ietf.org; Wed, 11 Jun 2003 10:33:22 -0400
Received: from panda.com
	([206.124.149.114] helo=Ikkoku-Kan.Panda.COM ident=uhhl)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q6fA-0000lj-00
	for lemonade@ietf.org; Wed, 11 Jun 2003 10:33:21 -0400
Received: from localhost (mrc@localhost) by Ikkoku-Kan.Panda.COM id HAA21495; Wed, 11 Jun 2003 07:35:17 -0700 (PDT)
Date: Wed, 11 Jun 2003 07:35:16 -0700 (PDT)
From: Mark Crispin <mrc@CAC.Washington.EDU>
To: Rick Block <rickblock@avaya.com>
cc: Lawrence Greenfield <leg+@andrew.cmu.edu>,
        "IETF LEMONADE (E-mail)" <lemonade@ietf.org>,
        Chris Newman <Chris.Newman@sun.com>
Subject: Re: [lemonade] Strawman for Submit based message composition
In-Reply-To: <3EE735D3.6020709@avaya.com>
Message-ID: <Pine.NXT.4.56.0306110732470.11845@Ikkoku-Kan.Panda.COM>
References: <2147483647.1055264863@nifty-jr.west.sun.com>
 <200306110310.h5B3Aenw001638@smtp6.andrew.cmu.edu>
 <Pine.NXT.4.56.0306102018520.11845@Ikkoku-Kan.Panda.COM> <3EE735D3.6020709@avaya.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Wed, 11 Jun 2003, Rick Block wrote:
> Non-issue meaning both the (SMTP-ish) submit and the (IMAP-ish)
> append to "sent" folder would be handled by the proxy which is
> in a position to expand any external references for each of
> these operations.

Correct.

> On the other hand, if bandwidth is so precious
> and latency so high perhaps the proxy server should be doing
> the copy to sent folder operation itself rather than the
> ultimate client, which makes the submit operation a little less
> SMTP-ish.

Agreed.  The issue is the client<->proxy server path.  Presumably the
proxy server is on the low-latency/high-bandwidth side of things and is
freer to act.

I would guess that there would be an "fcc" field in the request that the
client makes to the proxy server, along with all the other receipient
information, and the proxy server translates that to whatever commands.

-- 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 mailnull@www1.ietf.org  Wed Jun 11 10:52:37 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12093
	for <lemonade-archive@odin.ietf.org>; Wed, 11 Jun 2003 10:52:37 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5BEqDt05197
	for lemonade-archive@odin.ietf.org; Wed, 11 Jun 2003 10:52:13 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BEqDm05194
	for <lemonade-web-archive@optimus.ietf.org>; Wed, 11 Jun 2003 10:52:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12083
	for <lemonade-web-archive@ietf.org>; Wed, 11 Jun 2003 10:52:06 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q6vL-0000rb-00
	for lemonade-web-archive@ietf.org; Wed, 11 Jun 2003 10:50:03 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q6vK-0000rY-00
	for lemonade-web-archive@ietf.org; Wed, 11 Jun 2003 10:50:02 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BEq3m05172;
	Wed, 11 Jun 2003 10:52:03 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BEpEm05045
	for <lemonade@optimus.ietf.org>; Wed, 11 Jun 2003 10:51:14 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12065
	for <lemonade@ietf.org>; Wed, 11 Jun 2003 10:51:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q6uO-0000rH-00
	for lemonade@ietf.org; Wed, 11 Jun 2003 10:49:04 -0400
Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q6uO-0000rE-00
	for lemonade@ietf.org; Wed, 11 Jun 2003 10:49:04 -0400
Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83])
	by ihemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h5BEoZt12895
	for <lemonade@ietf.org>; Wed, 11 Jun 2003 09:50:36 -0500 (CDT)
Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19)
	id <L2XMB5BL>; Wed, 11 Jun 2003 09:50:35 -0500
Message-ID: <54E40201497DF142B06B27255953F79705BFDF3D@il0015exch007u.ih.lucent.com>
From: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
To: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>,
        "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Date: Wed, 11 Jun 2003 09:50:34 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [lemonade] Wireless latencies
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>


My earlier message was incorrect.  Below I suggest an average RTT of abount 100 ms, or a simple message submission time using SMTP-submit of about 1 second.  My measured experience using a CDMA data network has an average RTT of 1200 milliseconds (100 samples), or about 10 seconds to send a short message using a separate SMTP connection, or about 1-2 seconds using an existing IMAP connection.  There is good bandwidth at that RTT if the app uses it effeciently.  This longer RTT is consistent with other literature I have seen on the subject.

My appologies for spreading mis-information.

Greg V.

-----Original Message-----
From: Vaudreuil, Greg M (Greg) [mailto:gregv@lucent.com]
Sent: Tuesday, June 10, 2003 12:01 PM
To: IETF LEMONADE (E-mail)
Subject: RE: [lemonade] Re: IMAP as submit server and SPAM



Comparing the two options in light of the Lemonade requirements for efficiency over costly, high-latency links.

Using SMTP-Submit, 

1) Client requests a hash-token for a body part or message of interest from existing IMAP connection. (one round trip)

2) Client opens new TCP session to SMTP-Submit server (one round-trip)

3) Initiates SMTP protocol, determine capabilities, and authenticates to Submit server (three round trips)

4) Client sends message to submit server (about two round trips using command pipelining)

5) Client closes SMTP (1 round-trip)

Each wireless round-trip is about 100-150 ms... for a network-induced "extra" latency of about a second.  Extra latency if the client has to wait for the submit server to resolve the references before providing the 200 OK response to the DATA or BDAT for the submission.

The open of TCP and authentication also requires sending of extra data... maybe two hundred extra bytes or so vs. using an existing authenticated session. (extra $$)


Using IMAP-Submit 

1) Client posts message to outbox, client annotates message with SMTP envelope in pipeline, receives status in response (1 round trip)
	
Greg V.

_______________________________________________
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 mailnull@www1.ietf.org  Wed Jun 11 11:10:32 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12928
	for <lemonade-archive@odin.ietf.org>; Wed, 11 Jun 2003 11:10:31 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5BFA8406990
	for lemonade-archive@odin.ietf.org; Wed, 11 Jun 2003 11:10:08 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BFA8m06987
	for <lemonade-web-archive@optimus.ietf.org>; Wed, 11 Jun 2003 11:10:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12924
	for <lemonade-web-archive@ietf.org>; Wed, 11 Jun 2003 11:10:01 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q7Cg-00012G-00
	for lemonade-web-archive@ietf.org; Wed, 11 Jun 2003 11:07:58 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q7Cf-00012D-00
	for lemonade-web-archive@ietf.org; Wed, 11 Jun 2003 11:07:57 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BF9Wm06934;
	Wed, 11 Jun 2003 11:09:37 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BF8vm06897
	for <lemonade@optimus.ietf.org>; Wed, 11 Jun 2003 11:08:57 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12908
	for <lemonade@ietf.org>; Wed, 11 Jun 2003 11:08:51 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q7BX-00011q-00
	for lemonade@ietf.org; Wed, 11 Jun 2003 11:06:47 -0400
Received: from comversegw.icomverse.com ([192.118.48.248] helo=il-tlv-smtpout1.icomverse.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q7BW-00011n-00
	for lemonade@ietf.org; Wed, 11 Jun 2003 11:06:46 -0400
Received: from il-tlv-mbdg2.comverse.com (localhost.localdomain [127.0.0.1])
	by il-tlv-smtpout1.icomverse.com (8.11.6/8.11.6) with ESMTP id h5BF8Pf02196;
	Wed, 11 Jun 2003 18:08:25 +0300
Received: by il-tlv-mbdg2.comverse.com with Internet Mail Service (5.5.2655.55)
	id <M2S6S2R2>; Wed, 11 Jun 2003 18:08:36 +0300
Message-ID: <7D4344E32B34D511A6500002A560C60204D89304@il-tlv-mail4.comverse.com>
From: Erev Ari <Ari.Erev@comverse.com>
To: "'Vaudreuil, Greg M (Greg)'" <gregv@lucent.com>,
        "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: RE: [lemonade] Call for requirement consensus
Date: Wed, 11 Jun 2003 18:08:34 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3302A.C7F76106"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3302A.C7F76106
Content-Type: text/plain;
	charset="iso-8859-1"

I agree.

I think that the message part granularity is "good enough".

Maybe after getting some experience and better understand this level of
functionality, it could be extended (optionally?) to a full-blown
"composition server". Looks to me a bit premature at this time...

Ari 


> -----Original Message-----
> From: Vaudreuil, Greg M (Greg) [mailto:gregv@lucent.com]
> Sent: Wednesday, June 11, 2003 5:38 PM
> To: IETF LEMONADE (E-mail)
> Subject: [lemonade] Call for requirement consensus
> 
> 
> 
> Do we all agree that lemonade requirements should specify a 
> basic forward of message or atomic message part without 
> download and not a remote composition service?
> 
> I am interested in hearing objections and reasons or examples 
> of where a remote composition service would be of material 
> benefit in scope of the lemonade charter goals.
> 
> Greg V.
> 
> -----Original Message-----
> From: Randall Gellens [mailto:randy@qualcomm.com]
> Sent: Tuesday, June 10, 2003 1:55 PM
> To: Cyrus Daboo; Randall Gellens; IETF LEMONADE (E-mail)
> Cc: Doug Royer
> Subject: Re: [lemonade] Re: Just 'ATTACH'
> 
> 
> Hi Cyrus,
> 
> At 12:36 PM -0400 6/10/03, Cyrus Daboo wrote:
> 
> >  Hi Randall,
> >
> >  --On Monday, June 9, 2003 11:24 PM -0400 Randall Gellens 
> > <randy@qualcomm.com> wrote:
> >
> >  |>  SMTP commands can not be embedded into the DATA 
> stream. So I do not
> >  |>  think an ATTACH SMTP command will work. Although most 
> MUAs display
> >  |>  'attachments' in a separate pane, they are inline in 
> just about any
> >  |>  random order.
> >  |
> >  | We would be creating a new Submit extension mechanism.  
> Such a mechanism
> >  | could be as simple as saying 'expand references external 
> body parts that
> >  | have the "expand" flag set'.  Note that during the discussions on
> >  | developing a separate SMTP submit service from the SMTP 
> relay service, it
> >  | was suggested that future Submit extensions that were 
> only useful for
> >  | message submission should perhaps look quite different from SMTP
> >  | extensions, to prevent them from leaking into SMTP 
> relay.  One example
> >  | would be a kind of envelope wrapping the transaction.  
> At the time, there
> >  | was discussion of using a Submit service for various 
> sorts of helpful
> >  | things, including transcoding of voice attachments, 
> creating a proper
> >  | message, etc.
> >
> >  Can we have a clear statement of what exactly needs to be expanded 
> > for this application? The two possibilities I see right now are:
> >
> >  1) Expand entire MIME parts by substituting data from an outside 
> > source: external-body expansion.
> 
> This is what has been discussed to date, as far as I recall.
> 
> >
> >  2) Expand inline data (e.g. quotations in a reply or forward).
> 
> I don't recall hearing of this before the most recent series of 
> emails.  As far as I know this type of detailed composition server is 
> not a requirement, because presumably the client would be capable of 
> at least this level of composition.
> 
> >  The former is relatively easy to do - just substituting one MIME 
> > part for another.
> >
> >  The later is much more complicated as it requires detailed 
> > knowledge of the data itself. This really requires a full-blown 
> > 'composition agent' that knows how to deal with character set and 
> > encoding issues for all components of the data being expanded, as 
> > well as data format issues (e.g. knows how to put together HTML 
> > fragments in a consistent manner). That definitely goes beyond 
> > anything that either SMTP or IMAP has had to do up till now.
> >
> >  If (2) is a requirement then I'd be more inclined to go with a 
> > third server option that has not been discussed much - namely 
> > having a new type of server a 'message composition server' that has 
> > all the logic and capability of a typical desktop MUA in terms of 
> > building rfc2822/MIME messages as well as the ability to pull in 
> > data from external sources (with an appropriate security model). As 
> > well as providing pointers to the source components of the message, 
> > the client of this server would also be able to specify the 
> > destination, which might be an IMAP server or an SMTP server or 
> > some other destination in a similar manner to IMAP CHANNEL. Has 
> > this third server option been ruled out for any reason?
> 
> If this type of composition service is required, then I'd tend to 
> agree with you that it goes far beyond current IMAP or Submission 
> capabilities and would need a new server, part of a full-blown split 
> client mode.
> 
> -- 
> Randall Gellens
> Opinions are personal;    facts are suspect;    I speak for 
> myself only
> -------------- Randomly-selected tag: ---------------
> There once was a hacker named Ken
> Who inherited truckloads of Yen
>         So he built him some chicks
>         Of silicon chips
> And hasn't been heard from since then.
> _______________________________________________
> 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
> 

------_=_NextPart_001_01C3302A.C7F76106
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: [lemonade] Call for requirement consensus</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I agree.</FONT>
</P>

<P><FONT SIZE=3D2>I think that the message part granularity is =
&quot;good enough&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>Maybe after getting some experience and better =
understand this level of functionality, it could be extended =
(optionally?) to a full-blown &quot;composition server&quot;. Looks to =
me a bit premature at this time...</FONT></P>

<P><FONT SIZE=3D2>Ari </FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Vaudreuil, Greg M (Greg) [<A =
HREF=3D"mailto:gregv@lucent.com">mailto:gregv@lucent.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, June 11, 2003 5:38 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: IETF LEMONADE (E-mail)</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: [lemonade] Call for requirement =
consensus</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Do we all agree that lemonade requirements =
should specify a </FONT>
<BR><FONT SIZE=3D2>&gt; basic forward of message or atomic message part =
without </FONT>
<BR><FONT SIZE=3D2>&gt; download and not a remote composition =
service?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I am interested in hearing objections and =
reasons or examples </FONT>
<BR><FONT SIZE=3D2>&gt; of where a remote composition service would be =
of material </FONT>
<BR><FONT SIZE=3D2>&gt; benefit in scope of the lemonade charter =
goals.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Greg V.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Randall Gellens [<A =
HREF=3D"mailto:randy@qualcomm.com">mailto:randy@qualcomm.com</A>]</FONT>=

<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, June 10, 2003 1:55 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Cyrus Daboo; Randall Gellens; IETF LEMONADE =
(E-mail)</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: Doug Royer</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [lemonade] Re: Just =
'ATTACH'</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hi Cyrus,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; At 12:36 PM -0400 6/10/03, Cyrus Daboo =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; Hi Randall,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; --On Monday, June 9, 2003 11:24 PM =
-0400 Randall Gellens </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &lt;randy@qualcomm.com&gt; wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; |&gt;&nbsp; SMTP commands can not be =
embedded into the DATA </FONT>
<BR><FONT SIZE=3D2>&gt; stream. So I do not</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; |&gt;&nbsp; think an ATTACH SMTP =
command will work. Although most </FONT>
<BR><FONT SIZE=3D2>&gt; MUAs display</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; |&gt;&nbsp; 'attachments' in a =
separate pane, they are inline in </FONT>
<BR><FONT SIZE=3D2>&gt; just about any</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; |&gt;&nbsp; random order.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; | We would be creating a new Submit =
extension mechanism.&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; Such a mechanism</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; | could be as simple as saying =
'expand references external </FONT>
<BR><FONT SIZE=3D2>&gt; body parts that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; | have the &quot;expand&quot; flag =
set'.&nbsp; Note that during the discussions on</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; | developing a separate SMTP submit =
service from the SMTP </FONT>
<BR><FONT SIZE=3D2>&gt; relay service, it</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; | was suggested that future Submit =
extensions that were </FONT>
<BR><FONT SIZE=3D2>&gt; only useful for</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; | message submission should perhaps =
look quite different from SMTP</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; | extensions, to prevent them from =
leaking into SMTP </FONT>
<BR><FONT SIZE=3D2>&gt; relay.&nbsp; One example</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; | would be a kind of envelope =
wrapping the transaction.&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; At the time, there</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; | was discussion of using a Submit =
service for various </FONT>
<BR><FONT SIZE=3D2>&gt; sorts of helpful</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; | things, including transcoding of =
voice attachments, </FONT>
<BR><FONT SIZE=3D2>&gt; creating a proper</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; | message, etc.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; Can we have a clear statement of =
what exactly needs to be expanded </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; for this application? The two =
possibilities I see right now are:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; 1) Expand entire MIME parts by =
substituting data from an outside </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; source: external-body expansion.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; This is what has been discussed to date, as far =
as I recall.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; 2) Expand inline data (e.g. =
quotations in a reply or forward).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I don't recall hearing of this before the most =
recent series of </FONT>
<BR><FONT SIZE=3D2>&gt; emails.&nbsp; As far as I know this type of =
detailed composition server is </FONT>
<BR><FONT SIZE=3D2>&gt; not a requirement, because presumably the =
client would be capable of </FONT>
<BR><FONT SIZE=3D2>&gt; at least this level of composition.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; The former is relatively easy to do =
- just substituting one MIME </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; part for another.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; The later is much more complicated =
as it requires detailed </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; knowledge of the data itself. This really =
requires a full-blown </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 'composition agent' that knows how to deal =
with character set and </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; encoding issues for all components of the =
data being expanded, as </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; well as data format issues (e.g. knows how =
to put together HTML </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; fragments in a consistent manner). That =
definitely goes beyond </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; anything that either SMTP or IMAP has had =
to do up till now.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; If (2) is a requirement then I'd be =
more inclined to go with a </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; third server option that has not been =
discussed much - namely </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; having a new type of server a 'message =
composition server' that has </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; all the logic and capability of a typical =
desktop MUA in terms of </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; building rfc2822/MIME messages as well as =
the ability to pull in </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; data from external sources (with an =
appropriate security model). As </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; well as providing pointers to the source =
components of the message, </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the client of this server would also be =
able to specify the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; destination, which might be an IMAP server =
or an SMTP server or </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; some other destination in a similar manner =
to IMAP CHANNEL. Has </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; this third server option been ruled out =
for any reason?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If this type of composition service is =
required, then I'd tend to </FONT>
<BR><FONT SIZE=3D2>&gt; agree with you that it goes far beyond current =
IMAP or Submission </FONT>
<BR><FONT SIZE=3D2>&gt; capabilities and would need a new server, part =
of a full-blown split </FONT>
<BR><FONT SIZE=3D2>&gt; client mode.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -- </FONT>
<BR><FONT SIZE=3D2>&gt; Randall Gellens</FONT>
<BR><FONT SIZE=3D2>&gt; Opinions are personal;&nbsp;&nbsp;&nbsp; facts =
are suspect;&nbsp;&nbsp;&nbsp; I speak for </FONT>
<BR><FONT SIZE=3D2>&gt; myself only</FONT>
<BR><FONT SIZE=3D2>&gt; -------------- Randomly-selected tag: =
---------------</FONT>
<BR><FONT SIZE=3D2>&gt; There once was a hacker named Ken</FONT>
<BR><FONT SIZE=3D2>&gt; Who inherited truckloads of Yen</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
So he built him some chicks</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Of silicon chips</FONT>
<BR><FONT SIZE=3D2>&gt; And hasn't been heard from since then.</FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; lemonade mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; lemonade@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/lemonade" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/lemonade</A></F=
ONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; lemonade mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; lemonade@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/lemonade" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/lemonade</A></F=
ONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C3302A.C7F76106--
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Wed Jun 11 11:44:49 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14360
	for <lemonade-archive@odin.ietf.org>; Wed, 11 Jun 2003 11:44:49 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5BFiKm09341
	for lemonade-archive@odin.ietf.org; Wed, 11 Jun 2003 11:44:20 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BFiKm09338
	for <lemonade-web-archive@optimus.ietf.org>; Wed, 11 Jun 2003 11:44:20 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14264
	for <lemonade-web-archive@ietf.org>; Wed, 11 Jun 2003 11:44:17 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q7jq-0001Ei-00
	for lemonade-web-archive@ietf.org; Wed, 11 Jun 2003 11:42:14 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q7jq-0001Ef-00
	for lemonade-web-archive@ietf.org; Wed, 11 Jun 2003 11:42:14 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BFi4m09284;
	Wed, 11 Jun 2003 11:44:04 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BFhxm09241
	for <lemonade@optimus.ietf.org>; Wed, 11 Jun 2003 11:43:59 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14198
	for <lemonade@ietf.org>; Wed, 11 Jun 2003 11:43:56 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q7jV-0001E6-00
	for lemonade@ietf.org; Wed, 11 Jun 2003 11:41:53 -0400
Received: from oe-im2pub.managedmail.com ([206.46.164.53] helo=oe-im2.bizmailsrvcs.net)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q7jU-0001Du-00
	for lemonade@ietf.org; Wed, 11 Jun 2003 11:41:52 -0400
Received: from oe-ismta2.bizmailsrvcs.net ([206.46.164.29])
          by oe-im2.bizmailsrvcs.net
          (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP
          id <20030611154324.ORMO7174.oe-im2.bizmailsrvcs.net@oe-ismta2.bizmailsrvcs.net>;
          Wed, 11 Jun 2003 10:43:24 -0500
Received: from RoselinskyM ([206.35.147.89]) by oe-ismta2.bizmailsrvcs.net
          (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with SMTP
          id <20030611154323.KSUL8315.oe-ismta2.bizmailsrvcs.net@RoselinskyM>;
          Wed, 11 Jun 2003 10:43:23 -0500
From: "Milt Roselinsky" <milt.roselinsky@openwave.com>
To: "Vaudreuil, Greg M \(Greg\)" <gregv@lucent.com>,
        "IETF LEMONADE \(E-mail\)" <lemonade@ietf.org>
Subject: RE: [lemonade] Call for requirement consensus
Date: Wed, 11 Jun 2003 08:43:20 -0700
Message-ID: <LKEFIMGGONBOPJOEOFLOMEHAFJAA.milt.roselinsky@openwave.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <54E40201497DF142B06B27255953F79705BFDF0B@il0015exch007u.ih.lucent.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Content-Transfer-Encoding: 7bit
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Greg,

My recollection from our discussions during the lemonade meeting in SF
was that basic forwarding of messages and message parts is the requirement.

In any case, that's my vote for the requirement.  Remote composition
isn't needed.

Milt

> -----Original Message-----
> From: lemonade-admin@ietf.org [mailto:lemonade-admin@ietf.org]On Behalf
> Of Vaudreuil, Greg M (Greg)
> Sent: Wednesday, June 11, 2003 7:38 AM
> To: IETF LEMONADE (E-mail)
> Subject: [lemonade] Call for requirement consensus
> 
> 
> 
> Do we all agree that lemonade requirements should specify a basic 
> forward of message or atomic message part without download and 
> not a remote composition service?
> 
> I am interested in hearing objections and reasons or examples of 
> where a remote composition service would be of material benefit 
> in scope of the lemonade charter goals.
> 
> Greg V.
> 
> 
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Wed Jun 11 12:37:42 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16563
	for <lemonade-archive@odin.ietf.org>; Wed, 11 Jun 2003 12:37:42 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5BGbGS14743
	for lemonade-archive@odin.ietf.org; Wed, 11 Jun 2003 12:37:16 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BGbFm14740
	for <lemonade-web-archive@optimus.ietf.org>; Wed, 11 Jun 2003 12:37:15 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16555
	for <lemonade-web-archive@ietf.org>; Wed, 11 Jun 2003 12:37:12 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q8Z3-0001ff-00
	for lemonade-web-archive@ietf.org; Wed, 11 Jun 2003 12:35:09 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q8Z2-0001fc-00
	for lemonade-web-archive@ietf.org; Wed, 11 Jun 2003 12:35:08 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BGb7m14457;
	Wed, 11 Jun 2003 12:37:07 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BGaBm14215
	for <lemonade@optimus.ietf.org>; Wed, 11 Jun 2003 12:36:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16521
	for <lemonade@ietf.org>; Wed, 11 Jun 2003 12:36:07 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q8Y0-0001ez-00
	for lemonade@ietf.org; Wed, 11 Jun 2003 12:34:04 -0400
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q8Xz-0001ej-00
	for lemonade@ietf.org; Wed, 11 Jun 2003 12:34:03 -0400
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5BGZZn20991
	for <lemonade@ietf.org>; Wed, 11 Jun 2003 12:35:36 -0400 (EDT)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <KRLGC9ZD>; Wed, 11 Jun 2003 12:35:35 -0400
Message-ID: <D38D073716F2D411BEE400508BCF6296052AE45C@zcard04k.ca.nortel.com>
From: "Glenn Parsons" <gparsons@nortelnetworks.com>
To: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: RE: [lemonade] Internet Draft Important Dates and Working Session
Date: Wed, 11 Jun 2003 12:35:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C33036.1CA160F2"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C33036.1CA160F2
Content-Type: text/plain;
	charset="iso-8859-1"

Folks,

FYI the tentative schedule has us on Thursday afternoon.

THURSDAY, July 17, 2003
1530-1730 Afternoon Sessions II
APP     lemonade License to Enhance Messaging Oriented Network Access for 
                 Diverse Endpoints WG

Note that this is subject to change.

And since we are all coming for the entire week, I hope this will give us
the opportunity to have several offline discussions before our working
session on Thursday.

Cheers,
Glenn.

> ----------
> From: 	Eric Burger
> Sent: 	Tuesday, June 10, 2003 3:33 PM
> To: 	IETF LEMONADE (E-mail)
> Subject: 	[lemonade] Internet Draft Important Dates and Working
> Session
> 
> Please be aware of looming Internet Draft dates:
> 
> June 23, Monday - Internet Draft Cut-off for initial document (-00)
> submission at 09:00 ET
> June 30, Monday - Internet Draft final submission cut-off at 09:00 ET
> 
> * All times are in US Eastern Time 
> 
> 
> You MUST have drafts in by that date for consideration in our working
> session.
> 
> I have requested a 2-hour working session in Vienna.  In the *unlikely*
> event you wish to make a presentation (it is, after all, a working
> session), please send it to me NO LATER than Tuesday, July 8.
> 
> _______________________________________________
> lemonade mailing list
> lemonade@ietf.org
> https://www1.ietf.org/mailman/listinfo/lemonade
> 
> 

------_=_NextPart_001_01C33036.1CA160F2
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>RE: [lemonade] Internet Draft Important Dates and Working =
Session</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Folks,</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">FYI the tentative =
schedule has us on Thursday afternoon.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Monaco">THURSDAY, July 17, 2003</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Monaco">1530-1730 Afternoon Sessions =
II</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Monaco">APP&nbsp;&nbsp;&nbsp;&nbsp; lemonade =
License to Enhance Messaging Oriented Network Access for </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Monaco">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Diverse Endpoints WG</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Note that this is =
subject to change.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">And since we are all =
coming for the entire week, I hope this will give us the opportunity to =
have several offline discussions before our working session on =
Thursday.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Cheers,</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Glenn.</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"Arial">From:</FONT></B> &nbsp; <FONT =
SIZE=3D2 FACE=3D"Arial">Eric Burger</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"Arial">Sent:</FONT></B> &nbsp; <FONT =
SIZE=3D2 FACE=3D"Arial">Tuesday, June 10, 2003 3:33 PM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"Arial">To:</FONT></B> &nbsp;&nbsp;&nbsp; =
<FONT SIZE=3D2 FACE=3D"Arial">IETF LEMONADE (E-mail)</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"Arial">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">[lemonade] Internet Draft Important Dates and Working =
Session</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Monaco">Please be aware of looming Internet =
Draft dates:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Monaco">June 23, Monday - Internet Draft =
Cut-off for initial document (-00) submission at 09:00 ET</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Monaco">June 30, Monday - Internet Draft =
final submission cut-off at 09:00 ET</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Monaco">* All times are in US Eastern Time =
</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Monaco">You MUST have drafts in by that date =
for consideration in our working session.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Monaco">I have requested a 2-hour working =
session in Vienna.&nbsp; In the *unlikely* event you wish to make a =
presentation (it is, after all, a working session), please send it to =
me NO LATER than Tuesday, July 8.</FONT></P>

<P><FONT SIZE=3D2 =
FACE=3D"Monaco">_______________________________________________</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Monaco">lemonade mailing list</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Monaco">lemonade@ietf.org</FONT>
<BR><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Monaco"><A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/lemonade" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/lemonade</A></F=
ONT></U>
</P>
<BR>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C33036.1CA160F2--
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Wed Jun 11 12:58:36 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17220
	for <lemonade-archive@odin.ietf.org>; Wed, 11 Jun 2003 12:58:36 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5BGwA816185
	for lemonade-archive@odin.ietf.org; Wed, 11 Jun 2003 12:58:10 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BGw9m16182
	for <lemonade-web-archive@optimus.ietf.org>; Wed, 11 Jun 2003 12:58:10 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17210
	for <lemonade-web-archive@ietf.org>; Wed, 11 Jun 2003 12:58:06 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q8tH-0001oI-00
	for lemonade-web-archive@ietf.org; Wed, 11 Jun 2003 12:56:03 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q8tG-0001oF-00
	for lemonade-web-archive@ietf.org; Wed, 11 Jun 2003 12:56:02 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BGw5m16169;
	Wed, 11 Jun 2003 12:58:05 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BGvum16132
	for <lemonade@optimus.ietf.org>; Wed, 11 Jun 2003 12:57:56 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17203
	for <lemonade@ietf.org>; Wed, 11 Jun 2003 12:57:52 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q8t3-0001o4-00
	for lemonade@ietf.org; Wed, 11 Jun 2003 12:55:49 -0400
Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q8t2-0001nt-00
	for lemonade@ietf.org; Wed, 11 Jun 2003 12:55:48 -0400
Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83])
	by ihemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h5BGvKt20451
	for <lemonade@ietf.org>; Wed, 11 Jun 2003 11:57:20 -0500 (CDT)
Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19)
	id <L2XMC23T>; Wed, 11 Jun 2003 11:57:19 -0500
Message-ID: <54E40201497DF142B06B27255953F79705BFE0FA@il0015exch007u.ih.lucent.com>
From: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
To: Rick Block <rickblock@avaya.com>
Cc: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: RE: [lemonade] Re: Just 'ATTACH'
Date: Wed, 11 Jun 2003 11:57:19 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>


Rick,

You mis-understand me.  I am simply refering to the common practice of including a URL or external-body reference in an email message.  Most UA's can in fact launch the appropriate processing based on the URL or external-body machinery.  Today no MTA servers in the path try to resolve that URL on behalf of the client.  I don't think we need to change that behavior.

We need only to create a mechanism to resolve links on behalf of the sender where the sender desires to attach rather than refer to the content. This might include cases where the recipient does not have authorization to retreive it directly. 

Greg V.

-----Original Message-----
From: Rick Block [mailto:rickblock@avaya.com]
Sent: Tuesday, June 10, 2003 8:23 PM
To: Vaudreuil, Greg M (Greg)
Cc: Cyrus Daboo; Randall Gellens; IETF LEMONADE (E-mail); Doug Royer
Subject: Re: [lemonade] Re: Just 'ATTACH'



Vaudreuil, Greg M (Greg) wrote:
> I don't see the requirement for submit server resolution
 > of external documents and the like...  Maybe others have
 > a need for that, but I see the resolution of an external
 > URL as the obligation of the recipient UA.

Obligation of the recipient UA?  I have a message from
anyone@anywhere.com, I reply from my wireless device (with
original attached) and my friend anyone's UA is responsible
for putting the message together again (using pieces
of the original message sent to me obtained from my imap4
server)?  I must be misunderstanding this since it would
seem to require upgrading every UA everywhere in the world
and even if this could happen then requires my imap4 server
be accessible from anywhere.

Rick Block
Avaya Inc.

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



From mailnull@www1.ietf.org  Wed Jun 11 12:58:44 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17235
	for <lemonade-archive@odin.ietf.org>; Wed, 11 Jun 2003 12:58:44 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5BGwIN16201
	for lemonade-archive@odin.ietf.org; Wed, 11 Jun 2003 12:58:18 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BGwIm16198
	for <lemonade-web-archive@optimus.ietf.org>; Wed, 11 Jun 2003 12:58:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17214
	for <lemonade-web-archive@ietf.org>; Wed, 11 Jun 2003 12:58:14 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q8tP-0001oP-00
	for lemonade-web-archive@ietf.org; Wed, 11 Jun 2003 12:56:11 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q8tP-0001oM-00
	for lemonade-web-archive@ietf.org; Wed, 11 Jun 2003 12:56:11 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BGw3m16153;
	Wed, 11 Jun 2003 12:58:03 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BGvqm16127
	for <lemonade@optimus.ietf.org>; Wed, 11 Jun 2003 12:57:52 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17200
	for <lemonade@ietf.org>; Wed, 11 Jun 2003 12:57:48 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q8t0-0001nz-00
	for lemonade@ietf.org; Wed, 11 Jun 2003 12:55:46 -0400
Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q8sz-0001nr-00
	for lemonade@ietf.org; Wed, 11 Jun 2003 12:55:45 -0400
Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83])
	by ihemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h5BGvGt20424
	for <lemonade@ietf.org>; Wed, 11 Jun 2003 11:57:16 -0500 (CDT)
Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19)
	id <L2XMC23M>; Wed, 11 Jun 2003 11:57:15 -0500
Message-ID: <54E40201497DF142B06B27255953F79705BFE0F9@il0015exch007u.ih.lucent.com>
From: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
To: Rick Block <rickblock@avaya.com>
Cc: lemonade@ietf.org
Subject: RE: [lemonade] Re: IMAP as a submit server
Date: Wed, 11 Jun 2003 11:57:15 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

Rick, 

I believe there will be two modalities going forward, with separate protocols and constituencies.  I don't expect much "mix and match".

1) POP (or IMAP) plus SMTP-Submit, for basic email client support.  Bandwidth is cheap, clients are smart, server capacity is limited relative to cheap PCs, and complexity is simply not worth it.

2) IMAP plus IMAP-Submit (maybe via SMTP/IMAP splitting proxy) for mobile optimized or media aware (UM) clients.  Clients resources are limited (connectivity, storage, CPU power, battery power), network resident servers are relatively cheap, and complexity that saves $$ or enables new services is worth paying for. 

POP and SMTP-Submit will continue to be evolve but are essentially "mature" services.  The mobile "lemonade" clients require substantial new functionality to simply function economically in a new market segment.  These protocols need to compete against existing "MMS" solutions that are optimized for the mobile network.

Building a completely new protocol to replace IMAP and SMTP for mobile clients is out-of-scope.  While academically interesting, the WG and IESG has rejected that route. 

Greg V.

-----Original Message-----
From: Rick Block [mailto:rickblock@avaya.com]
Sent: Tuesday, June 10, 2003 1:26 PM
To: Pete Resnick
Cc: Mark Crispin; Vaudreuil, Greg M (Greg); lemonade@ietf.org
Subject: Re: [lemonade] Re: IMAP as a submit server


Does the "IMAP as submit protocol" proposal imply that clients
using it will use two different submit protocols, IMAP for
messages containing bits of others and SMTP for messages
originated in toto by the client?

It seems to me either the answer to this question is:

yes, in which case I would think the client developers would
not be very happy (two different protocols for submitting
messages, based on the context of the composition?)

or

no, in which case it would seem the IMAP "submit" capabilities
must be a superset of SMTP (for example, it would seem
IMAP submit would have to support the client side of quota
if not lemonade's quota by media)

In addition, what shall an IMAP server do if an SMTP submit
it's been requested to do (via some new IMAP operation) fails,
or will the IMAP server be required to do the resultant SMTP
submit synchronously so any SMTP error can be conveyed back
to the original client with an IMAP response?

I understand the appeal of an IMAP submit mechanism, but it
seems this effectively requires completely merging IMAP and SMTP.
Perhaps we should be talking about an entirely new protocol that
really is a combination of IMAP and SMTP and could be implemented
by a server that effectively proxies independent (regular) IMAP
and SMTP sessions.

Rick Block
Avaya Inc.
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Wed Jun 11 13:13:42 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17751
	for <lemonade-archive@odin.ietf.org>; Wed, 11 Jun 2003 13:13:42 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5BHDFK17736
	for lemonade-archive@odin.ietf.org; Wed, 11 Jun 2003 13:13:15 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BHDFm17733
	for <lemonade-web-archive@optimus.ietf.org>; Wed, 11 Jun 2003 13:13:15 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17691
	for <lemonade-web-archive@ietf.org>; Wed, 11 Jun 2003 13:13:11 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q97s-0001tQ-00
	for lemonade-web-archive@ietf.org; Wed, 11 Jun 2003 13:11:08 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q97s-0001tN-00
	for lemonade-web-archive@ietf.org; Wed, 11 Jun 2003 13:11:08 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BHD3m17684;
	Wed, 11 Jun 2003 13:13:03 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BHB8m17596
	for <lemonade@optimus.ietf.org>; Wed, 11 Jun 2003 13:11:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17568
	for <lemonade@ietf.org>; Wed, 11 Jun 2003 13:11:04 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q95p-0001rp-00
	for lemonade@ietf.org; Wed, 11 Jun 2003 13:09:01 -0400
Received: from panda.com
	([206.124.149.114] helo=Ikkoku-Kan.Panda.COM ident=metka)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q95o-0001rj-00
	for lemonade@ietf.org; Wed, 11 Jun 2003 13:09:00 -0400
Received: from localhost (mrc@localhost) by Ikkoku-Kan.Panda.COM id KAA21801; Wed, 11 Jun 2003 10:10:51 -0700 (PDT)
Date: Wed, 11 Jun 2003 10:10:51 -0700 (PDT)
From: Mark Crispin <mrc@CAC.Washington.EDU>
To: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
cc: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: Re: [lemonade] Call for requirement consensus
In-Reply-To: <54E40201497DF142B06B27255953F79705BFDF0B@il0015exch007u.ih.lucent.com>
Message-ID: <Pine.NXT.4.56.0306111008100.11845@Ikkoku-Kan.Panda.COM>
References: <54E40201497DF142B06B27255953F79705BFDF0B@il0015exch007u.ih.lucent.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Wed, 11 Jun 2003, Vaudreuil, Greg M (Greg) wrote:
> Do we all agree that lemonade requirements should specify a basic
> forward of message or atomic message part without download and not a
> remote composition service?

I would delete the phrase "and not a remote composition service".

I agree that a remote composition service is not necessary for the
requirements list.  However, it *is* one of the possible solutions and
thus should not be precluded by the requirements.

In other words, it is a requirement that there be a basic forward of
message or atomic message part without download.  Precise mechanism to be
determined.

-- 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 mailnull@www1.ietf.org  Wed Jun 11 13:22:32 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17997
	for <lemonade-archive@odin.ietf.org>; Wed, 11 Jun 2003 13:22:32 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5BHM6o18215
	for lemonade-archive@odin.ietf.org; Wed, 11 Jun 2003 13:22:06 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BHM6m18212
	for <lemonade-web-archive@optimus.ietf.org>; Wed, 11 Jun 2003 13:22:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17989
	for <lemonade-web-archive@ietf.org>; Wed, 11 Jun 2003 13:22:02 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q9GR-0001wl-00
	for lemonade-web-archive@ietf.org; Wed, 11 Jun 2003 13:19:59 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q9GQ-0001wi-00
	for lemonade-web-archive@ietf.org; Wed, 11 Jun 2003 13:19:58 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BHM2m18180;
	Wed, 11 Jun 2003 13:22:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BHKDm18025
	for <lemonade@optimus.ietf.org>; Wed, 11 Jun 2003 13:20:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17922
	for <lemonade@ietf.org>; Wed, 11 Jun 2003 13:20:09 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q9Ec-0001vA-00
	for lemonade@ietf.org; Wed, 11 Jun 2003 13:18:06 -0400
Received: from darius.cyrusoft.com ([63.163.82.2])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q9Ec-0001v7-00
	for lemonade@ietf.org; Wed, 11 Jun 2003 13:18:06 -0400
Received: from PLATO.cyrusoft.com (localhost [127.0.0.1])
	by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id NAA13506;
	Wed, 11 Jun 2003 13:16:14 -0400 (EDT)
Date: Wed, 11 Jun 2003 13:21:33 -0400
From: Cyrus Daboo <daboo@cyrusoft.com>
To: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>,
        "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: Re: [lemonade] Wireless latencies
Message-ID: <6812726.1055337693@PLATO.cyrusoft.com>
In-Reply-To: <54E40201497DF142B06B27255953F79705BFDF3D@il0015exch007u.ih.lucent.com>
References:  <54E40201497DF142B06B27255953F79705BFDF3D@il0015exch007u.ih.luce
 nt.com>
X-Mailer: Mulberry/3.1.0b1 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi Vaudreuil,,

--On Wednesday, June 11, 2003 9:50 AM -0500 "Vaudreuil, Greg M (Greg)" 
<gregv@lucent.com> wrote:

| My earlier message was incorrect.  Below I suggest an average RTT of
| abount 100 ms, or a simple message submission time using SMTP-submit of
| about 1 second.  My measured experience using a CDMA data network has an
| average RTT of 1200 milliseconds (100 samples), or about 10 seconds to
| send a short message using a separate SMTP connection, or about 1-2
| seconds using an existing IMAP connection.  There is good bandwidth at
| that RTT if the app uses it effeciently.  This longer RTT is consistent
| with other literature I have seen on the subject.

And what if your SMTP submit server and smtp client were designed to keep 
the SMTP connection open for long periods of time, as is done for IMAP? 
That would eliminate the startup costs of SMTP (auth + tls), but not the 
RTT's for MAIL FROM/RCPT TO etc (though pipelining could reduce that). i.e. 
Isn't it possible with minor changes to get SMTP performance to be much 
better than it is now, even without considering the issues of expanding 
content? That would benefit not only wireless devices but potentially all 
SMTP clients. It would also level the playing field (wrt latency) when it 
comes to deciding where the expanding content submit should be (IMAP vs 
SMTP).


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



From mailnull@www1.ietf.org  Wed Jun 11 13:26:42 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18177
	for <lemonade-archive@odin.ietf.org>; Wed, 11 Jun 2003 13:26:42 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5BHQG718411
	for lemonade-archive@odin.ietf.org; Wed, 11 Jun 2003 13:26:16 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BHQGm18408
	for <lemonade-web-archive@optimus.ietf.org>; Wed, 11 Jun 2003 13:26:16 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18138
	for <lemonade-web-archive@ietf.org>; Wed, 11 Jun 2003 13:26:12 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q9KT-0001yw-00
	for lemonade-web-archive@ietf.org; Wed, 11 Jun 2003 13:24:09 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q9KT-0001yt-00
	for lemonade-web-archive@ietf.org; Wed, 11 Jun 2003 13:24:09 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BHQ1m18381;
	Wed, 11 Jun 2003 13:26:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BHMum18258
	for <lemonade@optimus.ietf.org>; Wed, 11 Jun 2003 13:22:56 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18044
	for <lemonade@ietf.org>; Wed, 11 Jun 2003 13:22:52 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q9HF-0001wy-00
	for lemonade@ietf.org; Wed, 11 Jun 2003 13:20:49 -0400
Received: from panda.com
	([206.124.149.114] helo=Ikkoku-Kan.Panda.COM ident=pat)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q9HE-0001wv-00
	for lemonade@ietf.org; Wed, 11 Jun 2003 13:20:48 -0400
Received: from localhost (mrc@localhost) by Ikkoku-Kan.Panda.COM id KAA21829; Wed, 11 Jun 2003 10:22:43 -0700 (PDT)
Date: Wed, 11 Jun 2003 10:22:43 -0700 (PDT)
From: Mark Crispin <mrc@CAC.Washington.EDU>
To: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
cc: Rick Block <rickblock@avaya.com>, lemonade@ietf.org
Subject: RE: [lemonade] Re: IMAP as a submit server
In-Reply-To: <54E40201497DF142B06B27255953F79705BFE0F9@il0015exch007u.ih.lucent.com>
Message-ID: <Pine.NXT.4.56.0306111013560.11845@Ikkoku-Kan.Panda.COM>
References: <54E40201497DF142B06B27255953F79705BFE0F9@il0015exch007u.ih.lucent.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Wed, 11 Jun 2003, Vaudreuil, Greg M (Greg) wrote:
> 2) IMAP plus IMAP-Submit (maybe via SMTP/IMAP splitting proxy) for
                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> Building a completely new protocol to replace IMAP and SMTP for mobile
> clients is out-of-scope.  While academically interesting, the WG and
> IESG has rejected that route.

I do not see how the underlined text can be resolved with the latter
statement.  I also question about how the "WG" could have rejected
anything, given that the WG was just recently formed.

Perhaps you intended "completely" to be a moderating word.  If so, I think
that needs clarification.

The SMTP/IMAP splitting proxy *is* a new protocol.  It can be chartered to
be a "user" of SMTP/IMAP as opposed to a replacement of SMTP or IMAP.
Indeed, the proxy should be defined in terms of what SMTP and IMAP will be
generated (although there *is* the prospect of substitutes, most obviously
NNTP in the short-term).

If this constitutes "not a completely new protocol" and thus an acceptable
route to you, please say so.

The more I think about it, the more that I think that the proxy may be a
good way out of the problem.  We have chattiness and RTT problems with
both SMTP and IMAP.  We have timing race problems with IMAP.  We have an
issue of installed base.

-- 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 mailnull@www1.ietf.org  Wed Jun 11 15:57:44 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11785
	for <lemonade-archive@odin.ietf.org>; Wed, 11 Jun 2003 15:57:43 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5BJvG730388
	for lemonade-archive@odin.ietf.org; Wed, 11 Jun 2003 15:57:16 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BJvFm30385
	for <lemonade-web-archive@optimus.ietf.org>; Wed, 11 Jun 2003 15:57:15 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11115
	for <lemonade-web-archive@ietf.org>; Wed, 11 Jun 2003 15:57:13 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QBgb-0003Ba-00
	for lemonade-web-archive@ietf.org; Wed, 11 Jun 2003 15:55:09 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19QBga-0003BX-00
	for lemonade-web-archive@ietf.org; Wed, 11 Jun 2003 15:55:08 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BJv4m30374;
	Wed, 11 Jun 2003 15:57:04 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BJuSm30345
	for <lemonade@optimus.ietf.org>; Wed, 11 Jun 2003 15:56:28 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10283
	for <lemonade@ietf.org>; Wed, 11 Jun 2003 15:56:26 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QBfq-0003BF-00
	for lemonade@ietf.org; Wed, 11 Jun 2003 15:54:22 -0400
Received: from champdsl-25-66.mcleodusa.net ([216.43.25.66] helo=episteme-software.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19QBfp-0003B1-00
	for lemonade@ietf.org; Wed, 11 Jun 2003 15:54:21 -0400
Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with
 ESMTP (Eudora Internet Mail Server X 3.2.2b1);
 Wed, 11 Jun 2003 14:55:58 -0500
Mime-Version: 1.0
X-Sender: resnick@resnick1.qualcomm.com
Message-Id: <p06001425bb0d39b644d8@[216.43.25.67]>
In-Reply-To: <Pine.NXT.4.56.0306111008100.11845@Ikkoku-Kan.Panda.COM>
References: 
 <54E40201497DF142B06B27255953F79705BFDF0B@il0015exch007u.ih.lucent.com>
 <Pine.NXT.4.56.0306111008100.11845@Ikkoku-Kan.Panda.COM>
X-Mailer: Eudora [Macintosh version 6.0a15]
Date: Wed, 11 Jun 2003 14:55:54 -0500
To: Mark Crispin <mrc@CAC.Washington.EDU>
From: Pete Resnick <presnick@qualcomm.com>
Subject: Re: [lemonade] Call for requirement consensus
Cc: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>,
        "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On 6/11/03 at 10:10 AM -0700, Mark Crispin wrote:

>In other words, it is a requirement that there be a basic forward of 
>message or atomic message part without download.  Precise mechanism 
>to be determined.

Something with which I wholeheartedly agree.

pr
-- 
Pete Resnick <mailto:presnick@qualcomm.com>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Wed Jun 11 16:30:42 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22050
	for <lemonade-archive@odin.ietf.org>; Wed, 11 Jun 2003 16:30:42 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5BKUEq00511
	for lemonade-archive@odin.ietf.org; Wed, 11 Jun 2003 16:30:14 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BKUEm00508
	for <lemonade-web-archive@optimus.ietf.org>; Wed, 11 Jun 2003 16:30:14 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21480
	for <lemonade-web-archive@ietf.org>; Wed, 11 Jun 2003 16:30:11 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QCCV-0003UT-00
	for lemonade-web-archive@ietf.org; Wed, 11 Jun 2003 16:28:07 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19QCCU-0003UQ-00
	for lemonade-web-archive@ietf.org; Wed, 11 Jun 2003 16:28:06 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BKT5m00421;
	Wed, 11 Jun 2003 16:29:05 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BKSBm00342
	for <lemonade@optimus.ietf.org>; Wed, 11 Jun 2003 16:28:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19065
	for <lemonade@ietf.org>; Wed, 11 Jun 2003 16:28:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QCAW-0003RW-00
	for lemonade@ietf.org; Wed, 11 Jun 2003 16:26:04 -0400
Received: from inet-consulting.com ([4.23.9.166] helo=royer.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19QCAV-0003RQ-00
	for lemonade@ietf.org; Wed, 11 Jun 2003 16:26:03 -0400
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h5BKRxbt009846
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <lemonade@ietf.org>; Wed, 11 Jun 2003 13:28:05 -0700
Message-ID: <3EE790C9.3080101@Royer.com>
Date: Wed, 11 Jun 2003 14:27:53 -0600
From: Doug Royer <Doug@Royer.com>
Reply-To: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: lemonade@ietf.org
Subject: Re: [lemonade] Strawman for Submit based message composition
References: <2147483647.1055264863@nifty-jr.west.sun.com> <3EE67B17.7080208@Royer.com> <Pine.WNT.4.60.0306101753331.2408@Tomobiki-Cho.CAC.Washington.EDU>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070501000208010202020808"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This is a cryptographically signed message in MIME format.

--------------ms070501000208010202020808
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Mark Crispin wrote:
 >
 >(your insulting comments removed from this reply)
>...
> 
> 
>>I think the GENRUL command could be eliminated:
>>
>>  As the client is going to be sent something that tells it that
>>  a non-downloaded body part exits, why not make that something
>>  compatible with the 'BURL'?
> 
> 
> Huh?  That's what GENURL creates.

So why do the round trip?

> 
>>  Now that round trip is eliminated.
>>  Generating some authentication token / UID or CID/MID / whatever
>>  can not be that complex for each non-downloaded body part or
>>  message.
> 
> 
> If you're talking about the client generating the URL,

No. I was talking about modifying the IMAP server so that we can avoid
the round trip in the first place.

 > then perhaps we can
> have something returned at select time that allows the client to build
> URLs for any data in the mailbox via a well-known algorithm.

Or that would work. Just eliminate that added round trip.

> All that's needed is something that the IMAP server, upon receiving the
> URL, can validate that an authorized client generated it.  So it's
> important that a bad guy can't use an valid URL to create one of his own.

I still think that the best approach is to have the IMAP server do the
submit :-)
-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  Doug@Royer.com                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

--------------ms070501000208010202020808
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC
A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j
cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB
MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T
BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN
VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre
qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+
5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA
MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg
TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD
QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx
ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz
IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq
hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34
1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA
gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK
YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd
SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC
AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF
BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl
cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl
IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs
MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq
1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2
TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail
MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE
AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO
b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG
MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD
VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV
BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv
43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y
lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP
D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn
0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK
bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg
hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT
IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI
AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t
L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk
OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW
yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1
MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl
ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTEyMDI3NTRaMCMGCSqGSIb3DQEJBDEWBBRb
koLffEFzAD9AlmEw4HgvKyN5ZjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL
KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAY0cMAbJjyaFv
0SF1R4vXBirY2rcbc+fiIrhdRBjHFDOcMGH3+/HpE59vi3INY1BLZvWBQu01+YNHXZDRdur7
oF4JCbcLKIDZvOu/Ly/VlFOv58Rjm37oovMog4RLIv0CnPxmb9zihxWFFz+7EL7tmyN8JQnA
eQRF3YsoXizOoE3anESBU3RMrGEj53wKUjBDtm8cDCbmStb2gIH3t05NRj/mc0P+MwnkZ4gW
Z0/HpZUmv9KczSFn7agGEYZhrmS2FKTDJx+iSZbh3FMj5l6jF2SUl/XLaOTiPYfxrd6iwrYt
g0UcaqX18X6fYnRdKGV42WKfOk+ceLbpZxPykSi2hgAAAAAAAA==
--------------ms070501000208010202020808--

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



From mailnull@www1.ietf.org  Wed Jun 11 16:35:10 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29008
	for <lemonade-archive@odin.ietf.org>; Wed, 11 Jun 2003 16:35:10 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5BKYhE00824
	for lemonade-archive@odin.ietf.org; Wed, 11 Jun 2003 16:34:43 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BKYgm00821
	for <lemonade-web-archive@optimus.ietf.org>; Wed, 11 Jun 2003 16:34:42 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28238
	for <lemonade-web-archive@ietf.org>; Wed, 11 Jun 2003 16:34:39 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QCGq-0003X6-00
	for lemonade-web-archive@ietf.org; Wed, 11 Jun 2003 16:32:36 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19QCGp-0003X3-00
	for lemonade-web-archive@ietf.org; Wed, 11 Jun 2003 16:32:35 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BKYVm00796;
	Wed, 11 Jun 2003 16:34:31 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BKWXm00663
	for <lemonade@optimus.ietf.org>; Wed, 11 Jun 2003 16:32:33 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24808
	for <lemonade@ietf.org>; Wed, 11 Jun 2003 16:32:30 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QCEk-0003WG-00
	for lemonade@ietf.org; Wed, 11 Jun 2003 16:30:26 -0400
Received: from inet-consulting.com ([4.23.9.166] helo=royer.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19QCEj-0003WD-00
	for lemonade@ietf.org; Wed, 11 Jun 2003 16:30:25 -0400
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h5BKWNbt009920
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <lemonade@ietf.org>; Wed, 11 Jun 2003 13:32:28 -0700
Message-ID: <3EE791D2.20701@Royer.com>
Date: Wed, 11 Jun 2003 14:32:18 -0600
From: Doug Royer <Doug@Royer.com>
Reply-To: lemonade@ietf.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: lemonade@ietf.org
Subject: Re: [lemonade] Re: IMAP as a submit server
References: <54E40201497DF142B06B27255953F79705BFD86F@il0015exch007u.ih.lucent.com> <Pine.WNT.4.60.0306101039160.2760@Tomobiki-Cho.CAC.Washington.EDU> <p06001419bb0bc963f08d@[216.43.25.67]> <Pine.WNT.4.60.0306101239060.2408@Tomobiki-Cho.CAC.Washington.EDU> <p0600141abb0bfec9749c@[216.43.25.67]> <Pine.WNT.4.60.0306101436010.2408@Tomobiki-Cho.CAC.Washington.EDU> <3EE6653E.9020109@Royer.com> <Pine.WNT.4.60.0306101611500.2408@Tomobiki-Cho.CAC.Washington.EDU> <3EE678C1.1020000@Royer.com> <Pine.WNT.4.60.0306101736330.2408@Tomobiki-Cho.CAC.Washington.EDU> <3EE68104.4010409@Royer.com> <Pine.WNT.4.60.0306101811190.2408@Tomobiki-Cho.CAC.Washington.EDU>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040302090203010606010606"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This is a cryptographically signed message in MIME format.

--------------ms040302090203010606010606
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Mark Crispin wrote:

> 
> In the case of locking, you are talking about adding new assumptions which
> current do not exist, and deleting other assumptions that do exist.  Yet
> you seem to think that this can be done without changing the protocol.
> 

It can, I did it for several of my customeres in the past. Yet
no one has a clue because it is totally in the implementation.

And YES, we are talking about updating something, perhaps some
IMAP implementation considerations section, and I am arguing not
the over the wire protocol.


-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  Doug@Royer.com                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

--------------ms040302090203010606010606
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC
A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j
cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB
MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T
BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN
VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre
qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+
5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA
MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg
TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD
QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx
ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz
IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq
hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34
1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA
gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK
YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd
SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC
AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF
BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl
cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl
IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs
MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq
1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2
TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail
MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE
AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO
b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG
MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD
VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV
BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv
43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y
lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP
D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn
0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK
bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg
hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT
IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI
AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t
L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk
OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW
yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1
MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl
ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTEyMDMyMThaMCMGCSqGSIb3DQEJBDEWBBSc
B6IaPWSvAY7WtdM/WasdBaACrzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL
KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAN6K1xv/9IF8O
RKqpA+sJ+ioXKJeHoGwrAnIVy7NfZ9gRwNp6wGfiPxpH3PLs0vbrCv9iksCxVXXqPIu7j00L
jbAqAduh9/CKHtTX9BUiF5VbnqiimbYfkA+eNqDWL8DGUCeG++TRPRE5T/mCBkYQIzdcKdxt
gyNfk3TNjLDX6kJhUrsLkQcgXoFTJmgVrDLCOy5KPRtg96m+fErFh5s/4M5RheULsOfTTIbL
XisYXRnBEIKOAdCCoe3rfibSmNhevAKMU6EdZauhR37syQyy44myxTKVMgIKachFNKz2pBAf
Wx12HAa7j/XpUqz1lgA11Y0yRoHI3KWwsIrbvf3rlAAAAAAAAA==
--------------ms040302090203010606010606--

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



From mailnull@www1.ietf.org  Wed Jun 11 18:08:34 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05807
	for <lemonade-archive@odin.ietf.org>; Wed, 11 Jun 2003 18:08:34 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5BM88510666
	for lemonade-archive@odin.ietf.org; Wed, 11 Jun 2003 18:08:08 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BM88m10663
	for <lemonade-web-archive@optimus.ietf.org>; Wed, 11 Jun 2003 18:08:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05735
	for <lemonade-web-archive@ietf.org>; Wed, 11 Jun 2003 18:08:03 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QDjE-0004Sf-00
	for lemonade-web-archive@ietf.org; Wed, 11 Jun 2003 18:06:00 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19QDjD-0004Sc-00
	for lemonade-web-archive@ietf.org; Wed, 11 Jun 2003 18:05:59 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BM83m10640;
	Wed, 11 Jun 2003 18:08:03 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BM5tm09680
	for <lemonade@optimus.ietf.org>; Wed, 11 Jun 2003 18:05:55 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05497
	for <lemonade@ietf.org>; Wed, 11 Jun 2003 18:05:50 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QDh5-0004Rs-00
	for lemonade@ietf.org; Wed, 11 Jun 2003 18:03:47 -0400
Received: from champdsl-25-66.mcleodusa.net ([216.43.25.66] helo=episteme-software.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19QDh4-0004Rm-00
	for lemonade@ietf.org; Wed, 11 Jun 2003 18:03:46 -0400
Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with
 ESMTP (Eudora Internet Mail Server X 3.2.2b1);
 Wed, 11 Jun 2003 17:05:22 -0500
Mime-Version: 1.0
X-Sender: resnick@resnick1.qualcomm.com
Message-Id: <p06001427bb0d42745175@[216.43.25.67]>
In-Reply-To: 
 <Pine.WNT.4.60.0306101042020.2760@Tomobiki-Cho.CAC.Washington.EDU>
References: <3EE4C3EB.A8A32ABE@sun.com>
 <a06001406bb0a7f742ef1@[10.10.0.150]>
 <Pine.NXT.4.56.0306091132430.11845@Ikkoku-Kan.Panda.COM>
 <p06001410bb0a97292a4e@[216.43.25.67]>
 <Pine.WNT.4.60.0306091433020.924@Tomobiki-Cho.CAC.Washington.EDU>
 <p06001411bb0ae3b51b57@[216.43.25.67]>
 <Pine.NXT.4.56.0306092112530.11845@Ikkoku-Kan.Panda.COM>
 <p06001417bb0ba02445e7@[216.43.25.67]>
 <Pine.WNT.4.60.0306101042020.2760@Tomobiki-Cho.CAC.Washington.EDU>
X-Mailer: Eudora [Macintosh version 6.0a15]
Date: Wed, 11 Jun 2003 17:05:18 -0500
To: Mark Crispin <MRC@CAC.Washington.EDU>
From: Pete Resnick <presnick@qualcomm.com>
Cc: lemonade@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Subject: [lemonade] IMAP-based composition straw man (Was: Life on the List, and
 Vienna)
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On 6/10/03 at 12:38 PM -0700, Mark Crispin wrote:

>On Tue, 10 Jun 2003, Pete Resnick wrote:
>>- How does the message composer constitute a security hole?
>
>A message composer, by its nature, has complex buffer management; it 
>is, in effect, a text editor.  Text in mail can expand (e.g. due to 
>quoting) to a much larger size than the original.

Leaving the rest of this debate until later, I think we've got a 
basic level of not understanding each other here, because I don't see 
any complex buffer management here that IMAP doesn't already do. This 
misunderstanding may be because no one has ever written down the 
proposal for IMAP-based compose/submit. So let me, like Chris, give a 
sketch of what I'm thinking about:

There are two different potential mecahnisms we're discussion: "Send 
this message" or "Compose and send this message".

I don't think there's any misunderstanding about how "Send this 
message" works: I give a command to the IMAP server which includes a 
particular message from the IMAP store to send and a list of 
recipients (in a more complex setup with ESMTP options), and the IMAP 
server connects to a submit server (port 587 or port 25 as it likes), 
sends the SMTP commands to send the message, and sends the message 
itself (unchanged) in the DATA portion. There is definitely 
discussion to be had about the syntax of such a command (e.g., how to 
represent the ESMTP options if you desired them) as well as the 
requirements on the IMAP server (e.g., whether there is a requirement 
to connect to an SMTP server that can handle 8BITMIME to avoid 
transcoding issues), but I think everyone here has a basic 
understanding of what this feature entails.

It's the "Compose and send this message" that I think there is some 
confusion on. So here's what I see:

A client APPEND's a message *template* to the IMAP store. It marks it 
in a way to indicate that it is a template. (Perhaps we can use 
\Draft for this, but I'll leave that open for now.)

A message template will contain the entire message (headers and all) 
that the client wants to send, and may be a simple text message, or a 
complex multipart message. However, the template will not contain any 
body parts of the message (including, potentially, the top-level 
contents) that the client wishes to retrieve from other messages in 
the IMAP store. To include a body part from another message (either a 
full message or a subpart of a multipart message), the client makes 
the Content-Type of that part "message/external-body" which includes 
the pointer to the body to be included.

The client then issues a command similar (identical?) to the "Send 
this message" command above. The IMAP server connects to the submit 
server, sends the appropriate commands, and then (because it is 
indicated as a template) sends the message template one part at a 
time. If it encounters a part *in the message template* which has any 
Content-Type other than "message/external-body", it sends that body 
part of the template (including it's headers) as-is. If the IMAP 
server finds a body part with a Content-Type of 
"message/external-body" *in the template* which points to a message 
body on the IMAP server, it sends the encapsulated headers of the 
"message/external-body" followed by the contents of the IMAP message 
body indicated by the external-body.

The IMAP server does not need to examine the contents of the body 
parts it is retrieving from elsewhere in the IMAP store; it fetches 
them normally, redirecting the output to the submit server rather 
than to the requesting client. The IMAP server does not recurse 
through the referenced body parts looking for more external-body 
parts.

The actual sending would likely complete asynchronously.

There are a few caveats here:

- If the client wishes to include an external-body part in the 
template message which it actually wants sent as an external-body 
(i.e., not replaced with some other contents), we will need a 
mechanism for the client to mark that part of the template as such. 
Perhaps a parameter to the content-type?

- I'm not entirely sure of some semantics of some kinds of 
external-body references. For example, if the top-level Content-Type 
of the template message is "message/external-body", which headers get 
replaced by the encapsulated headers? Is it only the Content-* 
headers or all of them? If the latter, the top-level headers of the 
message are only dummies, and the actual "To:", "From:", etc. fields 
would actually be in the encapsulated headers. We have to know this 
to make the operation clear.

- The client is going to have to be responsible for setting the 
appropriate CTE's for the embedded parts. It should know this when it 
goes to include the referenced part (on the assumption that it's 
going to have to at least look at the headers in order to include 
it), but it's something that a client is going to have to be aware of.

- I haven't noted where the "reference count" business we were 
talking about in another thread gets included. I'm guessing that upon 
issuing the command, the server might scan the message for references 
and up the reference count on each immediately, failing immediately 
if any part has been deleted in the interim, but again, this may 
still need some hashing out.

This scheme doesn't do any "text editing" that Mark's message seemed 
to be concerned about. It doesn't have the functionality of 
external-body references to things *not* on the IMAP server.  It's 
pretty bare bones. But it does allow you the functionality of taking 
a message (or message template) which you have on the server and 
sending it. You don't have to worry about uploading it twice, once to 
the submit server and once to your "outbox" archive, or waiting for 
the submit server to deposit it back into your archive. You can 
compose it at one time, put it on your server, and not send it 
immediately (or delete it if you decide later to not send it at all). 
And you don't have your submit server given access to your IMAP store 
if you don't want to design your network that way.

Of course, doing this does not preclude also creating a full-fledged 
submit server as Chris and Mark have suggested where external-bodies 
to things *not* on the IMAP server could be included. But that 
service (which I view as much more heavyweight and much more 
complicated to implement) isn't required to get meet the requirements 
of LEMONADE, and I think this is the cleaner path to addressing those 
requirements.

pr
-- 
Pete Resnick <mailto:presnick@qualcomm.com>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Wed Jun 11 19:23:59 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09137
	for <lemonade-archive@odin.ietf.org>; Wed, 11 Jun 2003 19:23:59 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5BNNW316712
	for lemonade-archive@odin.ietf.org; Wed, 11 Jun 2003 19:23:32 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BNNWm16709
	for <lemonade-web-archive@optimus.ietf.org>; Wed, 11 Jun 2003 19:23:32 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09086
	for <lemonade-web-archive@ietf.org>; Wed, 11 Jun 2003 19:23:28 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QEuD-0005D9-00
	for lemonade-web-archive@ietf.org; Wed, 11 Jun 2003 19:21:25 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19QEuD-0005D6-00
	for lemonade-web-archive@ietf.org; Wed, 11 Jun 2003 19:21:25 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BNNGm16621;
	Wed, 11 Jun 2003 19:23:16 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BNJVm16370
	for <lemonade@optimus.ietf.org>; Wed, 11 Jun 2003 19:19:31 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08935
	for <lemonade@ietf.org>; Wed, 11 Jun 2003 19:19:28 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QEqK-0005Aw-00
	for lemonade@ietf.org; Wed, 11 Jun 2003 19:17:24 -0400
Received: from mxout2.cac.washington.edu ([140.142.33.4])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QEqK-0005At-00
	for lemonade@ietf.org; Wed, 11 Jun 2003 19:17:24 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9])
	by mxout2.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h5BNJSbr019072;
	Wed, 11 Jun 2003 16:19:28 -0700
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
	(authenticated bits=0)
	by smtp.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h5BNJR7k026287
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Wed, 11 Jun 2003 16:19:27 -0700
Date: Wed, 11 Jun 2003 16:19:27 -0700 (Pacific Daylight Time)
From: Mark Crispin <MRC@CAC.Washington.EDU>
To: Pete Resnick <presnick@qualcomm.com>
cc: lemonade@ietf.org
In-Reply-To: <p06001427bb0d42745175@[216.43.25.67]>
Message-ID: <Pine.WNT.4.60.0306111515120.3404@Tomobiki-Cho.CAC.Washington.EDU>
References: <3EE4C3EB.A8A32ABE@sun.com> <a06001406bb0a7f742ef1@[10.10.0.150]>
 <Pine.NXT.4.56.0306091132430.11845@Ikkoku-Kan.Panda.COM>
 <p06001410bb0a97292a4e@[216.43.25.67]> <Pine.WNT.4.60.0306091433020.924@Tomobiki-Cho.CAC.Washington.EDU>
 <p06001411bb0ae3b51b57@[216.43.25.67]> <Pine.NXT.4.56.0306092112530.11845@Ikkoku-Kan.Panda.COM>
 <p06001417bb0ba02445e7@[216.43.25.67]> <Pine.WNT.4.60.0306101042020.2760@Tomobiki-Cho.CAC.Washington.EDU>
 <p06001427bb0d42745175@[216.43.25.67]>
Organization: Networks & Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [lemonade] Re: IMAP-based composition straw man (Was: Life on the List, and
 Vienna)
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Wed, 11 Jun 2003, Pete Resnick wrote:
> So let me, like Chris, give a
> sketch of what I'm thinking about:

Thank you.  This is more or less what I expected you were talking about,
albeit a bit more complex in that you have a separate "send this message"
vs. "compose and send this message" with an earlier appended template.  A
simplified version would be a single "compose and send" which takes the
template as an argument (thus all messages being sent are templates).

You've outlined a rather complex procedure that *something* must do, no
matter which proposal ("do it in IMAP, do it in submit service, do it in a
proxy") is undertaken.

Specifically, *something* must:
 . deal with ESMTP in its full glory, including 8BITMIME issues.
 . add missing headers to the template; commonly, submit clients expect
    the submit server to provide Date, From, Message-ID, and similar
    niceties.  I expect that a mobile client, especially one with
    limited internal resources, would do the same.
 . recognize MESSAGE/EXTERNAL-BODY MIME parts, resolve them, and rewrite
    those parts using the resolved contents.
 . in some way arrange for the data referenced by these parts not to be
    deleted until the send has completed.

The desire to put this into the IMAP server is apparently based upon two
observations:
 1) IMAP already servers know how to parse MIME
 2) it is assumed that the external-body data will be on the same IMAP
     server

I dispute that second point.  I think that you conceed that this is an
failing of the "do it in IMAP" model.  Although I consider this to be a
fatal flaw, there is no concensus on that point.

There is also a implied presumption that it is easier to do a local disk
access to get the data than it is to use any protocol to get the data.

As to the first point, I personally do not believe that "IMAP servers
already know how to parse MIME" is a big advantage.  I know how to do all
four components of the above task, and I think that parsing MIME is one of
the easiest parts.  Perhaps that is just me, and everybody else thinks
that parsing MIME is very hard.

> This scheme doesn't do any "text editing" that Mark's message seemed
> to be concerned about.

By "text editing", I was referring to the addition of missing headers and
the rewrite of portions of the message.  RFC 2822/SMTP is pretty nasty in
that you generally need a buffer that is at least twice the size of the
input string, plus three bytes, to deal with worst case scenarios.

I've seen several buffer overflow attacks on RFC 2822/SMTP generating
code, and have spent a substantial amount of time dealing with it.  The
notion of having RFC 2822/SMTP generating code in an IMAP server gives me
the willies -- and from recent unhappy experience I know a lot of what to
look for!  It's what I don't yet know that worries me.

> You don't have to worry about uploading it twice, once to
> the submit server and once to your "outbox" archive,

I am willing to stipulate that this should be a requirement of whatever
solution is desired.

> or waiting for
> the submit server to deposit it back into your archive.

I agree that this is desirable, and perhaps even should be a requirement.
But do you really want the template, or the fully-resolved message in the
archive?  I think that the latter is more desirable, but that's just me.

> You can
> compose it at one time, put it on your server, and not send it
> immediately (or delete it if you decide later to not send it at all).

OK, so you want the ability to have drafts stored on the server instead of
on the device?  We can make that be a requirement.

> And you don't have your submit server given access to your IMAP store
> if you don't want to design your network that way.

Here, we have a disconnect.

I define submit server as "the entity that accepts the template from the
client, assembles it as a complete message, and passes the message to the
MTA."

I think that you define submit server as "the first-level SMTP server that
does MTA queuing."  [Is this correct?]

Using my definition, the submit server has full access to the user's
entire IMAP store (your proposal) or only access to the authorized pieces
(my model).

Using your definition, the submit server either has no access other than
to the fully-assembled message (your proposal) or only access to the
authorized pieces (my model).

Now, if we have an IMAP/SMTP proxy which talks directly to the mobile
device (and then to the IMAP and SMTP servers) that does all this work, we
have the following:
 . the first-level SMTP server that does MTA queuing has no access other
    than to the fully-assembled message
 . the IMAP server does not do assembly or passing to the MTA
 . the proxy has only acess to the authorized pieces

We can also stipulate that fcc and resolution of locking issues be part of
the proxy's responsibility.

> Of course, doing this does not preclude also creating a full-fledged
> submit server as Chris and Mark have suggested where external-bodies
> to things *not* on the IMAP server could be included.

Suppose that instead of a full-fledged submit server, we back off to a
the more limited IMAP/SMTP proxy server.  It *could* grow to be the
full-fledged thing, but it doesn't have to.

I also point out that that the proxy server can be specified (as part of
its design) to talk in the most ideal way to the mobile device, without
any of the chattiness or RTTs of IMAP and SMTP.

Another beauty is that, from the mobile device point of view, there is
nothing "heavyweight" about this.  If anything, the mobile device should
see a simpler world.

I think that if we all give just a little bit, we ought to be able to
settle upon this as a win-win situation for everybody.

-- 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 mailnull@www1.ietf.org  Wed Jun 11 22:07:42 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11990
	for <lemonade-archive@odin.ietf.org>; Wed, 11 Jun 2003 22:07:42 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5C27GB27062
	for lemonade-archive@odin.ietf.org; Wed, 11 Jun 2003 22:07:16 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C27Fm27059
	for <lemonade-web-archive@optimus.ietf.org>; Wed, 11 Jun 2003 22:07:15 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11971
	for <lemonade-web-archive@ietf.org>; Wed, 11 Jun 2003 22:07:12 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QHSd-0005yp-00
	for lemonade-web-archive@ietf.org; Wed, 11 Jun 2003 22:05:07 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19QHSd-0005ym-00
	for lemonade-web-archive@ietf.org; Wed, 11 Jun 2003 22:05:07 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C273m26672;
	Wed, 11 Jun 2003 22:07:03 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C26qm26535
	for <lemonade@optimus.ietf.org>; Wed, 11 Jun 2003 22:06:52 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11965
	for <lemonade@ietf.org>; Wed, 11 Jun 2003 22:06:49 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QHSG-0005yj-00
	for lemonade@ietf.org; Wed, 11 Jun 2003 22:04:44 -0400
Received: from champdsl-25-66.mcleodusa.net ([216.43.25.66] helo=episteme-software.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19QHSF-0005yb-00
	for lemonade@ietf.org; Wed, 11 Jun 2003 22:04:43 -0400
Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with
 ESMTP (Eudora Internet Mail Server X 3.2.2b1);
 Wed, 11 Jun 2003 21:06:21 -0500
Mime-Version: 1.0
X-Sender: resnick@resnick1.qualcomm.com
Message-Id: <p06001429bb0d7b1296c2@[216.43.25.67]>
In-Reply-To: 
 <Pine.WNT.4.60.0306111515120.3404@Tomobiki-Cho.CAC.Washington.EDU>
References: <3EE4C3EB.A8A32ABE@sun.com>
 <a06001406bb0a7f742ef1@[10.10.0.150]>
 <Pine.NXT.4.56.0306091132430.11845@Ikkoku-Kan.Panda.COM>
 <p06001410bb0a97292a4e@[216.43.25.67]>
 <Pine.WNT.4.60.0306091433020.924@Tomobiki-Cho.CAC.Washington.EDU>
 <p06001411bb0ae3b51b57@[216.43.25.67]>
 <Pine.NXT.4.56.0306092112530.11845@Ikkoku-Kan.Panda.COM>
 <p06001417bb0ba02445e7@[216.43.25.67]>
 <Pine.WNT.4.60.0306101042020.2760@Tomobiki-Cho.CAC.Washington.EDU>
 <p06001427bb0d42745175@[216.43.25.67]>
 <Pine.WNT.4.60.0306111515120.3404@Tomobiki-Cho.CAC.Washington.EDU>
X-Mailer: Eudora [Macintosh version 6.0a15]
Date: Wed, 11 Jun 2003 21:06:15 -0500
To: Mark Crispin <MRC@CAC.Washington.EDU>
From: Pete Resnick <presnick@qualcomm.com>
Subject: [lemonade] Re: IMAP-based composition straw man (Was: Life on the
 List, and  Vienna)
Cc: lemonade@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

Let me answer one later question right up front:

On 6/11/03 at 4:19 PM -0700, Mark Crispin wrote:

>I define submit server as "the entity that accepts the template from the
>client, assembles it as a complete message, and passes the message to the
>MTA."
>
>I think that you define submit server as "the first-level SMTP server that
>does MTA queuing."  [Is this correct?]

Right. In the model I've described, there is an 2821 or 2476 server 
that is going to accept the message from the IMAP server and forward 
it along. That could running on the same machine as the IMAP server, 
but I see it as a separate functional unit in this model.

Perhaps we can skip the term "submit server" and instead agree to 
different terms here:

1. Outgoing SMTP server or "OSMTP" server. The OSMTP server does MTA 
queuing. Some OSMTP servers are 2821 servers; some are 2476 servers.

2. The composition server is the entity that accepts the template 
from the client, assembles it into a complete message, and passes the 
message to the MTA.

And I think we agree on the definition of:

3. The IMAP server.

The questions are "Where does 2 go?" and "What is 2 responsible to 
do?" My proposal puts 2 into 3 (call it "IMAP compose"). Chris's 
proposal puts 2 into 1 (call it "OSMTP compose"). There's been the 
suggestion that 2 could also stand alone (call it "Proxy compose"). 
What 2 has to do still has some open issues. Are we OK to there?

Now, getting on to the rest of the message:

>A simplified version would be a single "compose and send" which 
>takes the template as an argument (thus all messages being sent are 
>templates).

Sure. In addition, you could add an argument which says "Don't expand 
*any* external-body parts" to give you full functionality.

>Specifically, *something* must:
>  . deal with ESMTP in its full glory, including 8BITMIME issues.

Right, though the OSMTP server might deal with some of that already 
by being a 2476 server.

>  . add missing headers to the template; commonly, submit clients expect
>     the submit server to provide Date, From, Message-ID, and similar
>     niceties.  I expect that a mobile client, especially one with
>     limited internal resources, would do the same.

Interesting question. Perhaps they do need to be dealt with, perhaps 
not. I know Date used to be a serious problem for resource-limited 
clients (especially time zones), but I don't know if that's an issue 
anymore. From (or Sender)  are the more interesting ones. We need to 
nail down whether this is a requirement or not.

>  . recognize MESSAGE/EXTERNAL-BODY MIME parts, resolve them, and rewrite
>     those parts using the resolved contents.

Absolutely. This is the big ticket item.

>  . in some way arrange for the data referenced by these parts not to be
>     deleted until the send has completed.

Sure.

There are other potential requirements mentioned below. Let's bring 
them up here:

. store the template for later submission
. store "what was sent" in the IMAP store (i.e., the outbox), where 
"what was sent" might be the template or might be the composed 
message.

>The desire to put this into the IMAP server is apparently based upon 
>two observations:
>  1) IMAP already servers know how to parse MIME
>  2) it is assumed that the external-body data will be on the same IMAP server

Let's add:
3) Users are always going to identify themselves to the IMAP server; 
in some current environments, users don't identify themselves to any 
other (e.g., OSMTP) servers. (This is the security benefit.)
4) IMAP servers are good places for storage of user data (where OSMTP 
servers generally are not).
5) IMAP servers are going to have to store "what was sent" anyway, so 
starting the template off on the IMAP server is efficient.

>I dispute that second point.  I think that you conceed that this is 
>an failing of the "do it in IMAP" model.  Although I consider this 
>to be a fatal flaw, there is no concensus on that point.

Agreed that we disagree. I think the most likely usage model is 
"forward without download".

>There is also a implied presumption that it is easier to do a local 
>disk access to get the data than it is to use any protocol to get 
>the data.

There's more to it than just easier. An entity that has local control 
of the data has many more tools at its disposal to do things like 
locking, reference counting, copying, etc. If you use a protocol, you 
need protocol bits for each of these, and you have to fully 
understand the semantics for each of them. That can be a tricky 
business. So I would add this to the benefits list as:

6) Local disk access has operational benefits.

>As to the first point, I personally do not believe that "IMAP 
>servers already know how to parse MIME" is a big advantage.  I know 
>how to do all four components of the above task, and I think that 
>parsing MIME is one of the easiest parts.  Perhaps that is just me, 
>and everybody else thinks that parsing MIME is very hard.

Think about the following (and I'm not claiming the answers here 
clearly support my position):

- How big is your MIME parsing code in relation to the rest of the 
IMAP system? How big would it be in relation to the rest of a 
present-day OSMTP system?

- How much of your MIME parsing code assumes quick random access to 
storage or large memory buffers?

>By "text editing", I was referring to the addition of missing 
>headers and the rewrite of portions of the message. [Tricky to do; 
>possible buffer overflow issues.]

Addition of headers is one thing and is an open issue. If we need to 
do it, deciding what entity does it is a real concern. Other sorts of 
rewrite I don't think is as much of an issue in this system. IMAP is 
passing around legal MIME parts already. The only buffer issues would 
be if you were doing further CTE transcodings, which I *don't* 
suggest is done on the composition end of things. Is there some other 
function that I'm missing?

>But do you really want the template, or the fully-resolved message 
>in the archive?  I think that the latter is more desirable, but 
>that's just me.

If it were me, and I had an IMAP server with a nice database-like 
store, upon getting the template I'd resolve the pointer to the 
external-body, incremement the reference count on the object, and 
store the pointer to the object with the template. I wouldn't want to 
fully resolve (i.e., keep a separate copy of all of the data) if I 
didn't have to.

>OK, so you want the ability to have drafts stored on the server 
>instead of on the device?  We can make that be a requirement.

Indeed, a separate item that's been on the what-some-folks-would-like 
list is "future delivery with cancel". In the IMAP compose model, you 
could add a queuing time to the command and knock off that item as 
well.

>>And you don't have your submit server given access to your IMAP 
>>store if you don't want to design your network that way.
>
>Here, we have a disconnect.

Right. So let me rephrase with the definitions I gave at the beginning:

- In the IMAP compose model, the composition server has local disk 
access to the entire IMAP store. The OSMTP server has protocol access 
only to the fully-assembled message.

- In the OSMTP compose model, the composition server and OSMTP server 
have protocol access to the authorized pieces of the IMAP store and 
the fully-assembled message.

- In the Proxy compose model, the composition server has protocol 
access to only the authorized parts. The OSMTP server has protocol 
access to only the fully-assembled message.

In all cases, the IMAP server (obviously) has local disk access to 
the entire IMAP store.

I think that makes the security implications as well as the protocol 
implications pretty clear.

>Suppose that instead of a full-fledged submit server, we back off to 
>a the more limited IMAP/SMTP proxy server.  It *could* grow to be 
>the full-fledged thing, but it doesn't have to.

I'm not sure I understand where the "limited" comes in. What is the 
difference between the limited one and the full-fledged one?

>I also point out that that the proxy server can be specified (as 
>part of its design) to talk in the most ideal way to the mobile 
>device, without any of the chattiness or RTTs of IMAP and SMTP.

Agreed, though the mobile device is required to talk to IMAP at some 
point anyway (obviously for accessing mail, but also to decide what's 
going to go into the template and, in the Proxy model, to get the 
tokens for the desired parts).

>Another beauty is that, from the mobile device point of view, there 
>is nothing "heavyweight" about this.  If anything, the mobile device 
>should see a simpler world.

I'm not clear on why. Can you describe more what you mean?

>I think that if we all give just a little bit, we ought to be able 
>to settle upon this as a win-win situation for everybody.

I still see a downside to the Proxy compose (since it has many of the 
same disadvantages of the OSMTP compose) and an upside to the IMAP 
compose, especially in relation to the 6 observations above. But I'm 
ready to listen to the upside of the proxy if you can answer a few of 
the above questions. And as I said, doing IMAP compose doesn't 
preclude doing either OSMTP compose or Proxy compose.

pr
-- 
Pete Resnick <mailto:presnick@qualcomm.com>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Wed Jun 11 23:32:36 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13254
	for <lemonade-archive@odin.ietf.org>; Wed, 11 Jun 2003 23:32:36 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5C3W8M31751
	for lemonade-archive@odin.ietf.org; Wed, 11 Jun 2003 23:32:08 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C3W8m31748
	for <lemonade-web-archive@optimus.ietf.org>; Wed, 11 Jun 2003 23:32:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13251
	for <lemonade-web-archive@ietf.org>; Wed, 11 Jun 2003 23:32:05 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QImn-0006Fq-00
	for lemonade-web-archive@ietf.org; Wed, 11 Jun 2003 23:30:01 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19QImn-0006Fn-00
	for lemonade-web-archive@ietf.org; Wed, 11 Jun 2003 23:30:01 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C3W3m31739;
	Wed, 11 Jun 2003 23:32:03 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C3VVm31715
	for <lemonade@optimus.ietf.org>; Wed, 11 Jun 2003 23:31:31 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13246
	for <lemonade@ietf.org>; Wed, 11 Jun 2003 23:31:27 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QImC-0006Fk-00
	for lemonade@ietf.org; Wed, 11 Jun 2003 23:29:24 -0400
Received: from mxout3.cac.washington.edu ([140.142.32.166])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QImB-0006Fh-00
	for lemonade@ietf.org; Wed, 11 Jun 2003 23:29:23 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139])
	by mxout3.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h5C3VSSL018406;
	Wed, 11 Jun 2003 20:31:28 -0700
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
	(authenticated bits=0)
	by smtp.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h5C3VRQ0004768
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Wed, 11 Jun 2003 20:31:27 -0700
Date: Wed, 11 Jun 2003 20:31:27 -0700 (Pacific Daylight Time)
From: Mark Crispin <MRC@CAC.Washington.EDU>
To: Pete Resnick <presnick@qualcomm.com>
cc: lemonade@ietf.org
Subject: Re: [lemonade] Re: IMAP-based composition straw man (Was: Life on
 the List, and  Vienna)
In-Reply-To: <p06001429bb0d7b1296c2@[216.43.25.67]>
Message-ID: <Pine.WNT.4.60.0306111927080.388@Tomobiki-Cho.CAC.Washington.EDU>
References: <3EE4C3EB.A8A32ABE@sun.com> <a06001406bb0a7f742ef1@[10.10.0.150]>
 <Pine.NXT.4.56.0306091132430.11845@Ikkoku-Kan.Panda.COM>
 <p06001410bb0a97292a4e@[216.43.25.67]> <Pine.WNT.4.60.0306091433020.924@Tomobiki-Cho.CAC.Washington.EDU>
 <p06001411bb0ae3b51b57@[216.43.25.67]> <Pine.NXT.4.56.0306092112530.11845@Ikkoku-Kan.Panda.COM>
 <p06001417bb0ba02445e7@[216.43.25.67]> <Pine.WNT.4.60.0306101042020.2760@Tomobiki-Cho.CAC.Washington.EDU>
 <p06001427bb0d42745175@[216.43.25.67]> <Pine.WNT.4.60.0306111515120.3404@Tomobiki-Cho.CAC.Washington.EDU>
 <p06001429bb0d7b1296c2@[216.43.25.67]>
Organization: Networks & Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Wed, 11 Jun 2003, Pete Resnick wrote:
> The questions are "Where does 2 go?" and "What is 2 responsible to
> do?" My proposal puts 2 into 3 (call it "IMAP compose"). Chris's
> proposal puts 2 into 1 (call it "OSMTP compose"). There's been the
> suggestion that 2 could also stand alone (call it "Proxy compose").
> What 2 has to do still has some open issues. Are we OK to there?

OK, but I really don't like the idea of the name "OSMTP compose", because
it ties "SMTP" and all of its baggage.  Since you think that the term
"submit server" has baggage, how about we call it "post server compose"
and hopefully avoid anyone's baggage?

But I'll use "OSMTP compose" in the remainder of this response.

> I know Date used to be a serious problem for resource-limited
> clients (especially time zones), but I don't know if that's an issue
> anymore.

Do CDMA phones know about timezones?  I don't think that GSM or TDMA
phones do.

> There are other potential requirements mentioned below. Let's bring
> them up here:
> . store the template for later submission
> . store "what was sent" in the IMAP store (i.e., the outbox), where
> "what was sent" might be the template or might be the composed
> message.

Both of these are possible with any of the proposals.  It's more of a work
item for OSMTP compose than the other two; but let's leave that point with
a stipulate that OSMTP compose will be required to address this in a
satisfactory fashion if that is the chosen proposal.

> 3) Users are always going to identify themselves to the IMAP server;
> in some current environments, users don't identify themselves to any
> other (e.g., OSMTP) servers. (This is the security benefit.)

I believe this to be a vanishing issue.

> 4) IMAP servers are good places for storage of user data (where OSMTP
> servers generally are not).
> 5) IMAP servers are going to have to store "what was sent" anyway, so
> starting the template off on the IMAP server is efficient.

I don't consider these two points to be particularly important in the
decision, because post and storage are different functions.  But if you
want to phrase this as a requirement for "only one upload from the mobile
client" we can go with that.

> 6) Local disk access has operational benefits.
> An entity that has local control
> of the data has many more tools at its disposal to do things like
> locking, reference counting, copying, etc.

[Slight shuffle in your text for brevity]

I remain unconvinced about locking/reference counting.  The locking hole
is between the last access by the mobile client and the post.  You need
some sort of assist to prevent a simultaneous session from expunging the
data.  The most likely way to do that assist would be by protocol
negotiation of a lock.

Another way would be to have the server keep track of items mentioned in
active drafts, and prohibit their expunge.  There's user interface ("why
can't I expunge?") and implementation complexity issues.

> Think about the following (and I'm not claiming the answers here
> clearly support my position):

Fair questions

> - How big is your MIME parsing code in relation to the rest of the
> IMAP system?

Quite small.  My entire MIME parser consists of three routines: parse
content header, parse content text, and parse parameter.  The RFC 2822
code is about three times the size.

> How big would it be in relation to the rest of a
> present-day OSMTP system?

It depends upon whether or not it has 8BITMIME support, doesn't it?  I
don't have C language SMTP server code which I wrote, but my C language
SMTP client code is twice the size of the C language MIME code.

Looking at my old PDP-10 assembly language code (where I have both client
and server), I see that my SMTP client code is about 1/4 the size of my
SMTP server code, and that SMTP server code didn't do any munging of the
message contents.  Too bad I don't have any PDP-10 assembly language MIME
code, but my PDP-10 RFC 822 code is smaller(!) than the C code.

We're into "lies, damn lies, and statistics" at this point; comparing C to
assembly language in applications with vastly different functional sets.

> - How much of your MIME parsing code assumes quick random access to
> storage or large memory buffers?

It doesn't.  It would *like* to run that way, but it doesn't have to.
Credit having to build PC Pine in 640K DOS (days all of us are happy to
forget).

> Addition of headers is one thing and is an open issue. If we need to
> do it, deciding what entity does it is a real concern. Other sorts of
> rewrite I don't think is as much of an issue in this system. IMAP is
> passing around legal MIME parts already.

Yes, but only insofar as it blats out data from the message.  It doesn't
have to do any thought about how to format that data.

> The only buffer issues would
> be if you were doing further CTE transcodings, which I *don't*
> suggest is done on the composition end of things.

CTE is actually fairly easy.  In the case of BINARY->BASE64 the exact
output size is known via calculation.  In the case of BASE64->BINARY and
QP->8BIT the resulting output is usually smaller and never larger than the
source; you can do it by overwriting the source buffer.  Only the 8BIT->QP
encoding involves having to figure a worse case.

> >Suppose that instead of a full-fledged submit server, we back off to
> >a the more limited IMAP/SMTP proxy server.  It *could* grow to be
> >the full-fledged thing, but it doesn't have to.
> I'm not sure I understand where the "limited" comes in. What is the
> difference between the limited one and the full-fledged one?

One difference would be that the intended client for this thing is a
mobile device.  It is not a full-fledged submit server that something like
Pine or Eudora would want to use.

> >I also point out that that the proxy server can be specified (as
> >part of its design) to talk in the most ideal way to the mobile
> >device, without any of the chattiness or RTTs of IMAP and SMTP.
> Agreed, though the mobile device is required to talk to IMAP at some
> point anyway (obviously for accessing mail, but also to decide what's
> going to go into the template and, in the Proxy model, to get the
> tokens for the desired parts).

Not at all for the tokens (the proxy would do all that) and not
necessarily for the other stuff.  I know that "compressed IMAP" is
something that a lot of people talk about; why can't this proxy be a front
end for IMAP?

> >Another beauty is that, from the mobile device point of view, there
> >is nothing "heavyweight" about this.  If anything, the mobile device
> >should see a simpler world.
> I'm not clear on why. Can you describe more what you mean?

This is that "front end" idea I alluded to above.

Since the proxy server is the mobile device's window on the world, it can
talk to the mobile device exactly as the mobile device wants.

-- 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 mailnull@www1.ietf.org  Thu Jun 12 00:26:41 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14226
	for <lemonade-archive@odin.ietf.org>; Thu, 12 Jun 2003 00:26:41 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5C4QE302873
	for lemonade-archive@odin.ietf.org; Thu, 12 Jun 2003 00:26:14 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C4QEm02870
	for <lemonade-web-archive@optimus.ietf.org>; Thu, 12 Jun 2003 00:26:14 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14217
	for <lemonade-web-archive@ietf.org>; Thu, 12 Jun 2003 00:26:11 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QJd9-0006RR-00
	for lemonade-web-archive@ietf.org; Thu, 12 Jun 2003 00:24:07 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19QJd8-0006RO-00
	for lemonade-web-archive@ietf.org; Thu, 12 Jun 2003 00:24:06 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C4Q4m02843;
	Thu, 12 Jun 2003 00:26:04 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C4PJm02774
	for <lemonade@optimus.ietf.org>; Thu, 12 Jun 2003 00:25:19 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14208
	for <lemonade@ietf.org>; Thu, 12 Jun 2003 00:25:15 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QJcG-0006RB-00
	for lemonade@ietf.org; Thu, 12 Jun 2003 00:23:12 -0400
Received: from outbound03.telus.net ([199.185.220.222] helo=priv-edtnes11-hme0.telusplanet.net)
	by ietf-mx with esmtp (Exim 4.12)
	id 19QJcF-0006Qr-00
	for lemonade@ietf.org; Thu, 12 Jun 2003 00:23:11 -0400
Received: from orthanc.ab.ca ([209.89.195.21])
          by priv-edtnes11-hme0.telusplanet.net
          (InterMail vM.5.01.05.17 201-253-122-126-117-20021021) with ESMTP
          id <20030612042446.BTWV12685.priv-edtnes11-hme0.telusplanet.net@orthanc.ab.ca>;
          Wed, 11 Jun 2003 22:24:46 -0600
Date: Wed, 11 Jun 2003 22:24:45 -0600
Subject: Re: [lemonade] Channel gaps?
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: Erev Ari <Ari.Erev@comverse.com>,
        "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
To: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
From: Lyndon Nerenberg <lyndon@orthanc.ab.ca>
In-Reply-To: <54E40201497DF142B06B27255953F79705BFDF08@il0015exch007u.ih.lucent.com>
Message-Id: <CC1CCE41-9C8D-11D7-A10F-000393D34A62@orthanc.ab.ca>
X-Mailer: Apple Mail (2.552)
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5C4PJm02776
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>
X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h5C4Q4m02843
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5C4QEm02870
Content-Transfer-Encoding: 8bit


On Wednesday, June 11, 2003, at 08:37  AM, Vaudreuil, Greg M (Greg) 
wrote:
>
> Unless I mis-understand the current draft (-02 I believe in my 
> disconnected state), there is an incompleteness with respect 
> to security.  The IMAP server is requested to deliver a content via an 
> external transport such as IMAP, HTTP, or RTP.  The specification does 
> not deal with the authentication of the requesting client connection 
> (a submit server?) on that port.

Correct. A lot of work needs to be done on the security aspects, and 
there are *many* security implications of the extension. To date about 
all that has been discussed is that, if it's at all possible, we want 
to pass authentication tokens within the URLs. The big problem that I 
see with this is that we can't set a single policy for how these 
authentication tokens are to be derived.

Every time this subject comes up, people get very quiet. It's going to 
be a difficult problem to solve, I think. I'm planning to push another 
draft out after Vienna, and some discussion on this now might allow for 
at least one strawman to be included in the document (preferably more).

--lyndon

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



From mailnull@www1.ietf.org  Thu Jun 12 01:10:44 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15068
	for <lemonade-archive@odin.ietf.org>; Thu, 12 Jun 2003 01:10:44 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5C5AGd06197
	for lemonade-archive@odin.ietf.org; Thu, 12 Jun 2003 01:10:16 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C5AGm06194
	for <lemonade-web-archive@optimus.ietf.org>; Thu, 12 Jun 2003 01:10:16 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15051
	for <lemonade-web-archive@ietf.org>; Thu, 12 Jun 2003 01:10:14 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QKJk-0006cG-00
	for lemonade-web-archive@ietf.org; Thu, 12 Jun 2003 01:08:08 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19QKJj-0006cD-00
	for lemonade-web-archive@ietf.org; Thu, 12 Jun 2003 01:08:07 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C5A3m06186;
	Thu, 12 Jun 2003 01:10:03 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C59gm06156
	for <lemonade@optimus.ietf.org>; Thu, 12 Jun 2003 01:09:42 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15048
	for <lemonade@ietf.org>; Thu, 12 Jun 2003 01:09:40 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QKJC-0006c8-00
	for lemonade@ietf.org; Thu, 12 Jun 2003 01:07:34 -0400
Received: from champdsl-25-66.mcleodusa.net ([216.43.25.66] helo=episteme-software.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19QKJB-0006bz-00
	for lemonade@ietf.org; Thu, 12 Jun 2003 01:07:33 -0400
Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with
 ESMTP (Eudora Internet Mail Server X 3.2.2b1);
 Thu, 12 Jun 2003 00:09:12 -0500
Mime-Version: 1.0
X-Sender: resnick@resnick1.qualcomm.com
Message-Id: <p0600142abb0db2f2af49@[216.43.25.67]>
In-Reply-To: 
 <Pine.WNT.4.60.0306111927080.388@Tomobiki-Cho.CAC.Washington.EDU>
References: <3EE4C3EB.A8A32ABE@sun.com>
 <a06001406bb0a7f742ef1@[10.10.0.150]>
 <Pine.NXT.4.56.0306091132430.11845@Ikkoku-Kan.Panda.COM>
 <p06001410bb0a97292a4e@[216.43.25.67]>
 <Pine.WNT.4.60.0306091433020.924@Tomobiki-Cho.CAC.Washington.EDU>
 <p06001411bb0ae3b51b57@[216.43.25.67]>
 <Pine.NXT.4.56.0306092112530.11845@Ikkoku-Kan.Panda.COM>
 <p06001417bb0ba02445e7@[216.43.25.67]>
 <Pine.WNT.4.60.0306101042020.2760@Tomobiki-Cho.CAC.Washington.EDU>
 <p06001427bb0d42745175@[216.43.25.67]>
 <Pine.WNT.4.60.0306111515120.3404@Tomobiki-Cho.CAC.Washington.EDU>
 <p06001429bb0d7b1296c2@[216.43.25.67]>
 <Pine.WNT.4.60.0306111927080.388@Tomobiki-Cho.CAC.Washington.EDU>
X-Mailer: Eudora [Macintosh version 6.0a15]
Date: Thu, 12 Jun 2003 00:09:06 -0500
To: Mark Crispin <MRC@CAC.Washington.EDU>
From: Pete Resnick <presnick@qualcomm.com>
Subject: Re: [lemonade] Re: IMAP-based composition straw man (Was: Life on
  the List, and  Vienna)
Cc: lemonade@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On 6/11/03 at 8:31 PM -0700, Mark Crispin wrote:

>On Wed, 11 Jun 2003, Pete Resnick wrote:
>["IMAP compose", "OSMTP compose", and "Proxy compose"]
>
>OK, but I really don't like the idea of the name "OSMTP compose", 
>because it ties "SMTP" and all of its baggage.

Gotcha. But it's necessarily (at least) an "MTA compose", right? 
Because the issue here is that the MTA and the composition server 
live in the same space. Am I mischaracterizing?

>Do CDMA phones know about timezones?

I'm pretty sure they do. (I was looking at some API's that have GMT, 
and I know of some stuff that is definitely in local time, so I think 
it's in there someplace.)

>I don't think that GSM or TDMA phones do.

I'm not sure, but I'm sure someone in this group knows.

>>. store the template for later submission
>>. store "what was sent" in the IMAP store (i.e., the outbox), where 
>>"what was sent" might be the template or might be the composed 
>>message.
>
>Both of these are possible with any of the proposals.  It's more of 
>a work item for OSMTP compose than the other two

For the "store the template for later submission", do you suppose 
that the Proxy compose will store on the IMAP server or in it's own 
storage?

>6) Local disk access has operational benefits.
>>An entity that has local control of the data has many more tools at 
>>its disposal to do things like locking, reference counting, 
>>copying, etc.
>
>[Slight shuffle in your text for brevity]
>
>I remain unconvinced about locking/reference counting.  The locking 
>hole is between the last access by the mobile client and the post. 
>You need some sort of assist to prevent a simultaneous session from 
>expunging the data.  The most likely way to do that assist would be 
>by protocol negotiation of a lock.

The other choice is to do a reference count, where no lock is 
required. Say you reference a body in another message. Its reference 
count starts at 1. You attempt to increment reference count on the 
object. That could fail if the expunge already happened (same as the 
lock attempt), but if it succeeds, the reference count is 2. Then, 
the simultaneous expunge simply decrements the reference count on the 
object, leaving it with a reference count of 1 and not deleted. The 
expunge "succeeds", but you still have a copy of the object. Of 
course, this requires a storage model where the references to the 
objects can be independent, but this isn't exactly a new way of 
thinking.

>Another way would be to have the server keep track of items 
>mentioned in active drafts, and prohibit their expunge.

That seems bad.

>>How big would [the MIME parsing code] be in relation to the rest of 
>>a present-day OSMTP system?
>
>It depends upon whether or not it has 8BITMIME support, doesn't it?

To some extent. Remember that there's a difference between parsing a 
MIME message to retrieve an individual part and converting CTEs: I'm 
pretty sure converting CTEs can be done in a single pass with a stack 
for multipart separators. I'm betting your MIME parsing code doesn't 
work that way; at least, I'll bet you keep pointers into different 
parts of the message for random access.

>We're into "lies, damn lies, and statistics" at this point;

Agreed. But my guess is that doing the kind of MIME manipulation 
required for this would be a relatively small part of an IMAP 
server's code, and a rather more significant part of an MTAs code, 
with or without 8BITMIME.

>>- How much of your MIME parsing code assumes quick random access to 
>>storage or large memory buffers?
>
>It doesn't.  It would *like* to run that way, but it doesn't have to.

Well, right. But I assume that there's plenty of "do this if you 
don't have to suffer through small buffers and serial access" because 
it's more efficient, and that it doesn't run "ideally" if it has to 
suffer through those things.

>>Other sorts of rewrite I don't think is as much of an issue in this 
>>system. IMAP is passing around legal MIME parts already.
>
>Yes, but only insofar as it blats out data from the message.  It 
>doesn't have to do any thought about how to format that data.
>[...]
>CTE is actually fairly easy. [Discussion of output buffers.]

In fact, most CTE stuff can be streamed and not pre-buffered. But my 
original question still stands: Other than adding headers, what 
additional kind of processing that it doesn't do now is an IMAP 
server going to have to do that is going to require it to do lots of 
buffer manipulations during composition?

>>the mobile device is required to talk to IMAP at some point anyway 
>>(obviously for accessing mail, but also to decide what's going to 
>>go into the template and, in the Proxy model, to get the tokens for 
>>the desired parts).
>
>Not at all for the tokens (the proxy would do all that) and not 
>necessarily for the other stuff.  I know that "compressed IMAP" is 
>something that a lot of people talk about; why can't this proxy be a 
>front end for IMAP?
>[...]
>This is that "front end" idea I alluded to above.
>
>Since the proxy server is the mobile device's window on the world, 
>it can talk to the mobile device exactly as the mobile device wants.

Oh. Sorry. I missed this in the earlier mail. You're suggesting that 
the Proxy talks to the IMAP server and the MTA server for *all* of 
the mobile devices operations (at least for composition, and perhaps 
for everything). In effect, the Proxy *is* an IMAP client *and* an 
MTA client, and a compose server (and potentially a mail access 
server) for the mobile device.

Well, that's an interesting idea, but unlike the other two models, it 
has one really big downside: This is an entirely new service with an 
entirely new set of code (caveat that there will obviously be a bunch 
of reuse from IMAP and SMTP clients) and most importantly an entirely 
new protocol. I don't think LEMONADE should be taking on something 
like that.

pr
-- 
Pete Resnick <mailto:presnick@qualcomm.com>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Thu Jun 12 01:40:42 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15460
	for <lemonade-archive@odin.ietf.org>; Thu, 12 Jun 2003 01:40:41 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5C5eDb07967
	for lemonade-archive@odin.ietf.org; Thu, 12 Jun 2003 01:40:13 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C5eDm07964
	for <lemonade-web-archive@optimus.ietf.org>; Thu, 12 Jun 2003 01:40:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15455
	for <lemonade-web-archive@ietf.org>; Thu, 12 Jun 2003 01:40:11 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QKmj-0006io-00
	for lemonade-web-archive@ietf.org; Thu, 12 Jun 2003 01:38:05 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19QKmi-0006il-00
	for lemonade-web-archive@ietf.org; Thu, 12 Jun 2003 01:38:04 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C5e2m07943;
	Thu, 12 Jun 2003 01:40:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C5dYm07908
	for <lemonade@optimus.ietf.org>; Thu, 12 Jun 2003 01:39:34 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15448
	for <lemonade@ietf.org>; Thu, 12 Jun 2003 01:39:32 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QKm6-0006ic-00
	for lemonade@ietf.org; Thu, 12 Jun 2003 01:37:26 -0400
Received: from oe-im1pub.managedmail.com ([206.46.164.52] helo=oe-im1.bizmailsrvcs.net)
	by ietf-mx with esmtp (Exim 4.12)
	id 19QKm6-0006iO-00
	for lemonade@ietf.org; Thu, 12 Jun 2003 01:37:26 -0400
Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26])
          by oe-im1.bizmailsrvcs.net
          (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP
          id <20030612053902.XMJD2597.oe-im1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>;
          Thu, 12 Jun 2003 00:39:02 -0500
Received: from AKSTEBBENS.mshome.net ([64.14.194.240])
          by oe-ismta1.bizmailsrvcs.net
          (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP
          id <20030612053856.WRSC6261.oe-ismta1.bizmailsrvcs.net@AKSTEBBENS.mshome.net>;
          Thu, 12 Jun 2003 00:38:56 -0500
Date: Wed, 11 Jun 2003 22:38:56 -0700
From: "Alan K. Stebbens" <alan.stebbens@openwave.com>
X-Mailer: The Bat! (v1.62r) Personal
Reply-To: "Alan K. Stebbens" <alan.stebbens@openwave.com>
Organization: Openwave Systems, Inc.
X-Priority: 3 (Normal)
Message-ID: <1843469988.20030611223856@openwave.com>
To: Doug Royer <Doug@royer.com>
CC: lemonade@ietf.org
Subject: Re: [lemonade] Strawman for Submit based message composition
In-Reply-To: <3EE790C9.3080101@Royer.com>
References: <2147483647.1055264863@nifty-jr.west.sun.com>
 <3EE67B17.7080208@Royer.com>
 <Pine.WNT.4.60.0306101753331.2408@Tomobiki-Cho.CAC.Washington.EDU>
 <3EE790C9.3080101@Royer.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hello Doug,

DR> I still think that the best approach is to have the IMAP server do the
DR> submit :-)

Here is an alternative submission protocol for mobile clients, supporting
forwarding without downloading, using standard IMAP4 features and standard
SMTP features.

I'll use a picture (because I like them :^)

            Please view in a fixed-width font such as Courier.

+--------+           +--------+           +----------+    5         +-----+
| Mobile |           |  IMAP  |---RECENT->|  Outbox  |--MAIL From-->| MTA |
| Client |--APPEND-->| Server |     2     |  Server  |  RCPT To     |     |
|        |    1      |        |<--SEARCH--| ( IMAP ) |  DATA        |     |
+--------+           |        |   RECENT  | (Client) |  ...         |     |
                     |        |     3     |          |  .           |     |
                     |        |---FETCH-->|          |              |     |
                     |        |     4     |          |              |     |
                     |"Outbox"|           |          |              |     |
                     +--------+           +----------+              +-----+

The "envelope" information that is needed for the SMTP transactions could be
carried in the message that is APPENDed to the IMAP4 "Outbox".  Example:

        To: you@yourdomain.com
        From: me@mydomain.com
        Subject: a mail
        X-Env-From: me@myserver.mydomain.com
        X-Env-To: you@yourdomain.com

        blah blah

The "X-Env-From:" and "X-Env-To:" headers would carry the MAIL and RCPT
information, and would be removed from the message transmitted over the SMTP
connection.

When a message is appended to a given user's Outbox, a later connection by
another, server-based IMAP client, called the "Outbox Server", would be used
to search for RECENT messages in the "Outbox".  For concurrent sessions,
asynchronous, untagged RECENT responses would be sent as a notification to
the Outbox Server, which would then do a SEARCH RECENT to get the recently
arrived messages in the Outbox.

After FETCHing the recent messages in the Outbox, the Outbox Server would
dereference any MIME parts consisting of IMAP URLs, the UIDs of which would
be relative to the same mailbox containing the Outbox.

After FETCHing any IMAP URLs to referenced MIME parts (or entire messages),
and replacing the MIME part of the outgoing message with the FETCHed
contents, the new outgoing message would be submitted to a configured MTA
using the envelope information defined by the "X-Env" headers.

This mechanism does not require any protocol changes to IMAP or to SMTP.

By virtue being part of the operator's infrastructure, the Outbox Server can
obtain access to each user's IMAP Outbox folder and limit itself to further
access solely within that same mailbox, including the IMAP URLs to messages
in the INBOX.

The sole liability to this mechanism is the current lack of a scalable
notification mechanism of newly APPENDed messages across all Outbox folders
for a given IMAP server.  It is not practical for an Outbox Server to
maintain sessions for *all* Outbox folders in order to receive asynchronous
untagged RECENT responses, and it is not practical for an Outbox Server to
repeatedly poll all the Outbox folders on a large scale IMAP server.

Instead, the occurrence of newly APPENDed messages into an Outbox folder
should trigger a notification mechanism to the Outbox Server.  How can this
be accomplished and by what mechanism should be an interesting discussion.

-- 
Best regards,
 Alan K. Stebbens <alan.stebbens@openwave.com>
 Principal Product Technologist, Messaging
 Openwave Systems, Inc.
 Cell: +1.805.886.8886  Voice/Fax: +1.866.579.0801
 Desk: +1.805.884.3162
 YIM/MSN: alan_stebbens  ICQ: 51361674  AIM: akstebbens   

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



From mailnull@www1.ietf.org  Thu Jun 12 01:55:34 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15640
	for <lemonade-archive@odin.ietf.org>; Thu, 12 Jun 2003 01:55:34 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5C5t6T08398
	for lemonade-archive@odin.ietf.org; Thu, 12 Jun 2003 01:55:06 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C5t6m08395
	for <lemonade-web-archive@optimus.ietf.org>; Thu, 12 Jun 2003 01:55:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15637
	for <lemonade-web-archive@ietf.org>; Thu, 12 Jun 2003 01:55:03 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QL17-0006ly-00
	for lemonade-web-archive@ietf.org; Thu, 12 Jun 2003 01:52:58 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19QL17-0006lv-00
	for lemonade-web-archive@ietf.org; Thu, 12 Jun 2003 01:52:57 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C5t2m08385;
	Thu, 12 Jun 2003 01:55:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C5sem08360
	for <lemonade@optimus.ietf.org>; Thu, 12 Jun 2003 01:54:40 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15634
	for <lemonade@ietf.org>; Thu, 12 Jun 2003 01:54:38 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QL0i-0006ls-00
	for lemonade@ietf.org; Thu, 12 Jun 2003 01:52:32 -0400
Received: from outbound03.telus.net ([199.185.220.222] helo=priv-edtnes11-hme0.telusplanet.net)
	by ietf-mx with esmtp (Exim 4.12)
	id 19QL0h-0006lp-00
	for lemonade@ietf.org; Thu, 12 Jun 2003 01:52:31 -0400
Received: from orthanc.ab.ca ([209.89.195.21])
          by priv-edtnes11-hme0.telusplanet.net
          (InterMail vM.5.01.05.17 201-253-122-126-117-20021021) with ESMTP
          id <20030612055407.CGAX12685.priv-edtnes11-hme0.telusplanet.net@orthanc.ab.ca>;
          Wed, 11 Jun 2003 23:54:07 -0600
Date: Wed, 11 Jun 2003 23:54:05 -0600
Subject: Re: [lemonade] Strawman for Submit based message composition
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: Doug Royer <Doug@royer.com>, lemonade@ietf.org
To: "Alan K. Stebbens" <alan.stebbens@openwave.com>
From: Lyndon Nerenberg <lyndon@orthanc.ab.ca>
In-Reply-To: <1843469988.20030611223856@openwave.com>
Message-Id: <4697F932-9C9A-11D7-A10F-000393D34A62@orthanc.ab.ca>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
Content-Transfer-Encoding: 7bit
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


On Wednesday, June 11, 2003, at 11:38  PM, Alan K. Stebbens wrote:

> The "X-Env-From:" and "X-Env-To:" headers would carry the MAIL and RCPT
> information, and would be removed from the message transmitted over 
> the SMTP
> connection.

The problem here is you will always have a namespace collision (however 
unlikely).

One way around this would be to submit the entire thing as an 
application/batch-smtp.

--lyndon

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



From mailnull@www1.ietf.org  Thu Jun 12 07:58:45 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05219
	for <lemonade-archive@odin.ietf.org>; Thu, 12 Jun 2003 07:58:45 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5CBwGX12996
	for lemonade-archive@odin.ietf.org; Thu, 12 Jun 2003 07:58:16 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CBwGm12993
	for <lemonade-web-archive@optimus.ietf.org>; Thu, 12 Jun 2003 07:58:16 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05216
	for <lemonade-web-archive@ietf.org>; Thu, 12 Jun 2003 07:58:15 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QQga-00017i-00
	for lemonade-web-archive@ietf.org; Thu, 12 Jun 2003 07:56:08 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19QQga-00017f-00
	for lemonade-web-archive@ietf.org; Thu, 12 Jun 2003 07:56:08 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CBw4m12985;
	Thu, 12 Jun 2003 07:58:04 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CBvfm12940
	for <lemonade@optimus.ietf.org>; Thu, 12 Jun 2003 07:57:41 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05199
	for <lemonade@ietf.org>; Thu, 12 Jun 2003 07:57:39 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QQg1-000176-00
	for lemonade@ietf.org; Thu, 12 Jun 2003 07:55:33 -0400
Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19QQg0-000170-00
	for lemonade@ietf.org; Thu, 12 Jun 2003 07:55:32 -0400
Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83])
	by hoemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h5CBv6O05813
	for <lemonade@ietf.org>; Thu, 12 Jun 2003 06:57:07 -0500 (CDT)
Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19)
	id <L2XM1D97>; Thu, 12 Jun 2003 06:57:06 -0500
Message-ID: <54E40201497DF142B06B27255953F79705BFE5AE@il0015exch007u.ih.lucent.com>
From: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
To: "Alan K. Stebbens" <alan.stebbens@openwave.com>
Cc: lemonade@ietf.org
Subject: RE: [lemonade] Strawman for Submit based message composition
Date: Thu, 12 Jun 2003 06:57:03 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>


Alan,

This looks like one of several possible implementations of IMAP-Submit.  The protocol between the mobile client and IMAP server is not materially different from Pete's outline.  It does not matter to the mobile client whether the IMAP server does the processing itself or it delegates it to an external submission client.  However, as you note, separating the functions does require additional enhancements to IMAP.  It appears to me this implementation as all the costs of both IMAP-submit and SMTP-submit since the submission client needs all the access control machinery (and more) of an external SMTP-submit server.

One question:  Do we believe the IMAP client needs some form of confirmation at the end of the submission transaction that the submission was sucessful?   It seems very valuable to return a sucess or detailed failure reason at submission time rather than to send a complete DSN back to the senders mailbox for subsequent retreival.... lots more round-trips and a degraded user experience.

Greg V.

-----Original Message-----
From: Alan K. Stebbens [mailto:alan.stebbens@openwave.com]
Sent: Thursday, June 12, 2003 12:39 AM
To: Doug Royer
Cc: lemonade@ietf.org
Subject: Re: [lemonade] Strawman for Submit based message composition


Hello Doug,

DR> I still think that the best approach is to have the IMAP server do the
DR> submit :-)

Here is an alternative submission protocol for mobile clients, supporting
forwarding without downloading, using standard IMAP4 features and standard
SMTP features.

I'll use a picture (because I like them :^)

            Please view in a fixed-width font such as Courier.

+--------+           +--------+           +----------+    5         +-----+
| Mobile |           |  IMAP  |---RECENT->|  Outbox  |--MAIL From-->| MTA |
| Client |--APPEND-->| Server |     2     |  Server  |  RCPT To     |     |
|        |    1      |        |<--SEARCH--| ( IMAP ) |  DATA        |     |
+--------+           |        |   RECENT  | (Client) |  ...         |     |
                     |        |     3     |          |  .           |     |
                     |        |---FETCH-->|          |              |     |
                     |        |     4     |          |              |     |
                     |"Outbox"|           |          |              |     |
                     +--------+           +----------+              +-----+

The "envelope" information that is needed for the SMTP transactions could be
carried in the message that is APPENDed to the IMAP4 "Outbox".  Example:

        To: you@yourdomain.com
        From: me@mydomain.com
        Subject: a mail
        X-Env-From: me@myserver.mydomain.com
        X-Env-To: you@yourdomain.com

        blah blah

The "X-Env-From:" and "X-Env-To:" headers would carry the MAIL and RCPT
information, and would be removed from the message transmitted over the SMTP
connection.

When a message is appended to a given user's Outbox, a later connection by
another, server-based IMAP client, called the "Outbox Server", would be used
to search for RECENT messages in the "Outbox".  For concurrent sessions,
asynchronous, untagged RECENT responses would be sent as a notification to
the Outbox Server, which would then do a SEARCH RECENT to get the recently
arrived messages in the Outbox.

After FETCHing the recent messages in the Outbox, the Outbox Server would
dereference any MIME parts consisting of IMAP URLs, the UIDs of which would
be relative to the same mailbox containing the Outbox.

After FETCHing any IMAP URLs to referenced MIME parts (or entire messages),
and replacing the MIME part of the outgoing message with the FETCHed
contents, the new outgoing message would be submitted to a configured MTA
using the envelope information defined by the "X-Env" headers.

This mechanism does not require any protocol changes to IMAP or to SMTP.

By virtue being part of the operator's infrastructure, the Outbox Server can
obtain access to each user's IMAP Outbox folder and limit itself to further
access solely within that same mailbox, including the IMAP URLs to messages
in the INBOX.

The sole liability to this mechanism is the current lack of a scalable
notification mechanism of newly APPENDed messages across all Outbox folders
for a given IMAP server.  It is not practical for an Outbox Server to
maintain sessions for *all* Outbox folders in order to receive asynchronous
untagged RECENT responses, and it is not practical for an Outbox Server to
repeatedly poll all the Outbox folders on a large scale IMAP server.

Instead, the occurrence of newly APPENDed messages into an Outbox folder
should trigger a notification mechanism to the Outbox Server.  How can this
be accomplished and by what mechanism should be an interesting discussion.

-- 
Best regards,
 Alan K. Stebbens <alan.stebbens@openwave.com>
 Principal Product Technologist, Messaging
 Openwave Systems, Inc.
 Cell: +1.805.886.8886  Voice/Fax: +1.866.579.0801
 Desk: +1.805.884.3162
 YIM/MSN: alan_stebbens  ICQ: 51361674  AIM: akstebbens   

_______________________________________________
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 mailnull@www1.ietf.org  Thu Jun 12 23:33:03 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06783
	for <lemonade-archive@odin.ietf.org>; Thu, 12 Jun 2003 23:33:03 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5D3WX017324
	for lemonade-archive@odin.ietf.org; Thu, 12 Jun 2003 23:32:33 -0400
Received: from ietf.org (lists.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D3WOm17321
	for <lemonade-web-archive@optimus.ietf.org>; Thu, 12 Jun 2003 23:32:24 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06779
	for <lemonade-web-archive@ietf.org>; Thu, 12 Jun 2003 23:32:19 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QfGX-0000eL-00
	for lemonade-web-archive@ietf.org; Thu, 12 Jun 2003 23:30:13 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19QfGW-0000eH-00
	for lemonade-web-archive@ietf.org; Thu, 12 Jun 2003 23:30:12 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CHq0a12036;
	Thu, 12 Jun 2003 13:52:00 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CHpLm12003
	for <lemonade@optimus.ietf.org>; Thu, 12 Jun 2003 13:51:21 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20882
	for <lemonade@ietf.org>; Thu, 12 Jun 2003 13:51:19 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QWCG-0004nU-00
	for lemonade@ietf.org; Thu, 12 Jun 2003 13:49:12 -0400
Received: from defout.telus.net ([199.185.220.240] helo=priv-edtnes51.telusplanet.net)
	by ietf-mx with esmtp (Exim 4.12)
	id 19QWCF-0004n5-00
	for lemonade@ietf.org; Thu, 12 Jun 2003 13:49:11 -0400
Received: from orthanc.ab.ca ([209.89.195.21])
          by priv-edtnes51.telusplanet.net
          (InterMail vM.5.01.05.17 201-253-122-126-117-20021021) with ESMTP
          id <20030612175047.FOMX16591.priv-edtnes51.telusplanet.net@orthanc.ab.ca>
          for <lemonade@ietf.org>; Thu, 12 Jun 2003 11:50:47 -0600
Date: Thu, 12 Jun 2003 11:50:46 -0600
Subject: Re: [lemonade] Strawman for Submit based message composition
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
From: Lyndon Nerenberg <lyndon@orthanc.ab.ca>
To: lemonade@ietf.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <54E40201497DF142B06B27255953F79705BFE5AE@il0015exch007u.ih.lucent.com>
Message-Id: <6544AEA2-9CFE-11D7-A10F-000393D34A62@orthanc.ab.ca>
X-Mailer: Apple Mail (2.552)
Content-Transfer-Encoding: 7bit
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

[Folks, please trim down the included text in your replies ...]

On Thursday, June 12, 2003, at 05:57  AM, Vaudreuil, Greg M (Greg) 
wrote:

> One question:  Do we believe the IMAP client needs some form of 
> confirmation at the end of the submission transaction that the 
> submission was sucessful?   It seems very valuable to return a sucess 
> or detailed failure reason at submission time rather than to send a 
> complete DSN back to the senders mailbox for subsequent retreival.... 
> lots more round-trips and a degraded user experience.

By the time we add this to IMAP-Submit we'll have reinvented SMTP (or 
at least, Submission). Having had a few days to digest all the list 
traffic, I'm starting to lean strongly towards a separate "message 
composition" service. Neither IMAP nor SMTP can do what we want, at 
least not without some ugly bastardization. The idea of remote 
composition has applicability in a wide range of applications, and it 
seems silly to restrict ourselves to a hacked up solution that is 
applicable to only a fraction of the potential solution space. If we 
solve this only for the IMAP server space, and the idea catches on (and 
I am convinced it will), then either a) the hack continues to get 
hacked to encompass other application spaces, or b) a new remote 
composition protocol is developed that isn't limited to just the IMAP 
space. Both of these scenarios are bad.

--lyndon

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



From mailnull@www1.ietf.org  Fri Jun 13 02:56:25 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23317
	for <lemonade-archive@odin.ietf.org>; Fri, 13 Jun 2003 02:56:25 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5D6tvj11471
	for lemonade-archive@odin.ietf.org; Fri, 13 Jun 2003 02:55:57 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D6tvm11468
	for <lemonade-web-archive@optimus.ietf.org>; Fri, 13 Jun 2003 02:55:57 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23301
	for <lemonade-web-archive@ietf.org>; Fri, 13 Jun 2003 02:55:54 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QiRW-00029z-00
	for lemonade-web-archive@ietf.org; Fri, 13 Jun 2003 02:53:46 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19QiRW-00029w-00
	for lemonade-web-archive@ietf.org; Fri, 13 Jun 2003 02:53:46 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CKP1a21935;
	Thu, 12 Jun 2003 16:25:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CKOQm21886
	for <lemonade@optimus.ietf.org>; Thu, 12 Jun 2003 16:24:26 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25721
	for <lemonade@ietf.org>; Thu, 12 Jun 2003 16:24:23 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QYaP-0005hz-00
	for lemonade@ietf.org; Thu, 12 Jun 2003 16:22:17 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QYaO-0005hw-00
	for lemonade@ietf.org; Thu, 12 Jun 2003 16:22:16 -0400
Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149])
	by numenor.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h5CKOLxO010707
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Thu, 12 Jun 2003 13:24:21 -0700 (PDT)
Received: from [10.61.33.218] (vpn-10-50-0-57.qualcomm.com [10.50.0.57])
	by neophyte.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h5CKOBuh010907;
	Thu, 12 Jun 2003 13:24:13 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <a06001422bb0e8ea3c961@[10.61.33.218]>
In-Reply-To: 
 <54E40201497DF142B06B27255953F79705BFDF3D@il0015exch007u.ih.lucent.com
 >
References: 
 <54E40201497DF142B06B27255953F79705BFDF3D@il0015exch007u.ih.lucent.com
 >
X-Mailer: Eudora for Mac OS X v6.0a
Date: Thu, 12 Jun 2003 16:22:49 -0400
To: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>,
        "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
From: Randall Gellens <randy@qualcomm.com>
Subject: Re: [lemonade] Wireless latencies
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b25
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

At 9:50 AM -0500 6/11/03, Greg M (Greg) Vaudreuil wrote:

>  My earlier message was incorrect.  Below I suggest an average RTT 
> of abount 100 ms, or a simple message submission time using 
> SMTP-submit of about 1 second.  My measured experience using a CDMA 
> data network has an average RTT of 1200 milliseconds (100 samples), 
> or about 10 seconds to send a short message using a separate SMTP 
> connection, or about 1-2 seconds using an existing IMAP connection. 
> There is good bandwidth at that RTT if the app uses it effeciently. 
> This longer RTT is consistent with other literature I have seen on 
> the subject.

The round-trip times can vary considerably, depending on a number of 
factors, including the specific options supported by the 
infrastructure, the service options requested by the handset, the 
packet sizes, the amount of interference, etc.  However, 1200 ms 
seems quite high.  It should be more like 120-140 ms.  (Plus 
processing time by the endpoints, but that shouldn't vary that much 
for wireless versus wireline.)  For example, opening a TCP connection 
(40-byte packets) would be 3*120 or 3*140 ms = 360 to 420 ms.  The 
numbers would be somewhat lower (faster) if certain service options 
are used.  Going to hosts outside the carrier's network will be 
somewhat higher (slower) of course.  In some recent tests, 280 ms 
averages were seen for18 byte pings (18+28byte header = 40 bytes) to 
www.google.com.

-- 
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 mailnull@www1.ietf.org  Fri Jun 13 10:56:35 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08836
	for <lemonade-archive@odin.ietf.org>; Fri, 13 Jun 2003 10:56:35 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5DEu8A17826
	for lemonade-archive@odin.ietf.org; Fri, 13 Jun 2003 10:56:08 -0400
Received: from ietf.org (lists.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DEu8m17823
	for <lemonade-web-archive@optimus.ietf.org>; Fri, 13 Jun 2003 10:56:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08830
	for <lemonade-web-archive@ietf.org>; Fri, 13 Jun 2003 10:56:04 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QpwC-00060L-00
	for lemonade-web-archive@ietf.org; Fri, 13 Jun 2003 10:53:56 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19QpwC-00060I-00
	for lemonade-web-archive@ietf.org; Fri, 13 Jun 2003 10:53:56 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CNw1a03025;
	Thu, 12 Jun 2003 19:58:01 -0400
Received: from ietf.org (lists.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CNvUm02986
	for <lemonade@optimus.ietf.org>; Thu, 12 Jun 2003 19:57:30 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01899
	for <lemonade@ietf.org>; Thu, 12 Jun 2003 19:57:28 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Qbub-00077x-00
	for lemonade@ietf.org; Thu, 12 Jun 2003 19:55:21 -0400
Received: from mxout3.cac.washington.edu ([140.142.32.166])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Qbua-00077u-00
	for lemonade@ietf.org; Thu, 12 Jun 2003 19:55:20 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9])
	by mxout3.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h5CNvPYx010845;
	Thu, 12 Jun 2003 16:57:25 -0700
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
	(authenticated bits=0)
	by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h5CNvP3n013931
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Thu, 12 Jun 2003 16:57:25 -0700
Date: Thu, 12 Jun 2003 16:57:24 -0700 (Pacific Daylight Time)
From: Mark Crispin <MRC@CAC.Washington.EDU>
To: Pete Resnick <presnick@qualcomm.com>
cc: lemonade@ietf.org
Subject: Re: [lemonade] Re: IMAP-based composition straw man (Was: Life on 
 the List, and  Vienna)
In-Reply-To: <p0600142abb0db2f2af49@[216.43.25.67]>
Message-ID: <Pine.WNT.4.60.0306121615270.3120@Tomobiki-Cho.CAC.Washington.EDU>
References: <3EE4C3EB.A8A32ABE@sun.com> <a06001406bb0a7f742ef1@[10.10.0.150]>
 <Pine.NXT.4.56.0306091132430.11845@Ikkoku-Kan.Panda.COM>
 <p06001410bb0a97292a4e@[216.43.25.67]> <Pine.WNT.4.60.0306091433020.924@Tomobiki-Cho.CAC.Washington.EDU>
 <p06001411bb0ae3b51b57@[216.43.25.67]> <Pine.NXT.4.56.0306092112530.11845@Ikkoku-Kan.Panda.COM>
 <p06001417bb0ba02445e7@[216.43.25.67]> <Pine.WNT.4.60.0306101042020.2760@Tomobiki-Cho.CAC.Washington.EDU>
 <p06001427bb0d42745175@[216.43.25.67]> <Pine.WNT.4.60.0306111515120.3404@Tomobiki-Cho.CAC.Washington.EDU>
 <p06001429bb0d7b1296c2@[216.43.25.67]> <Pine.WNT.4.60.0306111927080.388@Tomobiki-Cho.CAC.Washington.EDU>
 <p0600142abb0db2f2af49@[216.43.25.67]>
Organization: Networks & Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Thu, 12 Jun 2003, Pete Resnick wrote:
> >OK, but I really don't like the idea of the name "OSMTP compose",
> >because it ties "SMTP" and all of its baggage.
> Gotcha. But it's necessarily (at least) an "MTA compose", right?
> Because the issue here is that the MTA and the composition server
> live in the same space. Am I mischaracterizing?

I don't feel that either composition or submission belong in the MTA space
(and certainly not in the MUA space with IMAP).  However, for the purposes
of this discussion this disagreement may be academic.

> For the "store the template for later submission", do you suppose
> that the Proxy compose will store on the IMAP server or in it's own
> storage?

That is either "to be decided" or left to the implementation.  Unless
there is a requirement that the template be accessible to IMAP clients
which do not use the proxy facility, I don't think it matters either way.

If there is such a requirement, then that needs to be stipulated.

> The other choice is to do a reference count, where no lock is
> required. Say you reference a body in another message. Its reference
> count starts at 1. You attempt to increment reference count on the
> object. That could fail if the expunge already happened (same as the
> lock attempt), but if it succeeds, the reference count is 2. Then,
> the simultaneous expunge simply decrements the reference count on the
> object, leaving it with a reference count of 1 and not deleted. The
> expunge "succeeds", but you still have a copy of the object. Of
> course, this requires a storage model where the references to the
> objects can be independent, but this isn't exactly a new way of
> thinking.

> >Another way would be to have the server keep track of items
> >mentioned in active drafts, and prohibit their expunge.
> That seems bad.

I agree with you on "that seems bad", but in effect what you describe in
the paragraph which begins with "The other choice..." is an implementation
method of that bad thing.

That is, the reference count would be implemented by an active draft
containing a reference, and would be decremented by deactivating the draft
(either deleting it, or sending it).

You seem to envision some kind of dichotomy between "reference count" and
"lock".  Since any lock would presumably be a shared lock, this suggests a
reference count.  I see these as being the same.

Are you thinking about a lock in the POP3 sense, which I could refer to as
an exclusive lock?  That kind of lock wouldn't be particularly useful
here, other than as a way to block the acquisition of a shared lock.

One other point.  A database for a mail store has been a personal favorite
idea of mine for a long time (from IMAP's inception, in fact).  Some IMAP
server implementations do such a thing.  However, from a server management
point of view, there is *strong* pushback against a database mail store.
The reasons are outside of the scope of this discussion or LEMONADE (it'd
make a great bar topic), other than to caution that the world is not ready
to define IMAP as requiring a database.

> I'm
> pretty sure converting CTEs can be done in a single pass with a stack
> for multipart separators. I'm betting your MIME parsing code doesn't
> work that way; at least, I'll bet you keep pointers into different
> parts of the message for random access.

Such pointers are certainly generated as part of the MIME parse, but
they're not kept in the message store.  It's actually *much* easier to
recurse over nested parts than to do it single-pass with a stack,
especially if you want to be strictly compliant with MIME.

As for the ability to use pointers and do single-pass CTE conversion, you
can thank me for sticking to my guns 12 years ago and demanding that MIME
forbid nested encodings.  That was not a popular position.

> But my guess is that doing the kind of MIME manipulation
> required for this would be a relatively small part of an IMAP
> server's code, and a rather more significant part of an MTAs code,
> with or without 8BITMIME.

We'll just have to disagree on this point.  I think that you've
overestimating what an IMAP server does, and underestimating what an
8BITMIME compliant SMTP server does.  But we're both speculating at this
point.

> In fact, most CTE stuff can be streamed and not pre-buffered. But my
> original question still stands: Other than adding headers, what
> additional kind of processing that it doesn't do now is an IMAP
> server going to have to do that is going to require it to do lots of
> buffer manipulations during composition?

Header building (both RFC 2822 and MIME) and compliance with SMTP
line-length restrictions come immediately to mind.  Nor can you assume
"it's in my IMAP server, so it already complies and I can just copy it
as-is"  because your mail software may allow non-compliant text (such as
excessive line lengths) or mistagged texts, but it has an obligation not
to send such.

> You're suggesting that
> the Proxy talks to the IMAP server and the MTA server for *all* of
> the mobile devices operations (at least for composition, and perhaps
> for everything). In effect, the Proxy *is* an IMAP client *and* an
> MTA client, and a compose server (and potentially a mail access
> server) for the mobile device.

I'm suggesting this as one possible alternative.  I don't want to put all
my eggs in one basket.

> Well, that's an interesting idea, but unlike the other two models, it
> has one really big downside: This is an entirely new service with an
> entirely new set of code (caveat that there will obviously be a bunch
> of reuse from IMAP and SMTP clients) and most importantly an entirely
> new protocol. I don't think LEMONADE should be taking on something
> like that.

Unless there's a 100% show-stopper, let's keep in on the table.

I can't help but think that something in this vein would produce much more
satisfactory results for all concerned than forcing mobile devices to deal
with chatty IMAP and forcing IMAP to offer services to mobile devices that
are outside of its current scope.

I know that compressed IMAP is an important issue for many people in the
mobile device community.  To me, this practically screams for a proxy type
solution.

-- 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 mailnull@www1.ietf.org  Fri Jun 13 13:03:10 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12955
	for <lemonade-archive@odin.ietf.org>; Fri, 13 Jun 2003 13:03:10 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5DH2hX06932
	for lemonade-archive@odin.ietf.org; Fri, 13 Jun 2003 13:02:43 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DH2hm06929
	for <lemonade-web-archive@optimus.ietf.org>; Fri, 13 Jun 2003 13:02:43 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12919
	for <lemonade-web-archive@ietf.org>; Fri, 13 Jun 2003 13:02:40 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Qrui-0006sb-00
	for lemonade-web-archive@ietf.org; Fri, 13 Jun 2003 13:00:33 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Qrui-0006sY-00
	for lemonade-web-archive@ietf.org; Fri, 13 Jun 2003 13:00:32 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DGx1a03716;
	Fri, 13 Jun 2003 12:59:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DGwXm03284
	for <lemonade@optimus.ietf.org>; Fri, 13 Jun 2003 12:58:33 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12444
	for <lemonade@ietf.org>; Fri, 13 Jun 2003 12:58:29 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Qrqg-0006mS-00
	for lemonade@ietf.org; Fri, 13 Jun 2003 12:56:22 -0400
Received: from synx02.elettra.trieste.it ([140.105.2.2] helo=mac-allocchio3.elettra.trieste.it)
	by ietf-mx with smtp (Exim 4.12)
	id 19Qrqf-0006mG-00
	for lemonade@ietf.org; Fri, 13 Jun 2003 12:56:21 -0400
Received: from mac-allocchio3.elettra.trieste.it (140.105.2.18) by SYNX02 with 
 TCP/IP SMTP; Fri, 13 JUN 03 18:57 CET
Date: Fri, 13 Jun 2003 18:58:28 +0200 (CEST)
X-X-Sender: claudio@mac-allocchio3.elettra.trieste.it
To: lemonade@ietf.org
Message-ID: <Pine.OSX.4.56.0306131855090.805@mac-allocchio3.elettra.trieste.it>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
From: Claudio Allocchio <Claudio.Allocchio@garr.it>
Subject: [lemonade] OFF THREAD - Hotels in Vienna
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>


Hallo...
I just noticed that the hotels proposed "on line" from the IETF site are
just awfully more expensive than they should... and in fact on my usual
travel agent site

http://www.ventaglio.com/cgi-bin/cgi2nova.exe?SN_ADDRESS=ivvportal2&SN_METHOD=M_show&Haz=07&Hbt=04&Hpg=06&Hid=012&Hln=012&Hre=900

at pages 15 you can find the same hotels or better at much conviniente
prices.

Just for those who would like to check... or do it themselves (probably
also other travel agents have the same better offers than the official
reservation system selected by the IETF secretariat this time...

:-)

ok, end of OFF THREAD, sorry for that.

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          Claudio.Allocchio@garr.it
                        Project Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

           PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Fri Jun 13 13:16:28 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13564
	for <lemonade-archive@odin.ietf.org>; Fri, 13 Jun 2003 13:16:28 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5DHG2214714
	for lemonade-archive@odin.ietf.org; Fri, 13 Jun 2003 13:16:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DHG2m14711
	for <lemonade-web-archive@optimus.ietf.org>; Fri, 13 Jun 2003 13:16:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13542
	for <lemonade-web-archive@ietf.org>; Fri, 13 Jun 2003 13:15:58 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Qs7b-00075L-00
	for lemonade-web-archive@ietf.org; Fri, 13 Jun 2003 13:13:51 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Qs7a-00075I-00
	for lemonade-web-archive@ietf.org; Fri, 13 Jun 2003 13:13:50 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DH95a11459;
	Fri, 13 Jun 2003 13:09:05 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DH8gm11331
	for <lemonade@optimus.ietf.org>; Fri, 13 Jun 2003 13:08:42 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13278
	for <lemonade@ietf.org>; Fri, 13 Jun 2003 13:08:38 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Qs0V-0006zV-00
	for lemonade@ietf.org; Fri, 13 Jun 2003 13:06:31 -0400
Received: from panda.com
	([206.124.149.114] helo=Ikkoku-Kan.Panda.COM ident=death)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Qs0U-0006zS-00
	for lemonade@ietf.org; Fri, 13 Jun 2003 13:06:30 -0400
Received: from localhost (mrc@localhost) by Ikkoku-Kan.Panda.COM id KAA25132; Fri, 13 Jun 2003 10:08:21 -0700 (PDT)
Date: Fri, 13 Jun 2003 10:08:20 -0700 (PDT)
From: Mark Crispin <mrc@CAC.Washington.EDU>
To: Randall Gellens <randy@qualcomm.com>
cc: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>,
        "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: Re: [lemonade] Wireless latencies
In-Reply-To: <a06001422bb0e8ea3c961@[10.61.33.218]>
Message-ID: <Pine.NXT.4.56.0306131006280.11845@Ikkoku-Kan.Panda.COM>
References: <54E40201497DF142B06B27255953F79705BFDF3D@il0015exch007u.ih.lucent.com
 > <a06001422bb0e8ea3c961@[10.61.33.218]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Thu, 12 Jun 2003, Randall Gellens wrote:
> > My measured experience using a CDMA
> > data network has an average RTT of 1200 milliseconds
> The round-trip times can vary considerably, depending on a number of
> factors, including the specific options supported by the
> infrastructure, the service options requested by the handset, the
> packet sizes, the amount of interference, etc.  However, 1200 ms
> seems quite high.  It should be more like 120-140 ms.

I have to agree.  If this is the performance of CDMA data networks, then I
think that I'll stick with CDPD!  :-)

For what it's worth, PC Pine (using full IMAP and SMTP) works quite well
over CDPD.  I use it all the time.  The only time I have a problem is when
the ferry boat makes its turn and I lose the signal...

-- 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 mailnull@www1.ietf.org  Fri Jun 13 13:17:51 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13791
	for <lemonade-archive@odin.ietf.org>; Fri, 13 Jun 2003 13:17:51 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5DHHO317575
	for lemonade-archive@odin.ietf.org; Fri, 13 Jun 2003 13:17:24 -0400
Received: from ietf.org (lists.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DHHOm17430
	for <lemonade-web-archive@optimus.ietf.org>; Fri, 13 Jun 2003 13:17:24 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13700
	for <lemonade-web-archive@ietf.org>; Fri, 13 Jun 2003 13:17:20 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Qs8v-00077L-00
	for lemonade-web-archive@ietf.org; Fri, 13 Jun 2003 13:15:13 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Qs8u-00077I-00
	for lemonade-web-archive@ietf.org; Fri, 13 Jun 2003 13:15:12 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D9u1a25926;
	Fri, 13 Jun 2003 05:56:01 -0400
Received: from ietf.org (lists.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D9tJm25899
	for <lemonade@optimus.ietf.org>; Fri, 13 Jun 2003 05:55:19 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26866
	for <lemonade@ietf.org>; Fri, 13 Jun 2003 05:55:16 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QlF7-0003GE-00
	for lemonade@ietf.org; Fri, 13 Jun 2003 05:53:09 -0400
Received: from comversegw.icomverse.com ([192.118.48.248] helo=il-tlv-smtpout2.icomverse.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19QlF5-0003GB-00
	for lemonade@ietf.org; Fri, 13 Jun 2003 05:53:08 -0400
Received: from il-tlv-mbdg1.comverse.com (localhost.localdomain [127.0.0.1])
	by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id h5D9t2K30375
	for <lemonade@ietf.org>; Fri, 13 Jun 2003 12:55:02 +0300
Received: by il-tlv-mbdg1.comverse.com with Internet Mail Service (5.5.2655.55)
	id <M2S5KQ71>; Fri, 13 Jun 2003 12:55:08 +0300
Message-ID: <E1542177268FD511866B0002A560C8080512E8D8@il-tlv-mail5.comverse.com>
From: Mendelovich Meir <Meir.Mendelovich@comverse.com>
To: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Date: Fri, 13 Jun 2003 12:55:02 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C33191.DA3485C0"
Subject: [lemonade] Mobile messaging clients barriers
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C33191.DA3485C0
Content-Type: text/plain;
	charset="windows-1255"

Hi,
 I'm very happy to see that a consensus is forming about the need to add
message submission to IMAP4.
 But, this is only one of several barriers that prevent us from building
good mobile messaging clients. I want to raise two major problems. All the
details are in section 7.1 of the requirements document that was presented
by Wong and me in San-Francisco
(http://www.ietf.org/internet-drafts/draft-wong-umcli-02.txt
<http://www.ietf.org/internet-drafts/draft-wong-umcli-02.txt> ).

1. As Alan Stebbens mentioned, server-side processing of media is crucial.
We can't download 3 mega pixel image with 30bit color depth to device that
has 100X100 pixels screen and 8bit color depth. We don't expect mail servers
to implement image processing but it is needed to allow IMAP4 servers or
mobile messaging gateways to use external transcoding engines to provide
their mobile client better experience. 
In the MMS arena it is very hot issue. OMA prepares now a standard interface
for transcoding servers.

2. It is very hard to maintain long sessions in mobile networks. The current
statefull nature of IMAP4 prevent many clients from providing good
experience. Most of the mobile handsets that has IMAP4 client open and close
new session for each command. This kind of behaviour cause enormous load on
the server and spend lots of bandwidth. We MUST solve this problem if we
want to see real mobile e-mail solution in GPRS and CDMA1X networks.

From our experience in mobile messaging clients these two problems must be
solve to fulfill the LEMONADE goals.

	Meir :->

__________________________________

Meir Mendelovich
Product Engineer
Comverse
              
Tel:     +972-3-765 5834
Cell:    +972-5854-3834
Fax:    +972-3-765 5834
E-mail: meir_m@mail.com





------_=_NextPart_001_01C33191.DA3485C0
Content-Type: text/html;
	charset="windows-1255"
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=3Dwindows-1255">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>Mobile messaging clients barriers</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;I'm very happy to see that a =
consensus is forming about the need to add message submission to =
IMAP4.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;But, this is only one of =
several barriers that prevent us from building good mobile messaging =
clients. I want to raise two major problems. All the details are in =
section 7.1 of the requirements document that was presented by Wong and =
me in San-Francisco (</FONT><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-wong-umcli-02.txt"><U>=
<FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://www.ietf.org/internet-drafts/draft-wong-umcli-02.t=
xt</FONT></U></A><FONT SIZE=3D2 FACE=3D"Arial">).</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">1. As Alan</FONT><FONT SIZE=3D2 =
FACE=3D"Arial"> Stebbens</FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">mentioned, server-side processing of media is crucial. =
We can't download 3 mega pixel image with 30bit color depth to device =
that has 100X100 pixels screen and 8bit color depth. We don't expect =
mail servers to implement image processing but it is needed to allow =
IMAP4 servers or mobile messaging gateways to use external transcoding =
engines to provide their mobile client better experience. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In the MMS arena it is very hot issue. =
OMA prepares now a standard interface for transcoding servers.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">2. It is very hard to maintain long =
sessions in mobile networks. The current statefull nature of IMAP4 =
prevent many clients from providing good experience. Most of the mobile =
handsets that has IMAP4 client open and close new session for each =
command. This kind of behaviour cause enormous load on the server and =
spend lots of bandwidth. We MUST solve this problem if we want to see =
real mobile e-mail solution in GPRS and CDMA1X networks.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">From our experience in mobile =
messaging clients these two problems must be solve to fulfill the =
LEMONADE goals.</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Meir :-&gt;</FONT>
</P>

<P><FONT COLOR=3D"#3366FF" SIZE=3D2 =
FACE=3D"Arial">__________________________________</FONT>
</P>

<P><B><FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">Meir =
Mendelovich</FONT></B>
<BR><FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">Product =
Engineer</FONT>
<BR><FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">Comverse</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;</FONT><B> </B>
<BR><B><FONT COLOR=3D"#808080" SIZE=3D2 =
FACE=3D"Arial">Tel:</FONT></B><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; </FONT><FONT COLOR=3D"#993300" =
SIZE=3D2 FACE=3D"Arial">+972-3-765 5834</FONT>
<BR><B><FONT COLOR=3D"#808080" SIZE=3D2 =
FACE=3D"Arial">Cell:</FONT><FONT SIZE=3D2 FACE=3D"Arial"></FONT></B> =
<FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; </FONT><FONT =
COLOR=3D"#993300" SIZE=3D2 FACE=3D"Arial">+972-5854-3834</FONT>
<BR><B><FONT COLOR=3D"#808080" SIZE=3D2 =
FACE=3D"Arial">Fax:</FONT></B><FONT COLOR=3D"#808080" SIZE=3D2 =
FACE=3D"Arial">&nbsp;</FONT> <FONT SIZE=3D2 FACE=3D"Arial">&nbsp; =
</FONT><FONT COLOR=3D"#993300" SIZE=3D2 FACE=3D"Arial">+972-3-765 =
5834</FONT>
<BR><B><FONT COLOR=3D"#808080" SIZE=3D2 =
FACE=3D"Arial">E-mail:</FONT></B><FONT SIZE=3D2 FACE=3D"Arial"> =
</FONT><FONT COLOR=3D"#993300" SIZE=3D2 =
FACE=3D"Arial">meir_m@mail.com</FONT>
</P>
<BR>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C33191.DA3485C0--
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Fri Jun 13 13:20:16 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13971
	for <lemonade-archive@odin.ietf.org>; Fri, 13 Jun 2003 13:20:16 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5DHJnZ16964
	for lemonade-archive@odin.ietf.org; Fri, 13 Jun 2003 13:19:49 -0400
Received: from ietf.org (lists.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DHJnm16961
	for <lemonade-web-archive@optimus.ietf.org>; Fri, 13 Jun 2003 13:19:49 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13923
	for <lemonade-web-archive@ietf.org>; Fri, 13 Jun 2003 13:19:45 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QsBG-00079q-00
	for lemonade-web-archive@ietf.org; Fri, 13 Jun 2003 13:17:38 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19QsBG-00079n-00
	for lemonade-web-archive@ietf.org; Fri, 13 Jun 2003 13:17:38 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DE71a13441;
	Fri, 13 Jun 2003 10:07:01 -0400
Received: from ietf.org (lists.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DE6vm13393
	for <lemonade@optimus.ietf.org>; Fri, 13 Jun 2003 10:06:57 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05865
	for <lemonade@ietf.org>; Fri, 13 Jun 2003 10:06:54 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QpAc-0005VB-00
	for lemonade@ietf.org; Fri, 13 Jun 2003 10:04:46 -0400
Received: from inet-consulting.com ([4.23.9.166] helo=royer.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19QpAa-0005Uw-00
	for lemonade@ietf.org; Fri, 13 Jun 2003 10:04:44 -0400
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h5DE6hbt031256
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <lemonade@ietf.org>; Fri, 13 Jun 2003 07:06:51 -0700
Message-ID: <3EE9DA68.5050106@Royer.com>
Date: Fri, 13 Jun 2003 08:06:32 -0600
From: Doug Royer <Doug@Royer.com>
Reply-To: lemonade@ietf.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: lemonade@ietf.org
Subject: Re: [lemonade] Strawman for Submit based message composition
References: <54E40201497DF142B06B27255953F79705BFE5AE@il0015exch007u.ih.lucent.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090607040605060108080707"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This is a cryptographically signed message in MIME format.

--------------ms090607040605060108080707
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Vaudreuil, Greg M (Greg) wrote:
>
> One question:  Do we believe the IMAP client needs some form of
 > confirmation at the end of the submission transaction that the
 > submission was sucessful? It seems very valuable to return a
 > sucess or detailed failure reason at submission time rather than
 > to send a complete DSN back to the senders mailbox for subsequent
 > retreival.... lots more round-trips and a degraded user experience.

It might be unavoidable.  Right now I can submit e-mail to my
smtp-host which accepts the message with minimal checking
when heavily loaded, queues it, and then later sends any
bounce message.

Plus a heavily loaded smtp-host does not respond quickly which
would hold up the reply back to the IMAP client. I think it would
be best to allow both 'queued for delivery' and 'delivered' status
codes to be returned to minimize the delay.

The 'MAIL FROM' would not need any feedback as the user is
authenticated via IMAP. The 'RCPT' could return 'valid' or
'accepted for now'. And the at the end of DATA it could
return 'delivered' or 'queued'.

As the blob of data is appended to the OUTBOX a single
return could contain the RCPT and DATA results. As
the over the air CELL transfer speed is much slower than the
interprocess communication on the server, it should not
be a problem to return the results quickly relative to
the send time after the append.

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  Doug@Royer.com                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

--------------ms090607040605060108080707
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC
A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j
cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB
MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T
BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN
VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre
qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+
5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA
MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg
TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD
QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx
ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz
IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq
hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34
1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA
gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK
YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd
SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC
AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF
BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl
cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl
IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs
MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq
1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2
TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail
MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE
AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO
b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG
MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD
VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV
BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv
43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y
lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP
D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn
0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK
bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg
hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT
IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI
AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t
L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk
OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW
yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1
MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl
ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTMxNDA2MzJaMCMGCSqGSIb3DQEJBDEWBBRS
YEsSsTDgp6MfNrsLLNVUGbfGVTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL
KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAYAl5psuT1ilo
k1Ks05iDCPQxN6gU6QBpO/ty5kPNhMoncowRTSViu1BRxJAaddZUPbHcmQQGztuiT3G2qB31
MNf2U+090kZ364bG2b6B3Hs5aIS3Of2EuqxVI6JSGSQEAunHK0M2mwQJN+HylT0QVfPqSFHo
nO36QDQ+SgPrNxy6EEd1GNIeBvKpM6avsWavD90wajLhh9uKYnjPL+r9wmnB9ejE3Gi92/jG
elTrIPUJcAchKIotkl2ZujeR2BltYnyzZ1novsFklCbZxS4QQBgvJ4rsDlh8HK92ccgFvmy6
Z5/QhZXeFBg41iY7p4clAPo81JekHbeCM9Evz/qTVQAAAAAAAA==
--------------ms090607040605060108080707--

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



From mailnull@www1.ietf.org  Fri Jun 13 14:37:17 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17411
	for <lemonade-archive@odin.ietf.org>; Fri, 13 Jun 2003 14:37:16 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5DIanK02556
	for lemonade-archive@odin.ietf.org; Fri, 13 Jun 2003 14:36:49 -0400
Received: from ietf.org (lists.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DIamm02411
	for <lemonade-web-archive@optimus.ietf.org>; Fri, 13 Jun 2003 14:36:48 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17309
	for <lemonade-web-archive@ietf.org>; Fri, 13 Jun 2003 14:36:45 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QtNl-0000Fo-00
	for lemonade-web-archive@ietf.org; Fri, 13 Jun 2003 14:34:37 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19QtNk-0000Fk-00
	for lemonade-web-archive@ietf.org; Fri, 13 Jun 2003 14:34:36 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DHW1a24403;
	Fri, 13 Jun 2003 13:32:01 -0400
Received: from ietf.org (lists.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DHVAm22481
	for <lemonade@optimus.ietf.org>; Fri, 13 Jun 2003 13:31:10 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14831
	for <lemonade@ietf.org>; Fri, 13 Jun 2003 13:31:06 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QsMF-0007QY-00
	for lemonade@ietf.org; Fri, 13 Jun 2003 13:28:59 -0400
Received: from panda.com
	([206.124.149.114] helo=Ikkoku-Kan.Panda.COM ident=fwa)
	by ietf-mx with esmtp (Exim 4.12)
	id 19QsMD-0007QV-00
	for lemonade@ietf.org; Fri, 13 Jun 2003 13:28:58 -0400
Received: from localhost (mrc@localhost) by Ikkoku-Kan.Panda.COM id KAA25153; Fri, 13 Jun 2003 10:31:04 -0700 (PDT)
Date: Fri, 13 Jun 2003 10:31:03 -0700 (PDT)
From: Mark Crispin <mrc@CAC.Washington.EDU>
To: lemonade@ietf.org
Subject: Re: [lemonade] Strawman for Submit based message composition
In-Reply-To: <3EE9DA68.5050106@Royer.com>
Message-ID: <Pine.NXT.4.56.0306131027430.11845@Ikkoku-Kan.Panda.COM>
References: <54E40201497DF142B06B27255953F79705BFE5AE@il0015exch007u.ih.lucent.com>
 <3EE9DA68.5050106@Royer.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Fri, 13 Jun 2003, Doug Royer wrote:
> The 'MAIL FROM' would not need any feedback as the user is
> authenticated via IMAP.

Since when is the MAIL FROM tied to IMAP authentication?  Are you also
going to claim that the From: header is also tied to IMAP authentication?

-- 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 mailnull@www1.ietf.org  Fri Jun 13 14:37:34 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17477
	for <lemonade-archive@odin.ietf.org>; Fri, 13 Jun 2003 14:37:34 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5DIb6A13924
	for lemonade-archive@odin.ietf.org; Fri, 13 Jun 2003 14:37:06 -0400
Received: from ietf.org (lists.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DHJZm14556
	for <lemonade-web-archive@optimus.ietf.org>; Fri, 13 Jun 2003 13:19:35 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13901
	for <lemonade-web-archive@ietf.org>; Fri, 13 Jun 2003 13:19:31 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QsB2-00079D-00
	for lemonade-web-archive@ietf.org; Fri, 13 Jun 2003 13:17:24 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19QsB2-00079A-00
	for lemonade-web-archive@ietf.org; Fri, 13 Jun 2003 13:17:24 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DEb1a15876;
	Fri, 13 Jun 2003 10:37:01 -0400
Received: from ietf.org (lists.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DEa2m15824
	for <lemonade@optimus.ietf.org>; Fri, 13 Jun 2003 10:36:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08218
	for <lemonade@ietf.org>; Fri, 13 Jun 2003 10:35:58 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Qpck-0005rj-00
	for lemonade@ietf.org; Fri, 13 Jun 2003 10:33:50 -0400
Received: from zcars0m9.nortelnetworks.com ([47.129.242.157])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Qpch-0005re-00
	for lemonade@ietf.org; Fri, 13 Jun 2003 10:33:48 -0400
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5DEZLU06156
	for <lemonade@ietf.org>; Fri, 13 Jun 2003 10:35:21 -0400 (EDT)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <KRLG1MJK>; Fri, 13 Jun 2003 10:35:22 -0400
Message-ID: <D38D073716F2D411BEE400508BCF6296052AE47D@zcard04k.ca.nortel.com>
From: "Glenn Parsons" <gparsons@nortelnetworks.com>
To: "'IETF LEMONADE'" <lemonade@ietf.org>
Date: Fri, 13 Jun 2003 10:35:19 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C331B9.02B8E6AE"
Subject: [lemonade] WG documents
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C331B9.02B8E6AE
Content-Type: text/plain;
	charset="iso-8859-1"

Folks,

Now that we have some good discussion underway on the list, I would like to
let you know what the WG documents (and the individual IDs they are based
on) that we agreed to create after the SFO meeting are.  I have also
indicated who the volunteered editors are.

I'll sort them by charter numbering:

0. LEMONADE Goals (ex Requirements) 
  - draft-lemonade-goals-xx.txt - Editor Kue Wong 
  This incorporates parts of the following individual IDs:  
	- draft-wong-umcli-02.txt 
     - draft-stebrose-mmsarch-00.txt 
     - draft-vaudreuil-um-issues-00.txt 
     - draft-burger-um-reqts-00.txt 

1. IMAP4 extensions for streaming VM playback 
	- draft-lemonade-imap-channel-xx.txt - Editor Eric Burger 
	 This incorporates parts of the following individual IDs:  
     - draft-burger-imap-chanuse-00.txt 
     - draft-nerenberg-imap-channel-01.txt 

2. IMAP4 extensions for mobile devices 
	- draft-lemonade-imap-submit-xx.txt - Editor Randall Gellens 

3. IMAP4 profile for mobile devices 
   - volunteers will be solicited in Vienna

4. Server-to-Server Notification Protocol 
	- draft-lemonade-s2s-notify-xx.txt - Editor Noam Shapira 
	This incorporates parts of the following individual IDs:  
    - draft-shapira-snap-05.txt 
        - draft-dusseault-s2s-event-reqs-00 

5. Translation to and from other messaging systems 
    - draft-lemonade-gateway-xx.txt - Editor Alan Stebbens
  This incorporates parts of the following individual IDs:  
     - draft-stebrose-mmsarch-00.txt 

The indivdual IDs that we are still tracking, but currently have no
agreement to make WG documents are 

     - draft-neystadt-imap-status-counters-00.txt 
     - draft-shveidel-mediasize-00.txt 
         - draft-vaudreuil-futuredelivery-00.txt 

Note that the deadline for submitting these documents to the Internet Drafts
editor  -- since these will all be -00 documents --is June 23rd at 9am EDT.
I will be sending pre-clearance to the IETF folks indicating the LEMONADE WG
documents.

Cheers,
Glenn.

------_=_NextPart_001_01C331B9.02B8E6AE
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>WG documents</TITLE>
</HEAD>
<BODY>

<P><FONT FACE=3D"Arial">Folks,</FONT>
</P>

<P><FONT FACE=3D"Arial">Now that we have some good discussion underway =
on the list, I would like to let you know what the WG documents (and =
the individual IDs they are based on) that we agreed to create after =
the SFO meeting are.&nbsp; I have also indicated who the volunteered =
editors are.</FONT></P>

<P><FONT FACE=3D"Arial">I'll sort them by charter numbering:</FONT>
</P>

<P><B><FONT FACE=3D"Arial">0. LEMONADE Goals (ex =
Requirements)</FONT></B>=20
<BR><FONT FACE=3D"Arial">&nbsp; - draft-lemonade-goals-xx.txt =
-</FONT><I><FONT FACE=3D"Arial"> Editor Kue Wong</FONT></I><FONT =
FACE=3D"Arial"> </FONT>
<BR><FONT FACE=3D"Courier New">=A0=A0This incorporates parts of the =
following=A0individual IDs:=A0 </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT FACE=3D"Courier =
New">- draft-wong-umcli-02.txt</FONT><FONT FACE=3D"Arial"> </FONT>
<BR><FONT FACE=3D"Courier New">=A0=A0=A0=A0 - =
draft-stebrose-mmsarch-00.txt</FONT><FONT FACE=3D"Arial"> </FONT>
<BR><FONT FACE=3D"Courier New">=A0=A0=A0=A0 - =
draft-vaudreuil-um-issues-00.txt</FONT><FONT FACE=3D"Arial"> </FONT>
<BR><FONT FACE=3D"Courier New">=A0=A0=A0=A0 - =
draft-burger-um-reqts-00.txt</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P><B><FONT FACE=3D"Arial">1. IMAP4 extensions for streaming VM =
playback</FONT></B>=20
<UL>
<P><FONT FACE=3D"Arial">- draft-lemonade-imap-channel-xx.txt =
-</FONT><I><FONT FACE=3D"Arial"> Editor Eric Burger</FONT></I><FONT =
FACE=3D"Arial"> </FONT>
<BR><FONT FACE=3D"Courier New">&nbsp;This incorporates parts of the =
following=A0individual IDs:=A0</FONT>=20
</UL>
<P><FONT FACE=3D"Courier New">=A0=A0=A0=A0 - =
draft-burger-imap-chanuse-00.txt</FONT><FONT FACE=3D"Arial"> </FONT>
<BR><FONT FACE=3D"Courier New">=A0=A0=A0=A0 - =
draft-nerenberg-imap-channel-01.txt</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P><B><FONT FACE=3D"Arial">2. IMAP4 extensions for mobile =
devices</FONT></B>=20
<UL>
<P><FONT FACE=3D"Arial">- draft-lemonade-imap-submit-xx.txt =
-</FONT><I><FONT FACE=3D"Arial"> Editor Randall Gellens</FONT></I><FONT =
FACE=3D"Arial"> </FONT>
</P>
</UL>
<P><B><FONT FACE=3D"Arial">3. IMAP4 profile for mobile =
devices</FONT></B>=20
<BR><I><FONT FACE=3D"Arial">&nbsp;&nbsp; - volunteers will be solicited =
in Vienna</FONT></I>
</P>

<P><B><FONT FACE=3D"Arial">4. Server-to-Server Notification =
Protocol</FONT></B>=20
<UL>
<P><FONT FACE=3D"Arial">- draft-lemonade-s2s-notify-xx.txt =
-</FONT><I><FONT FACE=3D"Arial"> Editor Noam Shapira</FONT></I><FONT =
FACE=3D"Arial"> </FONT>
<BR><FONT FACE=3D"Courier New">This incorporates parts of the =
following=A0individual IDs:=A0</FONT>=20
</UL>
<P><FONT FACE=3D"Courier New">=A0=A0=A0 - =
draft-shapira-snap-05.txt</FONT><FONT FACE=3D"Arial"> </FONT>
<BR><FONT FACE=3D"Arial">=A0=A0=A0=A0=A0=A0=A0</FONT><FONT =
FACE=3D"Courier New"> - draft-dusseault-s2s-event-reqs-00</FONT><FONT =
FACE=3D"Arial"> </FONT>
</P>

<P><B><FONT FACE=3D"Arial">5. Translation to and from other messaging =
systems</FONT></B>=20
<BR><FONT FACE=3D"Arial">&nbsp;&nbsp;&nbsp; - =
draft-lemonade-gateway-xx.txt -</FONT><I><FONT FACE=3D"Arial"> Editor =
Alan Stebbens</FONT></I>
<BR><FONT FACE=3D"Courier New">=A0=A0This incorporates parts of the =
following=A0individual IDs:=A0 </FONT>
<BR><FONT FACE=3D"Courier New">=A0=A0=A0=A0 - =
draft-stebrose-mmsarch-00.txt</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The indivdual IDs that we are still =
tracking, but currently have no agreement to make WG documents are =
</FONT>
</P>

<P><FONT FACE=3D"Courier New">=A0=A0=A0=A0 - =
draft-neystadt-imap-status-counters-00.txt</FONT><FONT FACE=3D"Arial"> =
</FONT>
<BR><FONT FACE=3D"Courier New">=A0=A0=A0=A0 - =
draft-shveidel-mediasize-00.txt</FONT><FONT FACE=3D"Arial"> </FONT>
<BR><FONT FACE=3D"Arial">=A0=A0=A0=A0=A0=A0=A0=A0</FONT><FONT =
FACE=3D"Courier New"> - =
draft-vaudreuil-futuredelivery-00.txt</FONT><FONT FACE=3D"Arial"> =
</FONT>
</P>

<P><FONT FACE=3D"Arial">Note that the deadline for submitting these =
documents to the Internet Drafts editor&nbsp; -- since these will all =
be -00 documents --is June 23rd at 9am EDT.&nbsp; I will be sending =
pre-clearance to the IETF folks indicating the LEMONADE WG =
documents.</FONT></P>

<P><FONT FACE=3D"Arial">Cheers,</FONT>
<BR><FONT FACE=3D"Arial">Glenn.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C331B9.02B8E6AE--
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Fri Jun 13 14:38:10 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17703
	for <lemonade-archive@odin.ietf.org>; Fri, 13 Jun 2003 14:38:10 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5DIbgV04485
	for lemonade-archive@odin.ietf.org; Fri, 13 Jun 2003 14:37:42 -0400
Received: from ietf.org (lists.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DIbem03815
	for <lemonade-web-archive@optimus.ietf.org>; Fri, 13 Jun 2003 14:37:40 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17528
	for <lemonade-web-archive@ietf.org>; Fri, 13 Jun 2003 14:37:36 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QtOZ-0000HM-00
	for lemonade-web-archive@ietf.org; Fri, 13 Jun 2003 14:35:27 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19QtOY-0000HI-00
	for lemonade-web-archive@ietf.org; Fri, 13 Jun 2003 14:35:26 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DIbNa25482;
	Fri, 13 Jun 2003 14:37:23 -0400
Received: from ietf.org (lists.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DIaam27652
	for <lemonade@optimus.ietf.org>; Fri, 13 Jun 2003 14:36:36 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17290
	for <lemonade@ietf.org>; Fri, 13 Jun 2003 14:36:33 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QtNY-0000Ev-00
	for lemonade@ietf.org; Fri, 13 Jun 2003 14:34:24 -0400
Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19QtNY-0000Dz-00
	for lemonade@ietf.org; Fri, 13 Jun 2003 14:34:24 -0400
Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83])
	by ihemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h5DIZxP17286
	for <lemonade@ietf.org>; Fri, 13 Jun 2003 13:36:00 -0500 (CDT)
Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19)
	id <L2XMH8G6>; Fri, 13 Jun 2003 13:35:59 -0500
Message-ID: <54E40201497DF142B06B27255953F79705CC833B@il0015exch007u.ih.lucent.com>
From: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
To: Mark Crispin <mrc@CAC.Washington.EDU>,
        Randall Gellens
	 <randy@qualcomm.com>
Cc: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>,
        "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: RE: [lemonade] Wireless latencies
Date: Fri, 13 Jun 2003 13:35:58 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

OK, I have run a different test, skipping my corporate network gunk... maybe something about back-to-back modems.

Using my LG CDMA phone (qualcomm chipset) on the Verizon 1xRTT network using the 14.4 data channel (not the high-speed data) and pinging the first router after the wireless link with 100 byte packets, over 100 samples, I measured a high of 598, a low of 441, and an average of 532 milliseconds.  This was with "five bars" of signal strength.

End-to-end round-trips to the likes of a www.yahoo.com site are some 60 ms or so higher.

Greg V.



-----Original Message-----
From: Mark Crispin [mailto:mrc@CAC.Washington.EDU]
Sent: Friday, June 13, 2003 12:08 PM
To: Randall Gellens
Cc: Vaudreuil, Greg M (Greg); IETF LEMONADE (E-mail)
Subject: Re: [lemonade] Wireless latencies


On Thu, 12 Jun 2003, Randall Gellens wrote:
> > My measured experience using a CDMA
> > data network has an average RTT of 1200 milliseconds
> The round-trip times can vary considerably, depending on a number of
> factors, including the specific options supported by the
> infrastructure, the service options requested by the handset, the
> packet sizes, the amount of interference, etc.  However, 1200 ms
> seems quite high.  It should be more like 120-140 ms.

I have to agree.  If this is the performance of CDMA data networks, then I
think that I'll stick with CDPD!  :-)

For what it's worth, PC Pine (using full IMAP and SMTP) works quite well
over CDPD.  I use it all the time.  The only time I have a problem is when
the ferry boat makes its turn and I lose the signal...

-- 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 mailnull@www1.ietf.org  Fri Jun 13 15:26:24 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17483
	for <lemonade-archive@odin.ietf.org>; Fri, 13 Jun 2003 14:37:34 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5DIb6f13984
	for lemonade-archive@odin.ietf.org; Fri, 13 Jun 2003 14:37:06 -0400
Received: from ietf.org (lists.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DHJjm16774
	for <lemonade-web-archive@optimus.ietf.org>; Fri, 13 Jun 2003 13:19:45 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13920
	for <lemonade-web-archive@ietf.org>; Fri, 13 Jun 2003 13:19:42 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QsBC-00079k-00
	for lemonade-web-archive@ietf.org; Fri, 13 Jun 2003 13:17:34 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19QsBC-00079h-00
	for lemonade-web-archive@ietf.org; Fri, 13 Jun 2003 13:17:34 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DDn0a12303;
	Fri, 13 Jun 2003 09:49:00 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DDmCm12272
	for <lemonade@optimus.ietf.org>; Fri, 13 Jun 2003 09:48:12 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05076
	for <lemonade@ietf.org>; Fri, 13 Jun 2003 09:48:10 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QosU-0005Mu-00
	for lemonade@ietf.org; Fri, 13 Jun 2003 09:46:02 -0400
Received: from inet-consulting.com ([4.23.9.166] helo=royer.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19QosS-0005Mr-00
	for lemonade@ietf.org; Fri, 13 Jun 2003 09:46:01 -0400
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h5DDlxbt031103
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <lemonade@ietf.org>; Fri, 13 Jun 2003 06:48:07 -0700
Message-ID: <3EE9D5F6.1010709@Royer.com>
Date: Fri, 13 Jun 2003 07:47:34 -0600
From: Doug Royer <Doug@Royer.com>
Reply-To: lemonade@ietf.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: lemonade@ietf.org
Subject: Re: [lemonade] Strawman for Submit based message composition
References: <4697F932-9C9A-11D7-A10F-000393D34A62@orthanc.ab.ca>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060406040703090805080308"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This is a cryptographically signed message in MIME format.

--------------ms060406040703090805080308
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Lyndon Nerenberg wrote:
> 
> On Wednesday, June 11, 2003, at 11:38  PM, Alan K. Stebbens wrote:
> 
>> The "X-Env-From:" and "X-Env-To:" headers would carry the MAIL and RCPT
>> information, and would be removed from the message transmitted over 
>> the SMTP
>> connection.
> 
> 
> The problem here is you will always have a namespace collision (however 
> unlikely).
> 
> One way around this would be to submit the entire thing as an 
> application/batch-smtp.


Or to register some pre-defined headers that do not start with 'x-'.

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  Doug@Royer.com                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

--------------ms060406040703090805080308
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC
A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j
cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB
MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T
BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN
VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre
qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+
5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA
MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg
TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD
QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx
ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz
IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq
hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34
1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA
gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK
YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd
SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC
AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF
BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl
cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl
IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs
MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq
1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2
TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail
MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE
AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO
b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG
MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD
VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV
BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv
43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y
lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP
D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn
0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK
bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg
hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT
IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI
AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t
L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk
OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW
yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1
MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl
ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTMxMzQ3MzRaMCMGCSqGSIb3DQEJBDEWBBQY
JuArhgjiqCQuLHyMCpaYxRiYqzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL
KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAUMNhLQfIW8OY
IgxdLRVRR7w9l6Y36f1ICGn1s8ITOgyWkO4ctkeGAc8unkVClHnshFJi8uRUvSq1hCiJjIPH
YFTEcTtkiToJ2+5Ez3u6NlYN67XzmKpuGeM+NkUlYJ/7GTBKCfvYw3aM6wIlusEfCzQ3qaQX
9BKX8b9ewXLB/7MRiwK09+/qM5WwUPnS9aUcoMdoZq8CELRQ05go+ArmRKLz02txwQrNGkh8
93bKYMV99qPb12WZxj9b5IIF7ntHrqTfAwfmTk949P9PYALIoxI2et4nrsDYBOyF+SBNJGvj
W6XnjWV8QAUl3r/242W1nCn9HjvRIre+PLjyioVSSwAAAAAAAA==
--------------ms060406040703090805080308--

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



From mailnull@www1.ietf.org  Fri Jun 13 22:37:46 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02912
	for <lemonade-archive@odin.ietf.org>; Fri, 13 Jun 2003 22:37:46 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5E2bJo13222
	for lemonade-archive@odin.ietf.org; Fri, 13 Jun 2003 22:37:19 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5E2bFm13212
	for <lemonade-web-archive@optimus.ietf.org>; Fri, 13 Jun 2003 22:37:15 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02892
	for <lemonade-web-archive@ietf.org>; Fri, 13 Jun 2003 22:37:11 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19R0sg-0003QP-00
	for lemonade-web-archive@ietf.org; Fri, 13 Jun 2003 22:35:02 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19R0sg-0003QM-00
	for lemonade-web-archive@ietf.org; Fri, 13 Jun 2003 22:35:02 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DKj0a16788;
	Fri, 13 Jun 2003 16:45:00 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DKism16765
	for <lemonade@optimus.ietf.org>; Fri, 13 Jun 2003 16:44:54 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22468
	for <lemonade@ietf.org>; Fri, 13 Jun 2003 16:44:51 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QvNj-00016A-00
	for lemonade@ietf.org; Fri, 13 Jun 2003 16:42:43 -0400
Received: from mxout5.cac.washington.edu ([140.142.32.135])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QvNi-000167-00
	for lemonade@ietf.org; Fri, 13 Jun 2003 16:42:42 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9])
	by mxout5.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h5DKioGb016980;
	Fri, 13 Jun 2003 13:44:50 -0700
Received: from Shimo-Tomobiki.Panda.COM (mes128085095.airdata.net [166.128.85.95])
	(authenticated bits=0)
	by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h5DKhV3n019843
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Fri, 13 Jun 2003 13:44:44 -0700
Date: Fri, 13 Jun 2003 13:43:35 -0700 (Pacific Daylight Time)
From: Mark Crispin <MRC@CAC.Washington.EDU>
To: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
cc: Randall Gellens <randy@qualcomm.com>,
        "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: RE: [lemonade] Wireless latencies
In-Reply-To: <54E40201497DF142B06B27255953F79705CC833B@il0015exch007u.ih.lucent.com>
Message-ID: <Pine.WNT.4.60.0306131335420.4024@Shimo-Tomobiki.Panda.COM>
References: <54E40201497DF142B06B27255953F79705CC833B@il0015exch007u.ih.lucent.com>
Organization: Networks & Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Fri, 13 Jun 2003, Vaudreuil, Greg M (Greg) wrote:
> Using my LG CDMA phone (qualcomm chipset) on the Verizon 1xRTT network
> using the 14.4 data channel (not the high-speed data) and pinging the
> first router after the wireless link with 100 byte packets, over 100
> samples, I measured a high of 598, a low of 441, and an average of 532
> milliseconds.  This was with "five bars" of signal strength.
> End-to-end round-trips to the likes of a www.yahoo.com site are some 60
> ms or so higher.

I averaged 516ms (min of 455ms, max of 756ms but I think Pine may have
been doing a NOOP over IMAP at that time) pinging www.yahoo.com with 100
byte packets via CDPD from a ferry boat (not optimal characteristics...).
This suggests that something is wrong with your CDMA facility for you to
be getting 75ms worse with a full-strength connection, especially since
CDMA is superior technology.

Of course, at 14.4 it isn't unreasonable see a few hundred ms of ping
times for 100 byte packets.

-- 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 mailnull@www1.ietf.org  Fri Jun 13 23:39:41 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04403
	for <lemonade-archive@odin.ietf.org>; Fri, 13 Jun 2003 23:39:41 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5E3dBa17844
	for lemonade-archive@odin.ietf.org; Fri, 13 Jun 2003 23:39:11 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5E3d7m17840
	for <lemonade-web-archive@optimus.ietf.org>; Fri, 13 Jun 2003 23:39:07 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04397
	for <lemonade-web-archive@ietf.org>; Fri, 13 Jun 2003 23:39:02 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19R1qX-0003ob-00
	for lemonade-web-archive@ietf.org; Fri, 13 Jun 2003 23:36:53 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19R1qX-0003oX-00
	for lemonade-web-archive@ietf.org; Fri, 13 Jun 2003 23:36:53 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5E2x0a14675;
	Fri, 13 Jun 2003 22:59:00 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5E2wrm14662
	for <lemonade@optimus.ietf.org>; Fri, 13 Jun 2003 22:58:53 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03170
	for <lemonade@ietf.org>; Fri, 13 Jun 2003 22:58:48 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19R1Db-0003UR-00
	for lemonade@ietf.org; Fri, 13 Jun 2003 22:56:39 -0400
Received: from joy.songbird.com ([208.184.79.7])
	by ietf-mx with esmtp (Exim 4.12)
	id 19R1Db-0003UA-00
	for lemonade@ietf.org; Fri, 13 Jun 2003 22:56:39 -0400
Received: from bbprime (jay.songbird.com [208.184.79.253])
	by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h5E31EF04955;
	Fri, 13 Jun 2003 20:01:14 -0700
Date: Fri, 13 Jun 2003 19:58:08 -0700
From: Dave Crocker <dcrocker@brandenburg.com>
X-Mailer: The Bat! (v1.63 Beta/10) Personal
Organization: Brandenburg InternetWorking
X-Priority: 3 (Normal)
Message-ID: <6240300028.20030613195808@brandenburg.com>
To: Pete Resnick <presnick@qualcomm.com>
CC: Mark Crispin <mrc@CAC.Washington.EDU>,
        "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>,
        "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: Re: [lemonade] Call for requirement consensus
In-Reply-To: <p06001425bb0d39b644d8@[216\.43\.25\.67]>
References: 
 <54E40201497DF142B06B27255953F79705BFDF0B@il0015exch007u.ih.lucent.com>
 <Pine.NXT.4.56.0306111008100.11845@Ikkoku-Kan.Panda.COM>
 <p06001425bb0d39b644d8@[216.43.25.67]>
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

ditto.

d/


>>In other words, it is a requirement that there be a basic forward of 
>>message or atomic message part without download.  Precise mechanism 
>>to be determined.

PR> Something with which I wholeheartedly agree.


--
 Dave Crocker <mailto:dcrocker@brandenburg.com>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

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



From mailnull@www1.ietf.org  Sat Jun 14 01:04:11 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06580
	for <lemonade-archive@odin.ietf.org>; Sat, 14 Jun 2003 01:04:11 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5E53gH22450
	for lemonade-archive@odin.ietf.org; Sat, 14 Jun 2003 01:03:42 -0400
Received: from ietf.org (lists.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5E53gm22447
	for <lemonade-web-archive@optimus.ietf.org>; Sat, 14 Jun 2003 01:03:42 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06570
	for <lemonade-web-archive@ietf.org>; Sat, 14 Jun 2003 01:03:41 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19R3AQ-0004FG-00
	for lemonade-web-archive@ietf.org; Sat, 14 Jun 2003 01:01:30 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19R3AQ-0004FD-00
	for lemonade-web-archive@ietf.org; Sat, 14 Jun 2003 01:01:30 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DJ51a26464;
	Fri, 13 Jun 2003 15:05:01 -0400
Received: from ietf.org (lists.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DJ50m26443
	for <lemonade@optimus.ietf.org>; Fri, 13 Jun 2003 15:05:00 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19021
	for <lemonade@ietf.org>; Fri, 13 Jun 2003 15:04:57 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Qtp2-0000XL-00
	for lemonade@ietf.org; Fri, 13 Jun 2003 15:02:48 -0400
Received: from inet-consulting.com ([4.23.9.166] helo=royer.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Qtp0-0000XI-00
	for lemonade@ietf.org; Fri, 13 Jun 2003 15:02:47 -0400
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h5DJ4kbt001877
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <lemonade@ietf.org>; Fri, 13 Jun 2003 12:04:54 -0700
Message-ID: <3EEA2048.5010603@Royer.com>
Date: Fri, 13 Jun 2003 13:04:40 -0600
From: Doug Royer <Doug@Royer.com>
Reply-To: lemonade@ietf.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: lemonade@ietf.org
Subject: Re: [lemonade] Strawman for Submit based message composition
References: <54E40201497DF142B06B27255953F79705BFE5AE@il0015exch007u.ih.lucent.com> <3EE9DA68.5050106@Royer.com> <Pine.NXT.4.56.0306131027430.11845@Ikkoku-Kan.Panda.COM>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070301030600070004040200"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This is a cryptographically signed message in MIME format.

--------------ms070301030600070004040200
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Mark Crispin wrote:
> On Fri, 13 Jun 2003, Doug Royer wrote:
> 
>>The 'MAIL FROM' would not need any feedback as the user is
>>authenticated via IMAP.
> 
> 
> Since when is the MAIL FROM tied to IMAP authentication? 

In the context of the email I replied to.

>Are you also
> going to claim that the From: header is also tied to IMAP authentication?

Are you claming I said that?


-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  Doug@Royer.com                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

--------------ms070301030600070004040200
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC
A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j
cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB
MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T
BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN
VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre
qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+
5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA
MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg
TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD
QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx
ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz
IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq
hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34
1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA
gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK
YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd
SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC
AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF
BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl
cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl
IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs
MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq
1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2
TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail
MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE
AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO
b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG
MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD
VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV
BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv
43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y
lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP
D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn
0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK
bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg
hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT
IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI
AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t
L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk
OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW
yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1
MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl
ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTMxOTA0NDBaMCMGCSqGSIb3DQEJBDEWBBQV
7qlD4m/jpCOZ5FvMSnCRlDlCUzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL
KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAcS9ik5nZCNO/
yZJdf1iLkUGVPYTs53oCPqEfVT9Go7164P+Xw8Ll6lamjAmnTkpZceV4IafyHkMUZIH8Luw1
nabXJ8tHsfFGwtTQVD9uu7rgOVS3rkLliuEx9nfwKbPUWsk6o3e0PXDLPqEnwXgkmHGVdrQm
R9mpPSZS2wWfgVvhlFc1QkHBlsobEgKu7qul0/ZmLLb7Q7QIG0yP93iTWx8WMUsmFuf3dN0D
od/69BxdmqrAhYnHmTQIojL7D7a/NIAmey3M8AYpiUyP/nB10CWbfvVkd4J6pK1BE2jYxZPn
Sp/gP08+GbgjaaUau9USBFDNE/2L8eYbqkrtZy2a2wAAAAAAAA==
--------------ms070301030600070004040200--

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



From mailnull@www1.ietf.org  Sat Jun 14 01:45:11 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07305
	for <lemonade-archive@odin.ietf.org>; Sat, 14 Jun 2003 01:45:10 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5E5ig625823
	for lemonade-archive@odin.ietf.org; Sat, 14 Jun 2003 01:44:42 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5E5igm25820
	for <lemonade-web-archive@optimus.ietf.org>; Sat, 14 Jun 2003 01:44:42 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07299
	for <lemonade-web-archive@ietf.org>; Sat, 14 Jun 2003 01:44:40 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19R3o6-0004ST-00
	for lemonade-web-archive@ietf.org; Sat, 14 Jun 2003 01:42:30 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19R3o5-0004SQ-00
	for lemonade-web-archive@ietf.org; Sat, 14 Jun 2003 01:42:29 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DK01a09098;
	Fri, 13 Jun 2003 16:00:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DJxqm09058
	for <lemonade@optimus.ietf.org>; Fri, 13 Jun 2003 15:59:52 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21324
	for <lemonade@ietf.org>; Fri, 13 Jun 2003 15:59:50 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QugA-0000oL-00
	for lemonade@ietf.org; Fri, 13 Jun 2003 15:57:42 -0400
Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Qug9-0000oF-00
	for lemonade@ietf.org; Fri, 13 Jun 2003 15:57:41 -0400
Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83])
	by ihemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h5DJxIt16709
	for <lemonade@ietf.org>; Fri, 13 Jun 2003 14:59:18 -0500 (CDT)
Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19)
	id <L2XM2FA5>; Fri, 13 Jun 2003 14:59:17 -0500
Message-ID: <54E40201497DF142B06B27255953F797AC21EB@il0015exch007u.ih.lucent.com>
From: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
To: "'Mendelovich Meir'" <Meir.Mendelovich@comverse.com>,
        "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: RE: [lemonade] Mobile messaging clients barriers
Date: Fri, 13 Jun 2003 14:59:10 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C331E5.63719208"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C331E5.63719208
Content-Type: text/plain;
	charset="windows-1255"

It sounds like you are asking for an IMAP "session" to extend across multiple short-lived TCP connections?   Can you elaborate on why leaving the TCP connection open is a burden for the client.... is it that a wireless circuit must be maintained?  The cost of the TCP keep-alives?    
 
If the desire is to reduce the cost of "checking messages" over a circuit data session, then something like a suspend command that would return from the server a session token would be useful.  A new message-checking action could rapid-start with this token as a means to access the last shared state.... maybe check for new messages in just 3-4 round-trips.
 
Greg V.
 
-----Original Message-----
From: Mendelovich Meir [mailto:Meir.Mendelovich@comverse.com]
Sent: Friday, June 13, 2003 4:55 AM
To: IETF LEMONADE (E-mail)
Subject: [lemonade] Mobile messaging clients barriers



Hi, 
 I'm very happy to see that a consensus is forming about the need to add message submission to IMAP4. 
 But, this is only one of several barriers that prevent us from building good mobile messaging clients. I want to raise two major problems. All the details are in section 7.1 of the requirements document that was presented by Wong and me in San-Francisco (  <http://www.ietf.org/internet-drafts/draft-wong-umcli-02.txt> http://www.ietf.org/internet-drafts/draft-wong-umcli-02.txt).

1. As Alan Stebbens mentioned, server-side processing of media is crucial. We can't download 3 mega pixel image with 30bit color depth to device that has 100X100 pixels screen and 8bit color depth. We don't expect mail servers to implement image processing but it is needed to allow IMAP4 servers or mobile messaging gateways to use external transcoding engines to provide their mobile client better experience. 

In the MMS arena it is very hot issue. OMA prepares now a standard interface for transcoding servers. 

2. It is very hard to maintain long sessions in mobile networks. The current statefull nature of IMAP4 prevent many clients from providing good experience. Most of the mobile handsets that has IMAP4 client open and close new session for each command. This kind of behaviour cause enormous load on the server and spend lots of bandwidth. We MUST solve this problem if we want to see real mobile e-mail solution in GPRS and CDMA1X networks.

From our experience in mobile messaging clients these two problems must be solve to fulfill the LEMONADE goals. 

        Meir :-> 

__________________________________ 

Meir Mendelovich 
Product Engineer 
Comverse 
              
Tel:     +972-3-765 5834 
Cell:    +972-5854-3834 
Fax:    +972-3-765 5834 
E-mail: meir_m@mail.com 





------_=_NextPart_001_01C331E5.63719208
Content-Type: text/html;
	charset="windows-1255"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1255">
<TITLE>Mobile messaging clients barriers</TITLE>

<META content="MSHTML 5.50.4919.2200" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=740565219-13062003><FONT face=Arial color=#0000ff size=2>It 
sounds like you are asking for&nbsp;an IMAP "session"&nbsp;to extend across 
multiple short-lived TCP connections?&nbsp;&nbsp; </FONT></SPAN><SPAN 
class=740565219-13062003><FONT face=Arial color=#0000ff size=2>Can you elaborate 
on why leaving the TCP connection open is a burden for the client.... is it that 
a wireless circuit must be maintained?&nbsp; The cost of the TCP 
keep-alives?&nbsp;&nbsp;&nbsp; </FONT></SPAN></DIV>
<DIV><SPAN class=740565219-13062003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=740565219-13062003><FONT face=Arial color=#0000ff size=2>If the 
desire is to reduce the cost of "checking messages" over a circuit data session, 
then something like a suspend command that would return from the server a 
session token would be useful.&nbsp; A new message-checking action could 
rapid-start with this token as a means to access the last shared state.... maybe 
check for new messages in just 3-4 round-trips.</FONT></SPAN></DIV>
<DIV><SPAN class=740565219-13062003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=740565219-13062003><FONT face=Arial color=#0000ff size=2>Greg 
V.</FONT></SPAN></DIV>
<DIV><SPAN class=740565219-13062003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=740565219-13062003></SPAN><FONT face=Tahoma 
size=2>-----Original Message-----<BR><B>From:</B> Mendelovich Meir 
[mailto:Meir.Mendelovich@comverse.com]<BR><B>Sent:</B> Friday, June 13, 2003 
4:55 AM<BR><B>To:</B> IETF LEMONADE (E-mail)<BR><B>Subject:</B> [lemonade] 
Mobile messaging clients barriers<BR><BR></DIV></FONT>
<BLOCKQUOTE>
  <P><FONT face=Arial size=2>Hi,</FONT> <BR><FONT face=Arial size=2>&nbsp;I'm 
  very happy to see that a consensus is forming about the need to add message 
  submission to IMAP4.</FONT> <BR><FONT face=Arial size=2>&nbsp;But, this is 
  only one of several barriers that prevent us from building good mobile 
  messaging clients. I want to raise two major problems. All the details are in 
  section 7.1 of the requirements document that was presented by Wong and me in 
  San-Francisco (</FONT><A 
  href="http://www.ietf.org/internet-drafts/draft-wong-umcli-02.txt"><U><FONT 
  face=Arial color=#0000ff 
  size=2>http://www.ietf.org/internet-drafts/draft-wong-umcli-02.txt</FONT></U></A><FONT 
  face=Arial size=2>).</FONT></P>
  <P><FONT face=Arial size=2>1. As Alan</FONT><FONT face=Arial size=2> 
  Stebbens</FONT> <FONT face=Arial size=2>mentioned, server-side processing of 
  media is crucial. We can't download 3 mega pixel image with 30bit color depth 
  to device that has 100X100 pixels screen and 8bit color depth. We don't expect 
  mail servers to implement image processing but it is needed to allow IMAP4 
  servers or mobile messaging gateways to use external transcoding engines to 
  provide their mobile client better experience. </FONT></P>
  <P><FONT face=Arial size=2>In the MMS arena it is very hot issue. OMA prepares 
  now a standard interface for transcoding servers.</FONT> </P>
  <P><FONT face=Arial size=2>2. It is very hard to maintain long sessions in 
  mobile networks. The current statefull nature of IMAP4 prevent many clients 
  from providing good experience. Most of the mobile handsets that has IMAP4 
  client open and close new session for each command. This kind of behaviour 
  cause enormous load on the server and spend lots of bandwidth. We MUST solve 
  this problem if we want to see real mobile e-mail solution in GPRS and CDMA1X 
  networks.</FONT></P>
  <P><FONT face=Arial size=2>From our experience in mobile messaging clients 
  these two problems must be solve to fulfill the LEMONADE goals.</FONT> </P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial size=2>Meir 
  :-&gt;</FONT> </P>
  <P><FONT face=Arial color=#3366ff 
  size=2>__________________________________</FONT> </P>
  <P><B><FONT face=Arial color=#000080 size=2>Meir Mendelovich</FONT></B> 
  <BR><FONT face=Arial color=#000080 size=2>Product Engineer</FONT> <BR><FONT 
  face=Arial color=#000080 size=2>Comverse</FONT> <BR><FONT face=Arial 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT><B> 
  </B><BR><B><FONT face=Arial color=#808080 size=2>Tel:</FONT></B><FONT 
  face=Arial size=2>&nbsp;&nbsp;&nbsp;&nbsp; </FONT><FONT face=Arial 
  color=#993300 size=2>+972-3-765 5834</FONT> <BR><B><FONT face=Arial 
  color=#808080 size=2>Cell:</FONT><FONT face=Arial size=2></FONT></B> <FONT 
  face=Arial size=2>&nbsp;&nbsp; </FONT><FONT face=Arial color=#993300 
  size=2>+972-5854-3834</FONT> <BR><B><FONT face=Arial color=#808080 
  size=2>Fax:</FONT></B><FONT face=Arial color=#808080 size=2>&nbsp;</FONT> 
  <FONT face=Arial size=2>&nbsp; </FONT><FONT face=Arial color=#993300 
  size=2>+972-3-765 5834</FONT> <BR><B><FONT face=Arial color=#808080 
  size=2>E-mail:</FONT></B><FONT face=Arial size=2> </FONT><FONT face=Arial 
  color=#993300 size=2>meir_m@mail.com</FONT> 
</P><BR><BR><BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C331E5.63719208--
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Sat Jun 14 03:06:43 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20755
	for <lemonade-archive@odin.ietf.org>; Sat, 14 Jun 2003 03:06:43 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5E76F710460
	for lemonade-archive@odin.ietf.org; Sat, 14 Jun 2003 03:06:15 -0400
Received: from ietf.org (lists.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5E76Fm10457
	for <lemonade-web-archive@optimus.ietf.org>; Sat, 14 Jun 2003 03:06:15 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20749
	for <lemonade-web-archive@ietf.org>; Sat, 14 Jun 2003 03:06:12 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19R550-0005Am-00
	for lemonade-web-archive@ietf.org; Sat, 14 Jun 2003 03:04:02 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19R550-0005Aj-00
	for lemonade-web-archive@ietf.org; Sat, 14 Jun 2003 03:04:02 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5E5Q0a24095;
	Sat, 14 Jun 2003 01:26:00 -0400
Received: from ietf.org (lists.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5E5P2m24028
	for <lemonade@optimus.ietf.org>; Sat, 14 Jun 2003 01:25:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07126
	for <lemonade@ietf.org>; Sat, 14 Jun 2003 01:25:00 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19R3V4-0004PF-00
	for lemonade@ietf.org; Sat, 14 Jun 2003 01:22:50 -0400
Received: from panda.com
	([206.124.149.114] helo=Ikkoku-Kan.Panda.COM ident=weiner)
	by ietf-mx with esmtp (Exim 4.12)
	id 19R3V3-0004PC-00
	for lemonade@ietf.org; Sat, 14 Jun 2003 01:22:49 -0400
Received: from localhost (mrc@localhost) by Ikkoku-Kan.Panda.COM id WAA25890; Fri, 13 Jun 2003 22:24:57 -0700 (PDT)
Date: Fri, 13 Jun 2003 22:24:56 -0700 (PDT)
From: Mark Crispin <mrc@CAC.Washington.EDU>
To: lemonade@ietf.org
Subject: Re: [lemonade] Strawman for Submit based message composition
In-Reply-To: <3EEA2048.5010603@Royer.com>
Message-ID: <Pine.NXT.4.56.0306132222450.11845@Ikkoku-Kan.Panda.COM>
References: <54E40201497DF142B06B27255953F79705BFE5AE@il0015exch007u.ih.lucent.com>
 <3EE9DA68.5050106@Royer.com> <Pine.NXT.4.56.0306131027430.11845@Ikkoku-Kan.Panda.COM>
 <3EEA2048.5010603@Royer.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Fri, 13 Jun 2003, Doug Royer wrote:
> > Since when is the MAIL FROM tied to IMAP authentication?
> In the context of the email I replied to.

Why is the SMTP return-path tied to IMAP authentication?

> >Are you also
> > going to claim that the From: header is also tied to IMAP authentication?
> Are you claming I said that?

Why is the SMTP return-path is tied to IMAP authentication but the From:
header is not?

-- 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 mailnull@www1.ietf.org  Sat Jun 14 11:36:06 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27914
	for <lemonade-archive@odin.ietf.org>; Sat, 14 Jun 2003 11:36:05 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5EFZbK07381
	for lemonade-archive@odin.ietf.org; Sat, 14 Jun 2003 11:35:37 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5EFZbm07378
	for <lemonade-web-archive@optimus.ietf.org>; Sat, 14 Jun 2003 11:35:37 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27911
	for <lemonade-web-archive@ietf.org>; Sat, 14 Jun 2003 11:35:35 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19RD1x-0006e3-00
	for lemonade-web-archive@ietf.org; Sat, 14 Jun 2003 11:33:25 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19RD1x-0006e0-00
	for lemonade-web-archive@ietf.org; Sat, 14 Jun 2003 11:33:25 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5EEd0a04892;
	Sat, 14 Jun 2003 10:39:00 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5EEclm04878
	for <lemonade@optimus.ietf.org>; Sat, 14 Jun 2003 10:38:47 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26945
	for <lemonade@ietf.org>; Sat, 14 Jun 2003 10:38:44 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19RC8w-0006QL-00
	for lemonade@ietf.org; Sat, 14 Jun 2003 10:36:34 -0400
Received: from darius.cyrusoft.com ([63.163.82.2])
	by ietf-mx with esmtp (Exim 4.12)
	id 19RC8v-0006QI-00
	for lemonade@ietf.org; Sat, 14 Jun 2003 10:36:33 -0400
Received: from [10.0.1.5] (localhost [127.0.0.1])
	by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id KAA20261;
	Sat, 14 Jun 2003 10:34:59 -0400 (EDT)
Date: Sat, 14 Jun 2003 10:20:16 -0400
From: Cyrus Daboo <daboo@cyrusoft.com>
To: Mendelovich Meir <Meir.Mendelovich@comverse.com>,
        "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: Re: [lemonade] Mobile messaging clients barriers
Message-ID: <2147139759.1055586016@[10.0.1.5]>
In-Reply-To: <E1542177268FD511866B0002A560C8080512E8D8@il-tlv-mail5.comverse.com>
References:  <E1542177268FD511866B0002A560C8080512E8D8@il-tlv-mail5.comverse.
 com>
X-Mailer: Mulberry/3.1.0b2 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi Mendelovich,

--On Friday, June 13, 2003 12:55 PM +0300 Mendelovich Meir 
<Meir.Mendelovich@comverse.com> wrote:

| 2. It is very hard to maintain long sessions in mobile networks. The
| current statefull nature of IMAP4 prevent many clients from providing
| good experience. Most of the mobile handsets that has IMAP4 client open
| and close new session for each command. This kind of behaviour cause
| enormous load on the server and spend lots of bandwidth. We MUST solve
| this problem if we want to see real mobile e-mail solution in GPRS and
| CDMA1X networks.

Sadly this is also an issue for regular desktop clients sitting behind 
firewalls and cable/DSL modems. Typically those types of device have idle 
connection timeouts set to a value much less than the IMAP minimum of 30 
minutes and they end up unilaterally disconnecting the client/server.

This issue is also significant for some webmail implementations where, due 
to the nature of the http server, its difficult to maintain (imap) state 
across http requests.

A good solution to this is to have a proxy which is in effect an imap 
client on one end (that maintains the server connection and caches mailbox 
data), and a server (of some sort) on the other. One could then access this 
proxy by regular IMAP, mIMAP, HTTP, or any other mechanism that would make 
sense. The proxy could then handle composition/submission etc as already 
discussed. I think there is at least one simple connection caching proxy 
that's being used with webmail solutions right now.

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



From mailnull@www1.ietf.org  Sat Jun 14 12:32:28 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28756
	for <lemonade-archive@odin.ietf.org>; Sat, 14 Jun 2003 12:32:28 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5EGW1A10752
	for lemonade-archive@odin.ietf.org; Sat, 14 Jun 2003 12:32:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5EGW0m10749
	for <lemonade-web-archive@optimus.ietf.org>; Sat, 14 Jun 2003 12:32:00 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28753
	for <lemonade-web-archive@ietf.org>; Sat, 14 Jun 2003 12:31:57 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19RDuW-0006rC-00
	for lemonade-web-archive@ietf.org; Sat, 14 Jun 2003 12:29:48 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19RDuV-0006r9-00
	for lemonade-web-archive@ietf.org; Sat, 14 Jun 2003 12:29:47 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5EG20a09047;
	Sat, 14 Jun 2003 12:02:00 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5EG11m08865
	for <lemonade@optimus.ietf.org>; Sat, 14 Jun 2003 12:01:01 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28156
	for <lemonade@ietf.org>; Sat, 14 Jun 2003 12:00:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19RDQX-0006hf-00
	for lemonade@ietf.org; Sat, 14 Jun 2003 11:58:49 -0400
Received: from panda.com
	([206.124.149.114] helo=Ikkoku-Kan.Panda.COM ident=pao)
	by ietf-mx with esmtp (Exim 4.12)
	id 19RDQW-0006hb-00
	for lemonade@ietf.org; Sat, 14 Jun 2003 11:58:48 -0400
Received: from localhost (mrc@localhost) by Ikkoku-Kan.Panda.COM id JAA26594; Sat, 14 Jun 2003 09:00:48 -0700 (PDT)
Date: Sat, 14 Jun 2003 09:00:47 -0700 (PDT)
From: Mark Crispin <mrc@CAC.Washington.EDU>
To: Cyrus Daboo <daboo@cyrusoft.com>
cc: Mendelovich Meir <Meir.Mendelovich@comverse.com>,
        "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: Re: [lemonade] Mobile messaging clients barriers
In-Reply-To: <2147139759.1055586016@[10.0.1.5]>
Message-ID: <Pine.NXT.4.56.0306140857520.11845@Ikkoku-Kan.Panda.COM>
References: <E1542177268FD511866B0002A560C8080512E8D8@il-tlv-mail5.comverse.
 com> <2147139759.1055586016@[10.0.1.5]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Sat, 14 Jun 2003, Cyrus Daboo wrote:
> A good solution to this is to have a proxy which is in effect an imap
> client on one end (that maintains the server connection and caches mailbox
> data), and a server (of some sort) on the other. One could then access this
> proxy by regular IMAP, mIMAP, HTTP, or any other mechanism that would make
> sense. The proxy could then handle composition/submission etc as already
> discussed. I think there is at least one simple connection caching proxy
> that's being used with webmail solutions right now.

This sounds like a concensus is forming around developing this proxy --
which will provide multiple necessary services for mobile clients
including submit -- and NOT to hammer all this into IMAP.

-- 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 mailnull@www1.ietf.org  Sat Jun 14 13:10:22 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29517
	for <lemonade-archive@odin.ietf.org>; Sat, 14 Jun 2003 13:10:21 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5EH9ti13473
	for lemonade-archive@odin.ietf.org; Sat, 14 Jun 2003 13:09:55 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5EH9sm13470
	for <lemonade-web-archive@optimus.ietf.org>; Sat, 14 Jun 2003 13:09:54 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29514
	for <lemonade-web-archive@ietf.org>; Sat, 14 Jun 2003 13:09:51 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19REVC-00072Z-00
	for lemonade-web-archive@ietf.org; Sat, 14 Jun 2003 13:07:42 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19REVB-00072W-00
	for lemonade-web-archive@ietf.org; Sat, 14 Jun 2003 13:07:41 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5EGq1a12060;
	Sat, 14 Jun 2003 12:52:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5EGpqm12043
	for <lemonade@optimus.ietf.org>; Sat, 14 Jun 2003 12:51:52 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29030
	for <lemonade@ietf.org>; Sat, 14 Jun 2003 12:51:48 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19REDj-0006vx-00
	for lemonade@ietf.org; Sat, 14 Jun 2003 12:49:39 -0400
Received: from eagle.oceana.com ([208.17.123.12])
	by ietf-mx with esmtp (Exim 4.12)
	id 19REDi-0006vo-00
	for lemonade@ietf.org; Sat, 14 Jun 2003 12:49:38 -0400
Received: from oceana.com (ny-kenton4a-a-83.buf.adelphia.net [24.51.28.83])
	(authenticated bits=0)
	by eagle.oceana.com (8.12.9/8.12.9) with ESMTP id h5EGofbm007806
	(version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT);
	Sat, 14 Jun 2003 12:50:42 -0400 (EDT)
Message-ID: <3EEB525C.9030800@oceana.com>
Date: Sat, 14 Jun 2003 12:50:36 -0400
From: Ken Murchison <ken@oceana.com>
Organization: Oceana Matrix Ltd.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Cyrus Daboo <daboo@cyrusoft.com>
CC: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: Re: [lemonade] Mobile messaging clients barriers
References: <E1542177268FD511866B0002A560C8080512E8D8@il-tlv-mail5.comverse. com> <2147139759.1055586016@[10.0.1.5]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit



Cyrus Daboo wrote:
 >
 >
> A good solution to this is to have a proxy which is in effect an imap 
> client on one end (that maintains the server connection and caches 
> mailbox data), and a server (of some sort) on the other. One could then 
> access this proxy by regular IMAP, mIMAP, HTTP, or any other mechanism 
> that would make sense. The proxy could then handle 
> composition/submission etc as already discussed. I think there is at 
> least one simple connection caching proxy that's being used with webmail 
> solutions right now.

There are at least two that I know of, one of which is right in your own 
backyard at Pitt.

http://www.imapproxy.org/
http://www.horde.org/imapproxy/

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

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



From mailnull@www1.ietf.org  Sat Jun 14 14:09:10 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00554
	for <lemonade-archive@odin.ietf.org>; Sat, 14 Jun 2003 14:09:10 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5EI8gI16660
	for lemonade-archive@odin.ietf.org; Sat, 14 Jun 2003 14:08:42 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5EI8gm16657
	for <lemonade-web-archive@optimus.ietf.org>; Sat, 14 Jun 2003 14:08:42 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00542
	for <lemonade-web-archive@ietf.org>; Sat, 14 Jun 2003 14:08:40 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19RFQ5-0007FY-00
	for lemonade-web-archive@ietf.org; Sat, 14 Jun 2003 14:06:29 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19RFQ4-0007FV-00
	for lemonade-web-archive@ietf.org; Sat, 14 Jun 2003 14:06:28 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5EHQ0a13817;
	Sat, 14 Jun 2003 13:26:00 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5EHPQm13805
	for <lemonade@optimus.ietf.org>; Sat, 14 Jun 2003 13:25:26 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29754
	for <lemonade@ietf.org>; Sat, 14 Jun 2003 13:25:22 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19REkD-00076J-00
	for lemonade@ietf.org; Sat, 14 Jun 2003 13:23:13 -0400
Received: from champdsl-25-66.mcleodusa.net ([216.43.25.66] helo=episteme-software.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19REkC-00075m-00
	for lemonade@ietf.org; Sat, 14 Jun 2003 13:23:12 -0400
Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with
 ESMTP (Eudora Internet Mail Server X 3.2.2b1);
 Sat, 14 Jun 2003 12:25:01 -0500
Mime-Version: 1.0
X-Sender: resnick@resnick1.qualcomm.com
Message-Id: <p06001400bb1107c79305@[216.43.25.67]>
In-Reply-To: <Pine.NXT.4.56.0306140857520.11845@Ikkoku-Kan.Panda.COM>
References: 
 <E1542177268FD511866B0002A560C8080512E8D8@il-tlv-mail5.comverse. com>
 <2147139759.1055586016@[10.0.1.5]>
 <Pine.NXT.4.56.0306140857520.11845@Ikkoku-Kan.Panda.COM>
X-Mailer: Eudora [Macintosh version 6.0a15]
Date: Sat, 14 Jun 2003 12:24:50 -0500
To: Mark Crispin <mrc@CAC.Washington.EDU>
From: Pete Resnick <presnick@qualcomm.com>
Subject: Re: [lemonade] Mobile messaging clients barriers
Cc: Cyrus Daboo <daboo@cyrusoft.com>,
        Mendelovich Meir <Meir.Mendelovich@comverse.com>,
        "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On 6/14/03 at 9:00 AM -0700, Mark Crispin wrote:

>This sounds like a concensus is forming around developing this proxy --

1) It is for the chairs to call concensus.

2) I don't think "Mark and Cyrus think it's a good idea, Doug and 
Pete have expressed reservations about it, and a couple of other 
people say they are considering it" makes for anything you can call 
consensus.

I think the complexity introduced by a proxy I think is higher than 
the other choices, the idea of developing an entirely new protocol 
for mobile clients to access IMAP and SMTP through a proxy seems way 
outside of the scope of our charter, and the suggestion that 
something like mIMAP or HTTP would be used smacks of WAP. I *thought* 
our purpose here was to make things easier for mobile clients using 
*current* protocols, either by simplifying implementation 
requirements for current protocols (what we've called "profiling" in 
the charter for lack of a better word) or, when absolutely necessary, 
creating new commands for current protocols. I'd like to hear where 
our chairs are on this.

pr
-- 
Pete Resnick <mailto:presnick@qualcomm.com>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Sat Jun 14 15:24:06 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02869
	for <lemonade-archive@odin.ietf.org>; Sat, 14 Jun 2003 15:24:06 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5EJNbS20702
	for lemonade-archive@odin.ietf.org; Sat, 14 Jun 2003 15:23:37 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5EJNbm20699
	for <lemonade-web-archive@optimus.ietf.org>; Sat, 14 Jun 2003 15:23:37 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02865
	for <lemonade-web-archive@ietf.org>; Sat, 14 Jun 2003 15:23:36 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19RGab-0007XW-00
	for lemonade-web-archive@ietf.org; Sat, 14 Jun 2003 15:21:25 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19RGaa-0007XT-00
	for lemonade-web-archive@ietf.org; Sat, 14 Jun 2003 15:21:24 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5EHh0a15031;
	Sat, 14 Jun 2003 13:43:00 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5EHgam15017
	for <lemonade@optimus.ietf.org>; Sat, 14 Jun 2003 13:42:36 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29999
	for <lemonade@ietf.org>; Sat, 14 Jun 2003 13:42:34 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19RF0p-00078n-00
	for lemonade@ietf.org; Sat, 14 Jun 2003 13:40:23 -0400
Received: from inet-consulting.com ([4.23.9.166] helo=royer.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19RF0o-00078k-00
	for lemonade@ietf.org; Sat, 14 Jun 2003 13:40:22 -0400
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h5EHgPbt012155
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <lemonade@ietf.org>; Sat, 14 Jun 2003 10:42:31 -0700
Message-ID: <3EEB5E7B.9000404@Royer.com>
Date: Sat, 14 Jun 2003 11:42:19 -0600
From: Doug Royer <Doug@Royer.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: lemonade@ietf.org
Subject: Re: [lemonade] Strawman for Submit based message composition
References: <54E40201497DF142B06B27255953F79705BFE5AE@il0015exch007u.ih.lucent.com> <3EE9DA68.5050106@Royer.com> <Pine.NXT.4.56.0306131027430.11845@Ikkoku-Kan.Panda.COM> <3EEA2048.5010603@Royer.com> <Pine.NXT.4.56.0306132222450.11845@Ikkoku-Kan.Panda.COM>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040009030002010106010201"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This is a cryptographically signed message in MIME format.

--------------ms040009030002010106010201
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


Mark Crispin wrote:
> On Fri, 13 Jun 2003, Doug Royer wrote:
> 
>>>Since when is the MAIL FROM tied to IMAP authentication?
>>
>>In the context of the email I replied to.
> 
> 
> Why is the SMTP return-path tied to IMAP authentication?
> 
> 
>>>Are you also
>>>going to claim that the From: header is also tied to IMAP authentication?
>>
>>Are you claming I said that?
> 
> 
> Why is the SMTP return-path is tied to IMAP authentication but the From:
> header is not?

Why are you mis-quoting me?

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  Doug@Royer.com                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

--------------ms040009030002010106010201
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC
A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j
cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB
MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T
BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN
VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre
qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+
5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA
MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg
TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD
QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx
ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz
IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq
hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34
1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA
gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK
YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd
SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC
AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF
BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl
cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl
IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs
MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq
1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2
TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail
MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE
AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO
b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG
MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD
VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV
BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv
43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y
lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP
D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn
0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK
bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg
hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT
IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI
AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t
L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk
OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW
yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1
MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl
ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTQxNzQyMTlaMCMGCSqGSIb3DQEJBDEWBBS3
KqX7z2u15sUFzehYJK14toq7VjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL
KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAmc/t8/6QVBsI
LHTMuTCgEOPTCK72SXo+8nV48dJuwsrtcGBmViwGSKN6JJ3yyitYUhY4J+sEwi2J9O23yWDw
g4mmMvR0IUWeMNKePMFJ0gToyc5/5HGQ4MsK+yvhopzPdmiS/oZjopcYbVeI62t+slwLyxz8
A/EN1kyHHmMk28t6GomkHxGAsdzkPdaAzWet0izfW0SoMkLGgqGtS7XMbGqshTcfcji/UVAL
QISUaDv/68L/Zjg5vWjmm+DIOGIlDWYgx7G7wRuhjL6UemXjj6awzkH+7BDFm8RsIHJjzj1j
orvf/dI3SJ01ckvIofwzGOdmTwZV6CTzoRu7iBfOyAAAAAAAAA==
--------------ms040009030002010106010201--

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



From mailnull@www1.ietf.org  Sat Jun 14 16:16:40 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03573
	for <lemonade-archive@odin.ietf.org>; Sat, 14 Jun 2003 16:16:40 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5EKGCa23880
	for lemonade-archive@odin.ietf.org; Sat, 14 Jun 2003 16:16:12 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5EKGCm23877
	for <lemonade-web-archive@optimus.ietf.org>; Sat, 14 Jun 2003 16:16:12 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03565
	for <lemonade-web-archive@ietf.org>; Sat, 14 Jun 2003 16:16:10 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19RHPT-0007jb-00
	for lemonade-web-archive@ietf.org; Sat, 14 Jun 2003 16:13:59 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19RHPT-0007jY-00
	for lemonade-web-archive@ietf.org; Sat, 14 Jun 2003 16:13:59 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5EJg0a22107;
	Sat, 14 Jun 2003 15:42:00 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5EJfKm22089
	for <lemonade@optimus.ietf.org>; Sat, 14 Jun 2003 15:41:20 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03053
	for <lemonade@ietf.org>; Sat, 14 Jun 2003 15:41:18 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19RGrk-0007a9-00
	for lemonade@ietf.org; Sat, 14 Jun 2003 15:39:08 -0400
Received: from panda.com
	([206.124.149.114] helo=Ikkoku-Kan.Panda.COM ident=stuart)
	by ietf-mx with esmtp (Exim 4.12)
	id 19RGrj-0007a6-00
	for lemonade@ietf.org; Sat, 14 Jun 2003 15:39:07 -0400
Received: from localhost (mrc@localhost) by Ikkoku-Kan.Panda.COM id MAA26824; Sat, 14 Jun 2003 12:41:13 -0700 (PDT)
Date: Sat, 14 Jun 2003 12:41:12 -0700 (PDT)
From: Mark Crispin <mrc@CAC.Washington.EDU>
To: Doug Royer <Doug@Royer.com>
cc: lemonade@ietf.org
Subject: Re: [lemonade] Strawman for Submit based message composition
In-Reply-To: <3EEB5E7B.9000404@Royer.com>
Message-ID: <Pine.NXT.4.56.0306141239510.11845@Ikkoku-Kan.Panda.COM>
References: <54E40201497DF142B06B27255953F79705BFE5AE@il0015exch007u.ih.lucent.com>
 <3EE9DA68.5050106@Royer.com> <Pine.NXT.4.56.0306131027430.11845@Ikkoku-Kan.Panda.COM>
 <3EEA2048.5010603@Royer.com> <Pine.NXT.4.56.0306132222450.11845@Ikkoku-Kan.Panda.COM>
 <3EEB5E7B.9000404@Royer.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Sat, 14 Jun 2003, Doug Royer wrote:
> > Why is the SMTP return-path is tied to IMAP authentication but the From:
> > header is not?
> Why are you mis-quoting me?

Are you claiming that the SMTP return-path (which is what MAIL FROM sets)
is not tied to IMAP authentication?

Are you claiming that the From: header is tied to IMAP authentication?

If "no" to both of the above, then where is the misquote?

-- 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 mailnull@www1.ietf.org  Sat Jun 14 17:29:30 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04726
	for <lemonade-archive@odin.ietf.org>; Sat, 14 Jun 2003 17:29:30 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5ELT3228277
	for lemonade-archive@odin.ietf.org; Sat, 14 Jun 2003 17:29:03 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ELT3m28274
	for <lemonade-web-archive@optimus.ietf.org>; Sat, 14 Jun 2003 17:29:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04717
	for <lemonade-web-archive@ietf.org>; Sat, 14 Jun 2003 17:28:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19RIXx-0000HX-00
	for lemonade-web-archive@ietf.org; Sat, 14 Jun 2003 17:26:49 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19RIXx-0000HU-00
	for lemonade-web-archive@ietf.org; Sat, 14 Jun 2003 17:26:49 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5EJe1a22004;
	Sat, 14 Jun 2003 15:40:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5EJdLm21961
	for <lemonade@optimus.ietf.org>; Sat, 14 Jun 2003 15:39:21 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03006
	for <lemonade@ietf.org>; Sat, 14 Jun 2003 15:39:19 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19RGpo-0007ZO-00
	for lemonade@ietf.org; Sat, 14 Jun 2003 15:37:08 -0400
Received: from panda.com
	([206.124.149.114] helo=Ikkoku-Kan.Panda.COM ident=sra)
	by ietf-mx with esmtp (Exim 4.12)
	id 19RGpn-0007ZK-00
	for lemonade@ietf.org; Sat, 14 Jun 2003 15:37:08 -0400
Received: from localhost (mrc@localhost) by Ikkoku-Kan.Panda.COM id MAA26819; Sat, 14 Jun 2003 12:39:14 -0700 (PDT)
Date: Sat, 14 Jun 2003 12:39:13 -0700 (PDT)
From: Mark Crispin <mrc@CAC.Washington.EDU>
To: Pete Resnick <presnick@qualcomm.com>
cc: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: Re: [lemonade] Mobile messaging clients barriers
In-Reply-To: <p06001401bb1117cd548c@[216.43.25.67]>
Message-ID: <Pine.NXT.4.56.0306141236280.11845@Ikkoku-Kan.Panda.COM>
References: <E1542177268FD511866B0002A560C8080512E8D8@il-tlv-mail5.comverse.
 com> <2147139759.1055586016@[10.0.1.5]> <Pine.NXT.4.56.0306140857520.11845@Ikkoku-Kan.Panda.COM>
 <p06001400bb1107c79305@[216.43.25.67]> <Pine.NXT.4.56.0306141049400.11845@Ikkoku-Kan.Panda.COM>
 <p06001401bb1117cd548c@[216.43.25.67]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Sat, 14 Jun 2003, Pete Resnick wrote:
> I have never heard anyone claim that anything other than
> submit-in-IMAP is out of charter. I certainly don't think that
> Chris's proposal is out of charter.

Strange that it's called "Chris' proposal" when it is really an
elaboration of something that I originally brought up (and which you
shouted down, although later you apologized).

> I do question whether an entirely
> new proxy protocol is within charter and would like to hear the
> chairs' opinions on that, but I was also asking whether the chairs
> had any opinion on the state of consensus.

The state of compose and submit sucks.  I think that we can all stipulate
to that.  Whatever happens, something new has to be done to fix the
suckage.

The proxy proposal is a means to that end, but it isn't an end in itself.
Thus, I consider it in charter, although I'm willing to agree that it's
testing the boundaries and can only proceed with restraint.

-- 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 mailnull@www1.ietf.org  Sat Jun 14 17:32:57 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04788
	for <lemonade-archive@odin.ietf.org>; Sat, 14 Jun 2003 17:32:56 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5ELWTg28394
	for lemonade-archive@odin.ietf.org; Sat, 14 Jun 2003 17:32:29 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ELWTm28391
	for <lemonade-web-archive@optimus.ietf.org>; Sat, 14 Jun 2003 17:32:29 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04774
	for <lemonade-web-archive@ietf.org>; Sat, 14 Jun 2003 17:32:26 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19RIbI-0000IQ-00
	for lemonade-web-archive@ietf.org; Sat, 14 Jun 2003 17:30:16 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19RIbH-0000IN-00
	for lemonade-web-archive@ietf.org; Sat, 14 Jun 2003 17:30:15 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5EIH1a16975;
	Sat, 14 Jun 2003 14:17:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5EIGbm16956
	for <lemonade@optimus.ietf.org>; Sat, 14 Jun 2003 14:16:37 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00701
	for <lemonade@ietf.org>; Sat, 14 Jun 2003 14:16:35 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19RFXk-0007IZ-00
	for lemonade@ietf.org; Sat, 14 Jun 2003 14:14:24 -0400
Received: from panda.com
	([206.124.149.114] helo=Ikkoku-Kan.Panda.COM ident=rodriguez)
	by ietf-mx with esmtp (Exim 4.12)
	id 19RFXj-0007IW-00
	for lemonade@ietf.org; Sat, 14 Jun 2003 14:14:23 -0400
Received: from localhost (mrc@localhost) by Ikkoku-Kan.Panda.COM id LAA26742; Sat, 14 Jun 2003 11:16:16 -0700 (PDT)
Date: Sat, 14 Jun 2003 11:16:15 -0700 (PDT)
From: Mark Crispin <mrc@CAC.Washington.EDU>
To: Pete Resnick <presnick@qualcomm.com>
cc: Cyrus Daboo <daboo@cyrusoft.com>,
        Mendelovich Meir <Meir.Mendelovich@comverse.com>,
        "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: Re: [lemonade] Mobile messaging clients barriers
In-Reply-To: <p06001400bb1107c79305@[216.43.25.67]>
Message-ID: <Pine.NXT.4.56.0306141049400.11845@Ikkoku-Kan.Panda.COM>
References: <E1542177268FD511866B0002A560C8080512E8D8@il-tlv-mail5.comverse.
 com> <2147139759.1055586016@[10.0.1.5]> <Pine.NXT.4.56.0306140857520.11845@Ikkoku-Kan.Panda.COM>
 <p06001400bb1107c79305@[216.43.25.67]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Sat, 14 Jun 2003, Pete Resnick wrote:
> 1) It is for the chairs to call concensus.
> 2) I don't think "Mark and Cyrus think it's a good idea, Doug and
> Pete have expressed reservations about it, and a couple of other
> people say they are considering it" makes for anything you can call
> consensus.

I am disappointed that you would say this, after having let pass a claim
of concensus that you probably agreed with.

> I *thought*
> our purpose here was to make things easier for mobile clients using
> *current* protocols

Carrying that argument to its logical conclusion, it is out of order to
propose submission in IMAP because the current protocol to submit is SMTP;
therefore any effort to make submit easier for mobile clients must be done
in SMTP.

> I'd like to hear where
> our chairs are on this.

A ruling from the chairs to the effect that submit-in-IMAP is the only
in-charter solution would have the effect of rendering meaningless any
pretense of fairness in this WG.

-- 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 mailnull@www1.ietf.org  Sat Jun 14 17:38:00 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04853
	for <lemonade-archive@odin.ietf.org>; Sat, 14 Jun 2003 17:38:00 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5ELbXY29408
	for lemonade-archive@odin.ietf.org; Sat, 14 Jun 2003 17:37:33 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ELbXm29405
	for <lemonade-web-archive@optimus.ietf.org>; Sat, 14 Jun 2003 17:37:33 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04848
	for <lemonade-web-archive@ietf.org>; Sat, 14 Jun 2003 17:37:30 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19RIgC-0000Jb-00
	for lemonade-web-archive@ietf.org; Sat, 14 Jun 2003 17:35:20 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19RIgB-0000JY-00
	for lemonade-web-archive@ietf.org; Sat, 14 Jun 2003 17:35:19 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5EIJ0a17059;
	Sat, 14 Jun 2003 14:19:00 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5EIIgm17046
	for <lemonade@optimus.ietf.org>; Sat, 14 Jun 2003 14:18:42 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00736
	for <lemonade@ietf.org>; Sat, 14 Jun 2003 14:18:39 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19RFZk-0007JR-00
	for lemonade@ietf.org; Sat, 14 Jun 2003 14:16:28 -0400
Received: from smtp5.andrew.cmu.edu ([128.2.10.85])
	by ietf-mx with esmtp (Exim 4.12)
	id 19RFZk-0007JO-00
	for lemonade@ietf.org; Sat, 14 Jun 2003 14:16:28 -0400
Received: from majormajor.REM.CMU.EDU (DYN-4-220.CC.cmu.edu [128.2.4.220] (may be forged))
	(user=leg mech=GSSAPI (0 bits))
	by smtp5.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h5EIIU2u004598
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT);
	Sat, 14 Jun 2003 14:18:31 -0400
Date: Sat, 14 Jun 2003 14:18:23 -0400
From: Lawrence Greenfield <leg+@andrew.cmu.edu>
To: Pete Resnick <presnick@qualcomm.com>,
        Mark Crispin <mrc@cac.washington.edu>
cc: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: Re: [lemonade] Mobile messaging clients barriers
Message-ID: <831295850.1055600303@majormajor.REM.CMU.EDU>
In-Reply-To: <p06001400bb1107c79305@[216.43.25.67]>
References:  <E1542177268FD511866B0002A560C8080512E8D8@il-tlv-mail5.comverse.
  com> <2147139759.1055586016@[10.0.1.5]>
 <Pine.NXT.4.56.0306140857520.11845@Ikkoku-Kan.Panda.COM>
 <p06001400bb1107c79305@[216.43.25.67]>
X-Mailer: Mulberry/3.0.3 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

--On Saturday, June 14, 2003 12:24 PM -0500 Pete Resnick 
<presnick@qualcomm.com> wrote:

> I think the complexity introduced by a proxy I think is higher than the
> other choices, the idea of developing an entirely new protocol for mobile
> clients to access IMAP and SMTP through a proxy seems way outside of the
> scope of our charter, and the suggestion that something like mIMAP or
> HTTP would be used smacks of WAP. I *thought* our purpose here was to
> make things easier for mobile clients using *current* protocols, either
> by simplifying implementation requirements for current protocols (what
> we've called "profiling" in the charter for lack of a better word) or,
> when absolutely necessary, creating new commands for current protocols.
> I'd like to hear where our chairs are on this.

I agree with this. Introducing yet another access protocol and the security 
complications of proxy servers strikes me as exactly the wrong thing to do.

If the problem is long running TCP sessions, let's try to understand that 
(that's one complaint I've seen with IMAP). If the problem is having to 
initiate new TCP sessions (a complaint with submit only through SMTP) let's 
understand that.

Larry

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



From mailnull@www1.ietf.org  Sat Jun 14 17:48:44 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05031
	for <lemonade-archive@odin.ietf.org>; Sat, 14 Jun 2003 17:48:44 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5ELmHd29690
	for lemonade-archive@odin.ietf.org; Sat, 14 Jun 2003 17:48:17 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ELmHm29686
	for <lemonade-web-archive@optimus.ietf.org>; Sat, 14 Jun 2003 17:48:17 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05028
	for <lemonade-web-archive@ietf.org>; Sat, 14 Jun 2003 17:48:14 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19RIqa-0000MT-00
	for lemonade-web-archive@ietf.org; Sat, 14 Jun 2003 17:46:04 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19RIqZ-0000MQ-00
	for lemonade-web-archive@ietf.org; Sat, 14 Jun 2003 17:46:03 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5EKB1a23690;
	Sat, 14 Jun 2003 16:11:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5EKA7m23576
	for <lemonade@optimus.ietf.org>; Sat, 14 Jun 2003 16:10:07 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03423
	for <lemonade@ietf.org>; Sat, 14 Jun 2003 16:10:05 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19RHJa-0007fg-00
	for lemonade@ietf.org; Sat, 14 Jun 2003 16:07:54 -0400
Received: from champdsl-25-66.mcleodusa.net ([216.43.25.66] helo=episteme-software.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19RHJa-0007fY-00
	for lemonade@ietf.org; Sat, 14 Jun 2003 16:07:54 -0400
Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with
 ESMTP (Eudora Internet Mail Server X 3.2.2b1);
 Sat, 14 Jun 2003 15:09:42 -0500
Mime-Version: 1.0
X-Sender: resnick@resnick1.qualcomm.com
Message-Id: <p06001400bb112fb2ee43@[216.43.25.67]>
In-Reply-To: <Pine.NXT.4.56.0306141236280.11845@Ikkoku-Kan.Panda.COM>
References: 
 <E1542177268FD511866B0002A560C8080512E8D8@il-tlv-mail5.comverse. com>
 <2147139759.1055586016@[10.0.1.5]>
 <Pine.NXT.4.56.0306140857520.11845@Ikkoku-Kan.Panda.COM>
 <p06001400bb1107c79305@[216.43.25.67]>
 <Pine.NXT.4.56.0306141049400.11845@Ikkoku-Kan.Panda.COM>
 <p06001401bb1117cd548c@[216.43.25.67]>
 <Pine.NXT.4.56.0306141236280.11845@Ikkoku-Kan.Panda.COM>
X-Mailer: Eudora [Macintosh version 6.0a15]
Date: Sat, 14 Jun 2003 15:09:31 -0500
To: Mark Crispin <mrc@CAC.Washington.EDU>
From: Pete Resnick <presnick@qualcomm.com>
Subject: Re: [lemonade] Mobile messaging clients barriers
Cc: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On 6/14/03 at 12:39 PM -0700, Mark Crispin wrote:

>On Sat, 14 Jun 2003, Pete Resnick wrote:
>>I certainly don't think that Chris's proposal is out of charter.
>
>Strange that it's called "Chris' proposal" when it is really an 
>elaboration of something that I originally brought up

Oy, vey. I called it "Chris's proposal" because I first wrote 
"submit-in-SMTP", didn't like it, erased it and wrote 
"submit-in-MTA", didn't like it, erased it and then wrote "Chris's 
proposal" because he's the one who posted the straw man to the list. 
Is it really necessary to personalize each and every comment?

>(and which you shouted down, although later you apologized).

Which I shouted down because it came to the mic after the chairs 
closed down discussion in the face-to-face meeting and I thought it 
was unfair to bring up a new topic with no opportunity for 
discussion, not because I thought it was out of charter. And yes, I 
did apologize for shouting.

>The state of compose and submit sucks.  I think that we can all 
>stipulate to that.  Whatever happens, something new has to be done 
>to fix the suckage.

Agreed.

>The proxy proposal is a means to that end, but it isn't an end in 
>itself. Thus, I consider it in charter, although I'm willing to 
>agree that it's testing the boundaries and can only proceed with 
>restraint.

Understood.

pr
-- 
Pete Resnick <mailto:presnick@qualcomm.com>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Sat Jun 14 17:51:14 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05064
	for <lemonade-archive@odin.ietf.org>; Sat, 14 Jun 2003 17:51:14 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5ELoln29739
	for lemonade-archive@odin.ietf.org; Sat, 14 Jun 2003 17:50:47 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ELolm29736
	for <lemonade-web-archive@optimus.ietf.org>; Sat, 14 Jun 2003 17:50:47 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05058
	for <lemonade-web-archive@ietf.org>; Sat, 14 Jun 2003 17:50:44 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19RIt0-0000Mr-00
	for lemonade-web-archive@ietf.org; Sat, 14 Jun 2003 17:48:34 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19RIsz-0000Mo-00
	for lemonade-web-archive@ietf.org; Sat, 14 Jun 2003 17:48:33 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5EIT1a17330;
	Sat, 14 Jun 2003 14:29:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5EISWm17317
	for <lemonade@optimus.ietf.org>; Sat, 14 Jun 2003 14:28:32 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00898
	for <lemonade@ietf.org>; Sat, 14 Jun 2003 14:28:29 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19RFjG-0007LJ-00
	for lemonade@ietf.org; Sat, 14 Jun 2003 14:26:18 -0400
Received: from champdsl-25-66.mcleodusa.net ([216.43.25.66] helo=episteme-software.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19RFjG-0007LB-00
	for lemonade@ietf.org; Sat, 14 Jun 2003 14:26:18 -0400
Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with
 ESMTP (Eudora Internet Mail Server X 3.2.2b1);
 Sat, 14 Jun 2003 13:28:06 -0500
Mime-Version: 1.0
X-Sender: resnick@resnick1.qualcomm.com
Message-Id: <p06001401bb1117cd548c@[216.43.25.67]>
In-Reply-To: <Pine.NXT.4.56.0306141049400.11845@Ikkoku-Kan.Panda.COM>
References: 
 <E1542177268FD511866B0002A560C8080512E8D8@il-tlv-mail5.comverse. com>
 <2147139759.1055586016@[10.0.1.5]>
 <Pine.NXT.4.56.0306140857520.11845@Ikkoku-Kan.Panda.COM>
 <p06001400bb1107c79305@[216.43.25.67]>
 <Pine.NXT.4.56.0306141049400.11845@Ikkoku-Kan.Panda.COM>
X-Mailer: Eudora [Macintosh version 6.0a15]
Date: Sat, 14 Jun 2003 13:27:56 -0500
To: Mark Crispin <mrc@CAC.Washington.EDU>
From: Pete Resnick <presnick@qualcomm.com>
Subject: Re: [lemonade] Mobile messaging clients barriers
Cc: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On 6/14/03 at 11:16 AM -0700, Mark Crispin wrote:

>I am disappointed that you would say this, after having let pass a 
>claim of concensus that you probably agreed with.

I don't understand to what you are referring.

>>I *thought* our purpose here was to make things easier for mobile 
>>clients using *current* protocols
>
>Carrying that argument to its logical conclusion, it is out of order 
>to propose submission in IMAP because the current protocol to submit 
>is SMTP;

Uh, not if you include the rest of the sentence that you quoted:

"either by simplifying implementation requirements for current 
protocols (what we've called "profiling" in the charter for lack of a 
better word) or, when absolutely necessary, creating new commands for 
current protocols."

Don't take this out of context: What I was arguing against creating 
an entirely new proxy protocol rather than using either IMAP or SMTP 
to do the job.

>A ruling from the chairs to the effect that submit-in-IMAP is the 
>only in-charter solution would have the effect of rendering 
>meaningless any pretense of fairness in this WG.

I have never heard anyone claim that anything other than 
submit-in-IMAP is out of charter. I certainly don't think that 
Chris's proposal is out of charter. I do question whether an entirely 
new proxy protocol is within charter and would like to hear the 
chairs' opinions on that, but I was also asking whether the chairs 
had any opinion on the state of consensus.

pr
-- 
Pete Resnick <mailto:presnick@qualcomm.com>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Sat Jun 14 19:59:47 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07878
	for <lemonade-archive@odin.ietf.org>; Sat, 14 Jun 2003 19:59:47 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5ENxIB03735
	for lemonade-archive@odin.ietf.org; Sat, 14 Jun 2003 19:59:18 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ENxIm03732
	for <lemonade-web-archive@optimus.ietf.org>; Sat, 14 Jun 2003 19:59:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07875
	for <lemonade-web-archive@ietf.org>; Sat, 14 Jun 2003 19:59:16 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19RKtN-0000lx-00
	for lemonade-web-archive@ietf.org; Sat, 14 Jun 2003 19:57:05 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19RKtM-0000lu-00
	for lemonade-web-archive@ietf.org; Sat, 14 Jun 2003 19:57:04 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5EMn1a00540;
	Sat, 14 Jun 2003 18:49:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5EMm5m00524
	for <lemonade@optimus.ietf.org>; Sat, 14 Jun 2003 18:48:05 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07024
	for <lemonade@ietf.org>; Sat, 14 Jun 2003 18:48:01 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19RJmR-0000ZK-00
	for lemonade@ietf.org; Sat, 14 Jun 2003 18:45:51 -0400
Received: from inet-consulting.com ([4.23.9.166] helo=royer.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19RJmQ-0000ZH-00
	for lemonade@ietf.org; Sat, 14 Jun 2003 18:45:50 -0400
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h5EMlsbt014344
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <lemonade@ietf.org>; Sat, 14 Jun 2003 15:47:59 -0700
Message-ID: <3EEBA609.5070004@Royer.com>
Date: Sat, 14 Jun 2003 16:47:37 -0600
From: Doug Royer <Doug@Royer.com>
Reply-To: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: Re: [lemonade] Mobile messaging clients barriers
References: <E1542177268FD511866B0002A560C8080512E8D8@il-tlv-mail5.comverse. com> <2147139759.1055586016@[10.0.1.5]> <Pine.NXT.4.56.0306140857520.11845@Ikkoku-Kan.Panda.COM> <p06001400bb1107c79305@[216.43.25.67]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070305080401040808070709"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This is a cryptographically signed message in MIME format.

--------------ms070305080401040808070709
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Pete Resnick wrote:

> I think the complexity introduced by a proxy I think is higher than the 
> other choices, the idea of developing an entirely new protocol for 
> mobile clients to access IMAP and SMTP through a proxy seems way outside 
> of the scope of our charter, and the suggestion that something like 
> mIMAP or HTTP would be used smacks of WAP. I *thought* our purpose here 
> was to make things easier for mobile clients using *current* protocols, 
> either by simplifying implementation requirements for current protocols 
> (what we've called "profiling" in the charter for lack of a better word) 
> or, when absolutely necessary, creating new commands for current 
> protocols. I'd like to hear where our chairs are on this.

I agree. However if the proxy program could be written such that
IMAP commands were sent straight through to an IMAP server, and
IMAP replies came straight back through the proxy. (+/- any
handshakes). And any new submit commands were routed to some new
submit server then it would not be a 'new' protocol. Just extensions that
when sent through a submit-imap proxy did what you wanted.
In effect it is extending the IMAP protocol, yet existing
IMAP servers could be used for the non-submit part of the work.

Alan's idea (sorry if some one else said it first), of using
the OUTBOX also seems much easier that a proxy. A process
could just scan the OUTBOX (entries created by the IMAP
APPEND command), and process them. It could set any bounces
directly into the users INBOX. The only thing to do is to
define a capability so that any IMAP client knows and asks for it
to happen. Then define how 'include/forward this blob' is going
to work.

The external mime body part already can be used by existing
tools to mean 'do NOT include', so maybe a 'include mime
body part' needs to be invented.

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  Doug@Royer.com                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

--------------ms070305080401040808070709
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC
A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j
cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB
MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T
BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN
VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre
qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+
5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA
MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg
TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD
QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx
ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz
IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq
hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34
1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA
gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK
YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd
SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC
AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF
BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl
cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl
IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs
MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq
1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2
TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail
MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE
AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO
b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG
MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD
VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV
BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv
43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y
lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP
D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn
0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK
bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg
hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT
IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI
AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t
L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk
OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW
yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1
MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl
ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTQyMjQ3MzdaMCMGCSqGSIb3DQEJBDEWBBRj
bdWhNgWlF4ix8GnHcZk3jkhnOTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL
KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAL9qc7oU+QGsz
Cas5bfOpfgHiv57HN9MKvv9XoUFl+8I1MklX4h5Jsztl4SD8Xa5Cyk1nxDUnJwKVanJwCM+C
I/Md316zYfWUvLZwzMU2PENdXeyTarWjRiJrbtVB1P6O8BtWZ0bCOOWraNRzL0dLT11+Iah+
SBwKF8h0VwlcGBv2idN6nKaXn7GTmLCuT/gI5L6J2Ahz5ogOsP+cYWyo5soOd9gVXoY2JTXx
0UiRSNWNYWEnOlq6RhUBBiqRTFzWKuorD9vmBuWPHkQJ4r1PZ++AyXbJ+4zyENL5rF4ADvUx
IzqO5rsOO3Se6zZDdWk840RtNU942zhsMnQLbjDXSAAAAAAAAA==
--------------ms070305080401040808070709--

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



From mailnull@www1.ietf.org  Sat Jun 14 21:17:59 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09034
	for <lemonade-archive@odin.ietf.org>; Sat, 14 Jun 2003 21:17:59 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5F1HVE08377
	for lemonade-archive@odin.ietf.org; Sat, 14 Jun 2003 21:17:31 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5F1HVm08374
	for <lemonade-web-archive@optimus.ietf.org>; Sat, 14 Jun 2003 21:17:31 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09016
	for <lemonade-web-archive@ietf.org>; Sat, 14 Jun 2003 21:17:28 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19RM73-00012C-00
	for lemonade-web-archive@ietf.org; Sat, 14 Jun 2003 21:15:17 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19RM72-000129-00
	for lemonade-web-archive@ietf.org; Sat, 14 Jun 2003 21:15:16 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5F0A1a05063;
	Sat, 14 Jun 2003 20:10:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5F094m05035
	for <lemonade@optimus.ietf.org>; Sat, 14 Jun 2003 20:09:04 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08113
	for <lemonade@ietf.org>; Sat, 14 Jun 2003 20:09:01 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19RL2n-0000pc-00
	for lemonade@ietf.org; Sat, 14 Jun 2003 20:06:49 -0400
Received: from panda.com
	([206.124.149.114] helo=Ikkoku-Kan.Panda.COM ident=brit)
	by ietf-mx with esmtp (Exim 4.12)
	id 19RL2m-0000pZ-00
	for lemonade@ietf.org; Sat, 14 Jun 2003 20:06:48 -0400
Received: from localhost (mrc@localhost) by Ikkoku-Kan.Panda.COM id RAA27096; Sat, 14 Jun 2003 17:08:57 -0700 (PDT)
Date: Sat, 14 Jun 2003 17:08:56 -0700 (PDT)
From: Mark Crispin <mrc@CAC.Washington.EDU>
To: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: Re: [lemonade] Mobile messaging clients barriers
In-Reply-To: <3EEBA609.5070004@Royer.com>
Message-ID: <Pine.NXT.4.56.0306141702330.11845@Ikkoku-Kan.Panda.COM>
References: <E1542177268FD511866B0002A560C8080512E8D8@il-tlv-mail5.comverse.
 com> <2147139759.1055586016@[10.0.1.5]> <Pine.NXT.4.56.0306140857520.11845@Ikkoku-Kan.Panda.COM>
 <p06001400bb1107c79305@[216.43.25.67]> <3EEBA609.5070004@Royer.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Sat, 14 Jun 2003, Doug Royer wrote:
> However if the proxy program could be written such that
> IMAP commands were sent straight through to an IMAP server, and
> IMAP replies came straight back through the proxy. (+/- any
> handshakes).

Yes, it should certainly be a requirement that a proxy program offer a
means to send/receive raw IMAP from the real IMAP server.

> In effect it is extending the IMAP protocol, yet existing
> IMAP servers could be used for the non-submit part of the work.

That is a way of looking at it; and if that makes it a more acceptable
solution to some then that's fine with me.

It *would* be nice if the proxy could be extensible enough so that future
hooks into NNTP, etc. could be made.  That implies that the base level
proxy operations be powerful enough, e.g. at least have a "get overview"
and "get message" operation.  But if this ruffles some feathers then I can
punt on that part.

-- 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 mailnull@www1.ietf.org  Sun Jun 15 07:29:52 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28597
	for <lemonade-archive@odin.ietf.org>; Sun, 15 Jun 2003 07:29:52 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5FBTNT25391
	for lemonade-archive@odin.ietf.org; Sun, 15 Jun 2003 07:29:23 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FBTMm25388
	for <lemonade-web-archive@optimus.ietf.org>; Sun, 15 Jun 2003 07:29:22 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28590
	for <lemonade-web-archive@ietf.org>; Sun, 15 Jun 2003 07:29:21 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19RVfA-00036j-00
	for lemonade-web-archive@ietf.org; Sun, 15 Jun 2003 07:27:08 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19RVfA-00036f-00
	for lemonade-web-archive@ietf.org; Sun, 15 Jun 2003 07:27:08 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5F7O0a07499;
	Sun, 15 Jun 2003 03:24:00 -0400
Received: from ietf.org (lists.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5F7Nfm07478
	for <lemonade@optimus.ietf.org>; Sun, 15 Jun 2003 03:23:41 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25280
	for <lemonade@ietf.org>; Sun, 15 Jun 2003 03:23:40 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19RRpQ-0002L7-00
	for lemonade@ietf.org; Sun, 15 Jun 2003 03:21:28 -0400
Received: from comversegw.icomverse.com ([192.118.48.248] helo=il-tlv-smtpout1.icomverse.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19RRpP-0002L4-00
	for lemonade@ietf.org; Sun, 15 Jun 2003 03:21:27 -0400
Received: from il-tlv-mbdg1.comverse.com (localhost.localdomain [127.0.0.1])
	by il-tlv-smtpout1.icomverse.com (8.11.6/8.11.6) with ESMTP id h5F7NB704733;
	Sun, 15 Jun 2003 10:23:12 +0300
Received: by il-tlv-mbdg1.comverse.com with Internet Mail Service (5.5.2655.55)
	id <M2S5K7V8>; Sun, 15 Jun 2003 10:23:17 +0300
Message-ID: <E1542177268FD511866B0002A560C8080512E8E1@il-tlv-mail5.comverse.com>
From: Mendelovich Meir <Meir.Mendelovich@comverse.com>
To: "'Mark Crispin'" <MRC@CAC.Washington.EDU>,
        "Vaudreuil, Greg M (Greg)"
	 <gregv@lucent.com>
Cc: Randall Gellens <randy@qualcomm.com>,
        "IETF LEMONADE (E-mail)"
	 <lemonade@ietf.org>
Date: Sun, 15 Jun 2003 10:23:15 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3330E.FC384C14"
Subject: [lemonade] (no subject)
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3330E.FC384C14
Content-Type: text/plain;
	charset="iso-8859-1"

Hi,
 I tested my GPRS round trips. Unsurprisingly, the results where worse than
CDMA1X. The main reason is that in GPRS the mobile station has to ask the
cell to allocate out-going slots for him. For that reason, the first pings
where very slow (1300ms-1800ms) and the following where much better
(~800ms). Every few seconds, the network had one or two bad pings and then
return to the good results.
I used my Nokia 6310i that is connected to my laptop using IR. I pinged the
first router on the operator's side. Pinging the operator's web servers
(cellcom.co.il) didn't add much latency. The results: Minimum = 601ms,
Maximum =  1822ms, Average =  821ms.

	Meir :->

-----Original Message-----
From: Mark Crispin [mailto:MRC@CAC.Washington.EDU] 
Sent: Friday, June 13, 2003 11:44 PM
To: Vaudreuil, Greg M (Greg)
Cc: Randall Gellens; IETF LEMONADE (E-mail)
Subject: RE: [lemonade] Wireless latencies


On Fri, 13 Jun 2003, Vaudreuil, Greg M (Greg) wrote:
> Using my LG CDMA phone (qualcomm chipset) on the Verizon 1xRTT network 
> using the 14.4 data channel (not the high-speed data) and pinging the 
> first router after the wireless link with 100 byte packets, over 100 
> samples, I measured a high of 598, a low of 441, and an average of 532 
> milliseconds.  This was with "five bars" of signal strength. 
> End-to-end round-trips to the likes of a www.yahoo.com site are some 
> 60 ms or so higher.

I averaged 516ms (min of 455ms, max of 756ms but I think Pine may have been
doing a NOOP over IMAP at that time) pinging www.yahoo.com with 100 byte
packets via CDPD from a ferry boat (not optimal characteristics...). This
suggests that something is wrong with your CDMA facility for you to be
getting 75ms worse with a full-strength connection, especially since CDMA is
superior technology.

Of course, at 14.4 it isn't unreasonable see a few hundred ms of ping times
for 100 byte packets.

-- 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

------_=_NextPart_001_01C3330E.FC384C14
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE></TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi,</FONT>
<BR><FONT SIZE=3D2>&nbsp;I tested my GPRS round trips. Unsurprisingly, =
the results where worse than CDMA1X. The main reason is that in GPRS =
the mobile station has to ask the cell to allocate out-going slots for =
him. For that reason, the first pings where very slow (1300ms-1800ms) =
and the following where much better (~800ms). Every few seconds, the =
network had one or two bad pings and then return to the good =
results.</FONT></P>

<P><FONT SIZE=3D2>I used my Nokia 6310i that is connected to my laptop =
using IR. I pinged the first router on the operator's side. Pinging the =
operator's web servers (cellcom.co.il) didn't add much latency. The =
results: Minimum =3D 601ms, Maximum =3D&nbsp; 1822ms, Average =3D&nbsp; =
821ms.</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>Meir =
:-&gt;</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Mark Crispin [<A =
HREF=3D"mailto:MRC@CAC.Washington.EDU">mailto:MRC@CAC.Washington.EDU</A>=
] </FONT>
<BR><FONT SIZE=3D2>Sent: Friday, June 13, 2003 11:44 PM</FONT>
<BR><FONT SIZE=3D2>To: Vaudreuil, Greg M (Greg)</FONT>
<BR><FONT SIZE=3D2>Cc: Randall Gellens; IETF LEMONADE (E-mail)</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [lemonade] Wireless latencies</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>On Fri, 13 Jun 2003, Vaudreuil, Greg M (Greg) =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; Using my LG CDMA phone (qualcomm chipset) on =
the Verizon 1xRTT network </FONT>
<BR><FONT SIZE=3D2>&gt; using the 14.4 data channel (not the high-speed =
data) and pinging the </FONT>
<BR><FONT SIZE=3D2>&gt; first router after the wireless link with 100 =
byte packets, over 100 </FONT>
<BR><FONT SIZE=3D2>&gt; samples, I measured a high of 598, a low of =
441, and an average of 532 </FONT>
<BR><FONT SIZE=3D2>&gt; milliseconds.&nbsp; This was with &quot;five =
bars&quot; of signal strength. </FONT>
<BR><FONT SIZE=3D2>&gt; End-to-end round-trips to the likes of a =
www.yahoo.com site are some </FONT>
<BR><FONT SIZE=3D2>&gt; 60 ms or so higher.</FONT>
</P>

<P><FONT SIZE=3D2>I averaged 516ms (min of 455ms, max of 756ms but I =
think Pine may have been doing a NOOP over IMAP at that time) pinging =
www.yahoo.com with 100 byte packets via CDPD from a ferry boat (not =
optimal characteristics...). This suggests that something is wrong with =
your CDMA facility for you to be getting 75ms worse with a =
full-strength connection, especially since CDMA is superior =
technology.</FONT></P>

<P><FONT SIZE=3D2>Of course, at 14.4 it isn't unreasonable see a few =
hundred ms of ping times for 100 byte packets.</FONT>
</P>

<P><FONT SIZE=3D2>-- Mark --</FONT>
</P>

<P><FONT SIZE=3D2><A HREF=3D"http://staff.washington.edu/mrc" =
TARGET=3D"_blank">http://staff.washington.edu/mrc</A></FONT>
<BR><FONT SIZE=3D2>Science does not emerge from voting, party politics, =
or public debate. Si vis pacem, para bellum. =
_______________________________________________</FONT></P>

<P><FONT SIZE=3D2>lemonade mailing list</FONT>
<BR><FONT SIZE=3D2>lemonade@ietf.org <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/lemonade" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/lemonade</A></F=
ONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C3330E.FC384C14--
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Sun Jun 15 15:22:10 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08877
	for <lemonade-archive@odin.ietf.org>; Sun, 15 Jun 2003 15:22:10 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5FJLe218955
	for lemonade-archive@odin.ietf.org; Sun, 15 Jun 2003 15:21:40 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FJLem18952
	for <lemonade-web-archive@optimus.ietf.org>; Sun, 15 Jun 2003 15:21:40 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08873
	for <lemonade-web-archive@ietf.org>; Sun, 15 Jun 2003 15:21:39 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Rd2E-0004pi-00
	for lemonade-web-archive@ietf.org; Sun, 15 Jun 2003 15:19:26 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Rd2D-0004pf-00
	for lemonade-web-archive@ietf.org; Sun, 15 Jun 2003 15:19:25 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FFI0a05980;
	Sun, 15 Jun 2003 11:18:00 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FFHIm05963
	for <lemonade@optimus.ietf.org>; Sun, 15 Jun 2003 11:17:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04378
	for <lemonade@ietf.org>; Sun, 15 Jun 2003 11:17:16 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19RZDk-00041w-00
	for lemonade@ietf.org; Sun, 15 Jun 2003 11:15:04 -0400
Received: from panda.com
	([206.124.149.114] helo=Ikkoku-Kan.Panda.COM ident=pra)
	by ietf-mx with esmtp (Exim 4.12)
	id 19RZDj-00041t-00
	for lemonade@ietf.org; Sun, 15 Jun 2003 11:15:04 -0400
Received: from localhost (mrc@localhost) by Ikkoku-Kan.Panda.COM id IAA28000; Sun, 15 Jun 2003 08:17:12 -0700 (PDT)
Date: Sun, 15 Jun 2003 08:17:11 -0700 (PDT)
From: Mark Crispin <mrc@CAC.Washington.EDU>
To: Erev Ari <Ari.Erev@comverse.com>
cc: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: RE: [lemonade] Mobile messaging clients barriers - Protocls vs. S
 erver Implementation
In-Reply-To: <7D4344E32B34D511A6500002A560C60204D8931B@il-tlv-mail4.comverse.com>
Message-ID: <Pine.NXT.4.56.0306150758140.11845@Ikkoku-Kan.Panda.COM>
References: <7D4344E32B34D511A6500002A560C60204D8931B@il-tlv-mail4.comverse.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Sun, 15 Jun 2003, Erev Ari wrote:
> Arn't we mixing PROTOCOL with SERVER IMPLEMENTATION?
> In other words, if the submit-client talks to the proxy using "IMAP" or
> "IMAP with an additional SUBMIT/APPEND/SEND command", isn't this still the
> domain of the IMAP PROTOCOL (i.e, to define the extension commands, their
> semantics etc.)?

Not at all.

The proxy would be on a different port, and leaves open the possibility in
the future for extensibility to provide other non-IMAP services.

It may be convenient for you to think of it is "an extension of IMAP"; and
if it serves that purpose in a useful way for you, that would be a good
outcome.

> And if, the submit-client talks to the proxy using "SMTP" or "SMTP with
> compose using some extenral link semantics", don't we still have the same
> security and authentication/authorization issues we would have if the
> extended functionality would have been added to an SMTP (submit) server (for
> the Proxy to authenticate, get message data, etc. from the IMAP server)?

No, because those issues are already being addressed elsewhere.  The proxy
method means that the mobile device doesn't have to deal with it.

> And if we invent a new protocol for the submit-client to talk to the proxy,
> other than SMTP or IMAP,  doesn't it bring back the "Submit Client needs to
> support two submit protocols" problem?

What happens if your customers have a requirement to work in an existing
enterprise infrastructure?

You can't escape the "support two submit protocols" problem without a
proxy; and if your client won't work with a non-extended server then your
client's success depends upon the whim of the server managers.

The beauty of the proxy method is that it works with all existing servers.

-- 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 mailnull@www1.ietf.org  Sun Jun 15 16:15:42 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09966
	for <lemonade-archive@odin.ietf.org>; Sun, 15 Jun 2003 16:15:42 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5FKFD422569
	for lemonade-archive@odin.ietf.org; Sun, 15 Jun 2003 16:15:13 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FKFDm22566
	for <lemonade-web-archive@optimus.ietf.org>; Sun, 15 Jun 2003 16:15:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09963
	for <lemonade-web-archive@ietf.org>; Sun, 15 Jun 2003 16:15:11 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Rds3-000555-00
	for lemonade-web-archive@ietf.org; Sun, 15 Jun 2003 16:12:59 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Rds2-000552-00
	for lemonade-web-archive@ietf.org; Sun, 15 Jun 2003 16:12:58 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FFo0a07537;
	Sun, 15 Jun 2003 11:50:00 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FFnum07517
	for <lemonade@optimus.ietf.org>; Sun, 15 Jun 2003 11:49:56 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04851
	for <lemonade@ietf.org>; Sun, 15 Jun 2003 11:49:54 -0400 (EDT)
From: ned.freed@mrochek.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19RZjK-00046Q-00
	for lemonade@ietf.org; Sun, 15 Jun 2003 11:47:42 -0400
Received: from mauve.mrochek.com ([209.55.107.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 19RZjJ-00046N-00
	for lemonade@ietf.org; Sun, 15 Jun 2003 11:47:41 -0400
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243)
 id <01KX2CJYZD2O00CUGD@mauve.mrochek.com> for lemonade@ietf.org; Sun,
 15 Jun 2003 08:49:40 -0700 (PDT)
Date: Sun, 15 Jun 2003 08:33:00 -0700 (PDT)
Subject: Re: [lemonade] Mobile messaging clients barriers
In-reply-to: "Your message dated Sat, 14 Jun 2003 14:18:23 -0400"
 <831295850.1055600303@majormajor.REM.CMU.EDU>
To: Lawrence Greenfield <leg+@andrew.cmu.edu>
Cc: Pete Resnick <presnick@qualcomm.com>,
        Mark Crispin <mrc@cac.washington.edu>,
        "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Message-id: <01KX48V95LVU00CUGD@mauve.mrochek.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
References: 
 <E1542177268FD511866B0002A560C8080512E8D8@il-tlv-mail5.comverse.com>
 <2147139759.1055586016@[10.0.1.5]>
 <Pine.NXT.4.56.0306140857520.11845@Ikkoku-Kan.Panda.COM>
 <p06001400bb1107c79305@[216.43.25.67]>
 <831295850.1055600303@majormajor.REM.CMU.EDU>
Content-Transfer-Encoding: 7BIT
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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-Transfer-Encoding: 7BIT
Content-Transfer-Encoding: 7BIT

> --On Saturday, June 14, 2003 12:24 PM -0500 Pete Resnick
> <presnick@qualcomm.com> wrote:

> > I think the complexity introduced by a proxy I think is higher than the
> > other choices, the idea of developing an entirely new protocol for mobile
> > clients to access IMAP and SMTP through a proxy seems way outside of the
> > scope of our charter, and the suggestion that something like mIMAP or
> > HTTP would be used smacks of WAP. I *thought* our purpose here was to
> > make things easier for mobile clients using *current* protocols, either
> > by simplifying implementation requirements for current protocols (what
> > we've called "profiling" in the charter for lack of a better word) or,
> > when absolutely necessary, creating new commands for current protocols.
> > I'd like to hear where our chairs are on this.

The LEMONADE charter is very clear: Most of the WG's tasks are supposed to be
done by enhancement or profiling of either IMAP4 or SMTP submit. The one
exception is notifications. These restrictions were very intentionally
added to the charter because of IESG concerns regarding WG scope.

Speaking as the AD in charge, I believe a charter revision would be best in
order to proceed along the path of developing a proxy. This doesn't have
to be a big deal, and if the WG does decide to develop a proxy it will
likely avoid a lot of trouble later by having it in the charter.

Of course this presupposes the WG actually reaches consensus to solve
this set of problems with a proxy.

> I agree with this. Introducing yet another access protocol and the security
> complications of proxy servers strikes me as exactly the wrong thing to do.

I also am very concerned about the security complications of a proxy-based
approach.

> If the problem is long running TCP sessions, let's try to understand that
> (that's one complaint I've seen with IMAP). If the problem is having to
> initiate new TCP sessions (a complaint with submit only through SMTP) let's
> understand that.

I also would like to understand the long running session / session initiation
issue(s). I will also point out that if reliable connections to servers really
are an issue there is an entire IETF WG devoted to solving this particular
problem:

  http://www.ietf.org/html.charters/rserpool-charter.html

If the WG decides that work in this space is in order the RSERPOOL approach
needs to at least be considered.

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



From mailnull@www1.ietf.org  Sun Jun 15 17:16:18 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11014
	for <lemonade-archive@odin.ietf.org>; Sun, 15 Jun 2003 17:16:18 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5FLFpq26391
	for lemonade-archive@odin.ietf.org; Sun, 15 Jun 2003 17:15:51 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FLFpm26388
	for <lemonade-web-archive@optimus.ietf.org>; Sun, 15 Jun 2003 17:15:51 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11009
	for <lemonade-web-archive@ietf.org>; Sun, 15 Jun 2003 17:15:48 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Reoi-0005Mf-00
	for lemonade-web-archive@ietf.org; Sun, 15 Jun 2003 17:13:36 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Reoh-0005Mc-00
	for lemonade-web-archive@ietf.org; Sun, 15 Jun 2003 17:13:35 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FER1a02927;
	Sun, 15 Jun 2003 10:27:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FEQTm02912
	for <lemonade@optimus.ietf.org>; Sun, 15 Jun 2003 10:26:29 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03508
	for <lemonade@ietf.org>; Sun, 15 Jun 2003 10:26:26 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19RYQY-0003rj-00
	for lemonade@ietf.org; Sun, 15 Jun 2003 10:24:14 -0400
Received: from comversegw.icomverse.com ([192.118.48.248] helo=il-tlv-smtpout1.icomverse.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19RYQX-0003rd-00
	for lemonade@ietf.org; Sun, 15 Jun 2003 10:24:13 -0400
Received: from il-tlv-mbdg1.comverse.com (localhost.localdomain [127.0.0.1])
	by il-tlv-smtpout1.icomverse.com (8.11.6/8.11.6) with ESMTP id h5FEQ0a06003;
	Sun, 15 Jun 2003 17:26:03 +0300
Received: by il-tlv-mbdg1.comverse.com with Internet Mail Service (5.5.2655.55)
	id <M2S5LCM4>; Sun, 15 Jun 2003 17:26:10 +0300
Message-ID: <7D4344E32B34D511A6500002A560C60204D8931B@il-tlv-mail4.comverse.com>
From: Erev Ari <Ari.Erev@comverse.com>
To: "'Mark Crispin'" <mrc@CAC.Washington.EDU>
Cc: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: RE: [lemonade] Mobile messaging clients barriers - Protocls vs. S
	erver Implementation
Date: Sun, 15 Jun 2003 17:26:09 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3334A.10811F80"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3334A.10811F80
Content-Type: text/plain;
	charset="iso-8859-1"

Hi,

Regarding the Proxy suggestion, I have the following question:

Arn't we mixing PROTOCOL with SERVER IMPLEMENTATION?

In other words, if the submit-client talks to the proxy using "IMAP" or
"IMAP with an additional SUBMIT/APPEND/SEND command", isn't this still the
domain of the IMAP PROTOCOL (i.e, to define the extension commands, their
semantics etc.)?

(BTW, if an IMAP server implementation, selects to implement the "Proxy" as
part of the IMAP server itself, would it be a conforming implementation? (I
assume so). If yes, then why do we have to define the proxy as a separate
entity and not only the semantics of the various commands?)

And if, the submit-client talks to the proxy using "SMTP" or "SMTP with
compose using some extenral link semantics", don't we still have the same
security and authentication/authorization issues we would have if the
extended functionality would have been added to an SMTP (submit) server (for
the Proxy to authenticate, get message data, etc. from the IMAP server)?

And if we invent a new protocol for the submit-client to talk to the proxy,
other than SMTP or IMAP,  doesn't it bring back the "Submit Client needs to
support two submit protocols" problem?

So, the bottom line, is that I need some help to better understand what the
proxy idea buys us (for the "Forward without Download" requirement).

Ari


> -----Original Message-----
> From: Mark Crispin [mailto:mrc@CAC.Washington.EDU]
> Sent: Saturday, June 14, 2003 7:01 PM
> To: Cyrus Daboo
> Cc: Mendelovich Meir; IETF LEMONADE (E-mail)
> Subject: Re: [lemonade] Mobile messaging clients barriers
> 
> 
> On Sat, 14 Jun 2003, Cyrus Daboo wrote:
> > A good solution to this is to have a proxy which is in 
> effect an imap
> > client on one end (that maintains the server connection and 
> caches mailbox
> > data), and a server (of some sort) on the other. One could 
> then access this
> > proxy by regular IMAP, mIMAP, HTTP, or any other mechanism 
> that would make
> > sense. The proxy could then handle composition/submission 
> etc as already
> > discussed. I think there is at least one simple connection 
> caching proxy
> > that's being used with webmail solutions right now.
> 
> This sounds like a concensus is forming around developing 
> this proxy --
> which will provide multiple necessary services for mobile clients
> including submit -- and NOT to hammer all this into IMAP.
> 
> -- 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
> 

------_=_NextPart_001_01C3334A.10811F80
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: [lemonade] Mobile messaging clients barriers - Protocls vs. =
Server Implementation</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi,</FONT>
</P>

<P><FONT SIZE=3D2>Regarding the Proxy suggestion, I have the following =
question:</FONT>
</P>

<P><FONT SIZE=3D2>Arn't we mixing PROTOCOL with SERVER =
IMPLEMENTATION?</FONT>
</P>

<P><FONT SIZE=3D2>In other words, if the submit-client talks to the =
proxy using &quot;IMAP&quot; or &quot;IMAP with an additional =
SUBMIT/APPEND/SEND command&quot;, isn't this still the domain of the =
IMAP PROTOCOL (i.e, to define the extension commands, their semantics =
etc.)?</FONT></P>

<P><FONT SIZE=3D2>(BTW, if an IMAP server implementation, selects to =
implement the &quot;Proxy&quot; as part of the IMAP server itself, =
would it be a conforming implementation? (I assume so). If yes, then =
why do we have to define the proxy as a separate entity and not only =
the semantics of the various commands?)</FONT></P>

<P><FONT SIZE=3D2>And if, the submit-client talks to the proxy using =
&quot;SMTP&quot; or &quot;SMTP with compose using some extenral link =
semantics&quot;, don't we still have the same security and =
authentication/authorization issues we would have if the extended =
functionality would have been added to an SMTP (submit) server (for the =
Proxy to authenticate, get message data, etc. from the IMAP =
server)?</FONT></P>

<P><FONT SIZE=3D2>And if we invent a new protocol for the submit-client =
to talk to the proxy, other than SMTP or IMAP,&nbsp; doesn't it bring =
back the &quot;Submit Client needs to support two submit =
protocols&quot; problem?</FONT></P>

<P><FONT SIZE=3D2>So, the bottom line, is that I need some help to =
better understand what the proxy idea buys us (for the &quot;Forward =
without Download&quot; requirement).</FONT></P>

<P><FONT SIZE=3D2>Ari</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Mark Crispin [<A =
HREF=3D"mailto:mrc@CAC.Washington.EDU">mailto:mrc@CAC.Washington.EDU</A>=
]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Saturday, June 14, 2003 7:01 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Cyrus Daboo</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: Mendelovich Meir; IETF LEMONADE =
(E-mail)</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [lemonade] Mobile messaging =
clients barriers</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; On Sat, 14 Jun 2003, Cyrus Daboo wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; A good solution to this is to have a proxy =
which is in </FONT>
<BR><FONT SIZE=3D2>&gt; effect an imap</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; client on one end (that maintains the =
server connection and </FONT>
<BR><FONT SIZE=3D2>&gt; caches mailbox</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; data), and a server (of some sort) on the =
other. One could </FONT>
<BR><FONT SIZE=3D2>&gt; then access this</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; proxy by regular IMAP, mIMAP, HTTP, or any =
other mechanism </FONT>
<BR><FONT SIZE=3D2>&gt; that would make</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; sense. The proxy could then handle =
composition/submission </FONT>
<BR><FONT SIZE=3D2>&gt; etc as already</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; discussed. I think there is at least one =
simple connection </FONT>
<BR><FONT SIZE=3D2>&gt; caching proxy</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; that's being used with webmail solutions =
right now.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; This sounds like a concensus is forming around =
developing </FONT>
<BR><FONT SIZE=3D2>&gt; this proxy --</FONT>
<BR><FONT SIZE=3D2>&gt; which will provide multiple necessary services =
for mobile clients</FONT>
<BR><FONT SIZE=3D2>&gt; including submit -- and NOT to hammer all this =
into IMAP.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -- Mark --</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; <A HREF=3D"http://staff.washington.edu/mrc" =
TARGET=3D"_blank">http://staff.washington.edu/mrc</A></FONT>
<BR><FONT SIZE=3D2>&gt; Science does not emerge from voting, party =
politics, or public debate.</FONT>
<BR><FONT SIZE=3D2>&gt; Si vis pacem, para bellum.</FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; lemonade mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; lemonade@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/lemonade" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/lemonade</A></F=
ONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C3334A.10811F80--
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Sun Jun 15 17:50:52 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11738
	for <lemonade-archive@odin.ietf.org>; Sun, 15 Jun 2003 17:50:52 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5FLoPV28448
	for lemonade-archive@odin.ietf.org; Sun, 15 Jun 2003 17:50:25 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FLoPm28445
	for <lemonade-web-archive@optimus.ietf.org>; Sun, 15 Jun 2003 17:50:25 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11727
	for <lemonade-web-archive@ietf.org>; Sun, 15 Jun 2003 17:50:21 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19RfM9-0005Wj-00
	for lemonade-web-archive@ietf.org; Sun, 15 Jun 2003 17:48:09 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19RfM9-0005Wg-00
	for lemonade-web-archive@ietf.org; Sun, 15 Jun 2003 17:48:09 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FKV0a23027;
	Sun, 15 Jun 2003 16:31:00 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FKUfm22983
	for <lemonade@optimus.ietf.org>; Sun, 15 Jun 2003 16:30:41 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10278
	for <lemonade@ietf.org>; Sun, 15 Jun 2003 16:30:39 -0400 (EDT)
From: hardie@qualcomm.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Re71-00059d-00
	for lemonade@ietf.org; Sun, 15 Jun 2003 16:28:27 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Re70-00059Z-00
	for lemonade@ietf.org; Sun, 15 Jun 2003 16:28:26 -0400
Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149])
	by numenor.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h5FKUXxO008615
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Sun, 15 Jun 2003 13:30:34 -0700 (PDT)
Received: from [205.214.163.27] (vpn-10-50-0-80.qualcomm.com [10.50.0.80])
	by neophyte.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h5FKURuh011727;
	Sun, 15 Jun 2003 13:30:28 -0700 (PDT)
Mime-Version: 1.0
X-Sender: hardie@mage.qualcomm.com
Message-Id: <p06001201bb128284b404@[205.214.163.27]>
In-Reply-To: <Pine.NXT.4.56.0306150758140.11845@Ikkoku-Kan.Panda.COM>
References: 
 <7D4344E32B34D511A6500002A560C60204D8931B@il-tlv-mail4.comverse.com>
 <Pine.NXT.4.56.0306150758140.11845@Ikkoku-Kan.Panda.COM>
Date: Sun, 15 Jun 2003 13:30:28 -0700
To: Mark Crispin <mrc@CAC.Washington.EDU>, Erev Ari <Ari.Erev@comverse.com>
Subject: RE: [lemonade] Mobile messaging clients barriers - Protocls vs. S
  erver Implementation
Cc: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

Folks,
	I believe that Erev is making a very important point that
we should not pass by so quickly.  The group's charter has as deliverable 0:

0. An informational RFC or RFCs will be produced on LEMONADE
architecture and the issues it seeks to address.

	It may be that the term "architecture" in deliverable 0 has
caused folks to consider server architectures and message stores
as the key initial consideration.  That's now how I understand them,
though, and I suspect that the reading Erev gives--that the group
is meant to be discussing protocol architecture--is closer to the
mark.  Re-reading all of the charter text (something I highly recommend
to anyone), the very first sentences are:

Lemonade is tasked to provide a set of enhancements and profiles of
Internet email submission, transport, and retrieval protocols to
facilitate operation on platforms with constrained resources, or
communications links with high latency or limited bandwidth. A primary
goal of this work is to ensure that those profiles and enhancements
continue to interoperate with the existing Internet email protocols in
use on the Internet, so that these environments and more traditional
Internet users have access to a seamless service.

	Much of the discussion of the past few days makes me
very uneasy about the group's focus on the primary goal of interoperability.
The proxy notions in Cyrus's recent email (using http, mIMAP, and IMAP
to access the proxy, for example) don't look terribly interoperable, and
statements like "The beauty of  the proxy method is that it works
with all existing servers." seem to indicate that interopability will be
achieved by introducing an entirely new network element for messaging,
with an entirely new protocol in support of client-server communication
with that element, plus a set of protocol enhancements to support
the interaction of that new element and the existing elements.
	That sounds a bit fragile as a way forward, to put it mildly.
It also sounds like developing a proxy for interaction with any
potential source of data to be included in a message is outside
of the current charter.
	I encourage those who have put forward straw proposals
to the group to get them into I-D form, however rough they may
be.  I also encourage those taking on that work to re-read the
charter as they do that writing.
			regards,
				Ted Hardie



At 8:17 AM -0700 6/15/03, Mark Crispin wrote:
>On Sun, 15 Jun 2003, Erev Ari wrote:
>  > Arn't we mixing PROTOCOL with SERVER IMPLEMENTATION?
>>  In other words, if the submit-client talks to the proxy using "IMAP" or
>>  "IMAP with an additional SUBMIT/APPEND/SEND command", isn't this still the
>>  domain of the IMAP PROTOCOL (i.e, to define the extension commands, their
>>  semantics etc.)?
>
>Not at all.
>
>The proxy would be on a different port, and leaves open the possibility in
>the future for extensibility to provide other non-IMAP services.
>
>It may be convenient for you to think of it is "an extension of IMAP"; and
>if it serves that purpose in a useful way for you, that would be a good
>outcome.
>
>  > And if, the submit-client talks to the proxy using "SMTP" or "SMTP with
>>  compose using some extenral link semantics", don't we ...
>...snip...
>>... would have been added to an SMTP (submit) server (for
>>  the Proxy to authenticate, get message data, etc. from the IMAP server)?
>
>No, because those issues are already being addressed elsewhere.  The proxy
>method means that the mobile device doesn't have to deal with it.
>
>  > And if we invent a new protocol for the submit-client to talk to the proxy,
>>  other than SMTP or IMAP,  doesn't it bring back the "Submit Client needs to
>>  support two submit protocols" problem?
>
>What happens if your customers have a requirement to work in an existing
>enterprise infrastructure?
>
>You can't escape the "support two submit protocols" problem without a
>proxy; and if your client won't work with a non-extended server then your
>client's success depends upon the whim of the server managers.
>
>The beauty of the proxy method is that it works with all existing servers.
>
>-- 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

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



From mailnull@www1.ietf.org  Sun Jun 15 18:13:26 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13047
	for <lemonade-archive@odin.ietf.org>; Sun, 15 Jun 2003 18:13:26 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5FMCxi30231
	for lemonade-archive@odin.ietf.org; Sun, 15 Jun 2003 18:12:59 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FMCxm30228
	for <lemonade-web-archive@optimus.ietf.org>; Sun, 15 Jun 2003 18:12:59 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12991
	for <lemonade-web-archive@ietf.org>; Sun, 15 Jun 2003 18:12:55 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Rfhz-0005f6-00
	for lemonade-web-archive@ietf.org; Sun, 15 Jun 2003 18:10:43 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Rfhz-0005f3-00
	for lemonade-web-archive@ietf.org; Sun, 15 Jun 2003 18:10:43 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FKb0a23143;
	Sun, 15 Jun 2003 16:37:00 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FKapm23105
	for <lemonade@optimus.ietf.org>; Sun, 15 Jun 2003 16:36:51 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10346
	for <lemonade@ietf.org>; Sun, 15 Jun 2003 16:36:49 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19ReCz-0005Ad-00
	for lemonade@ietf.org; Sun, 15 Jun 2003 16:34:37 -0400
Received: from inet-consulting.com ([4.23.9.166] helo=royer.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19ReCx-0005Aa-00
	for lemonade@ietf.org; Sun, 15 Jun 2003 16:34:35 -0400
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h5FKaebt012887
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <lemonade@ietf.org>; Sun, 15 Jun 2003 13:36:46 -0700
Message-ID: <3EECD8CD.1030300@Royer.com>
Date: Sun, 15 Jun 2003 14:36:29 -0600
From: Doug Royer <Doug@Royer.com>
Reply-To: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: Re: [lemonade] Mobile messaging clients barriers - Protocls vs. S
 erver Implementation
References: <7D4344E32B34D511A6500002A560C60204D8931B@il-tlv-mail4.comverse.com> <Pine.NXT.4.56.0306150758140.11845@Ikkoku-Kan.Panda.COM>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010503080308040704000608"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This is a cryptographically signed message in MIME format.

--------------ms010503080308040704000608
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Mark Crispin wrote:
> On Sun, 15 Jun 2003, Erev Ari wrote:
> 
>>Arn't we mixing PROTOCOL with SERVER IMPLEMENTATION?
>>In other words, if the submit-client talks to the proxy using "IMAP" or
>>"IMAP with an additional SUBMIT/APPEND/SEND command", isn't this still the
>>domain of the IMAP PROTOCOL (i.e, to define the extension commands, their
>>semantics etc.)?
> 
> 
> Not at all.
> 
> The proxy would be on a different port, and leaves open the possibility in
> the future for extensibility to provide other non-IMAP services.

Or it could be on the same port with the real IMAP server hidden
from the client. As long as it passes the IMAP data through, no
existing client would know the difference. And having it on
the same port and just advertising a new capability would
make the same server (hardware) available to old and new clients.

When my Unix application connects to 993 it would not care
about the wire protocol extension. When my TCP aware cell phone
connects to exactly the same system and port it uses the
new extension with the 'real' IMAP server never knowing.

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  Doug@Royer.com                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

--------------ms010503080308040704000608
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC
A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j
cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB
MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T
BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN
VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre
qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+
5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA
MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg
TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD
QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx
ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz
IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq
hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34
1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA
gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK
YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd
SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC
AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF
BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl
cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl
IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs
MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq
1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2
TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail
MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE
AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO
b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG
MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD
VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV
BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv
43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y
lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP
D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn
0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK
bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg
hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT
IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI
AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t
L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk
OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW
yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1
MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl
ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTUyMDM2MzBaMCMGCSqGSIb3DQEJBDEWBBRA
PODhUKMzm//57OcSwIN5Z3kPJTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL
KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAZlcIQ7bylaEu
hbS78fGi+ycouykMsyi1F0xXyCvn/OTMIDk6gR1HCr8RQ/KQwVPFckVPq6Xc4P5KeX8ObeD9
/20+7qosrKDlQZeixgZhOKUktcBp8zhpMB3dYP0VCl8mgWZdNRNEoPdiK32zbeppgBNOpsrf
nwx/4R51l1UL83OmLt7QJo3tSTqVJvKzfGvaeSXWLWxlKY+klBx4otHbaKlDmkn6Q9eF2OdT
3X5Uz+VlbfbH88IUGCojPMfGalIVGH+G/s3L0uvor8RikaxlKMYiZPU3qjc12BRA75ykprkL
oxVP1PGnROPqli6rVYJVc1WyeF+65YgtAWgNdYY+MwAAAAAAAA==
--------------ms010503080308040704000608--

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



From mailnull@www1.ietf.org  Sun Jun 15 21:18:03 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16019
	for <lemonade-archive@odin.ietf.org>; Sun, 15 Jun 2003 21:18:03 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5G1HZ008980
	for lemonade-archive@odin.ietf.org; Sun, 15 Jun 2003 21:17:35 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G1HZm08977
	for <lemonade-web-archive@optimus.ietf.org>; Sun, 15 Jun 2003 21:17:35 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16016
	for <lemonade-web-archive@ietf.org>; Sun, 15 Jun 2003 21:17:32 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Riad-0006Ks-00
	for lemonade-web-archive@ietf.org; Sun, 15 Jun 2003 21:15:19 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Riad-0006Kp-00
	for lemonade-web-archive@ietf.org; Sun, 15 Jun 2003 21:15:19 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FLc1a28014;
	Sun, 15 Jun 2003 17:38:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FLbZm28001
	for <lemonade@optimus.ietf.org>; Sun, 15 Jun 2003 17:37:35 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11448
	for <lemonade@ietf.org>; Sun, 15 Jun 2003 17:37:32 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Rf9k-0005Sc-00
	for lemonade@ietf.org; Sun, 15 Jun 2003 17:35:20 -0400
Received: from inet-consulting.com ([4.23.9.166] helo=royer.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Rf9j-0005SZ-00
	for lemonade@ietf.org; Sun, 15 Jun 2003 17:35:19 -0400
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h5FLbPbt013315
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <lemonade@ietf.org>; Sun, 15 Jun 2003 14:37:31 -0700
Message-ID: <3EECE708.1030204@Royer.com>
Date: Sun, 15 Jun 2003 15:37:12 -0600
From: Doug Royer <Doug@Royer.com>
Reply-To: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: Re: [lemonade] Mobile messaging clients barriers - Protocls vs. S
 erver Implementation
References: <7D4344E32B34D511A6500002A560C60204D8931B@il-tlv-mail4.comverse.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070405070307060103080304"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This is a cryptographically signed message in MIME format.

--------------ms070405070307060103080304
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Erev Ari wrote:

> 
> And if, the submit-client talks to the proxy using "SMTP" or "SMTP with 
> compose using some extenral link semantics", don't we still have the 
> same security and authentication/authorization issues we would have if 
> the extended functionality would have been added to an SMTP (submit) 
> server (for the Proxy to authenticate, get message data, etc. from the 
> IMAP server)?

No, because the proxy could use its credentials when connecting
to the SMTP server. And that SMTP server could allow relaying
to that authenticated proxy server.

The SMTP server would not have to 'get' a message from the IMAP server
because:

  The proxy server would do the 'get' from its own IMAP server.
  (This WG seem to be in favor of all forwards and body parts
   coming from the currently authenticated IMAP users mailbox anyway.)

  The proxy itself would do the inline expansion of the included
  body part.

  The proxy server could setup the email headers to show the
  correct user, site, ... to match the currently IMAP authenticated
  user.

The proxy server could then just do standard [E]SMTP to the SMTP server.

> And if we invent a new protocol for the submit-client to talk to the 
> proxy, other than SMTP or IMAP,  doesn't it bring back the "Submit 
> Client needs to support two submit protocols" problem?

My initial guess is that it could look like the 'append' command
except be called 'submit'. The new IMAP clients would only
have to format the message and do a 'submit' command.

> So, the bottom line, is that I need some help to better understand what 
> the proxy idea buys us (for the "Forward without Download" requirement).

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  Doug@Royer.com                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

--------------ms070405070307060103080304
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC
A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j
cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB
MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T
BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN
VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre
qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+
5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA
MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg
TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD
QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx
ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz
IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq
hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34
1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA
gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK
YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd
SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC
AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF
BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl
cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl
IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs
MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq
1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2
TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail
MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE
AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO
b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG
MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD
VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV
BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv
43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y
lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP
D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn
0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK
bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg
hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT
IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI
AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t
L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk
OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW
yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1
MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl
ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTUyMTM3MTJaMCMGCSqGSIb3DQEJBDEWBBRv
MY0UCIdua7/7Rf0QYEDc5TEBEDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL
KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAp5lYkbrHZt+3
kkJCUrS/luI4l4BtOXlq7kyz0BHT1WfehgnsKxfHutDBrZN3I3jh+nG1Sg0QVx0dQO603bdX
XRmWhJopbWAaJ9zPfU7tQcKvxfRw0QXh6L8xpYn269mcSYd0kiYRpfdg+6xOjA43b84aFQrS
f8rLZ1vGFMJgQHWnes0pD3dHK3rnGoX6BSGWswA7TMQKwcKbourM77LLiBi6pkK2SV3P8UZE
hb0VJcMCzmD3EMWGSwvnVq7eM7q4Z5GTMp104W/yIQ7URPsAnHANjsJjHaAtqOWG4f1LsVXW
/jTPX8yLj9fnLdWL9f0PdHjsEGLI9MoUjOV1HvxLywAAAAAAAA==
--------------ms070405070307060103080304--

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



From mailnull@www1.ietf.org  Sun Jun 15 21:36:34 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16307
	for <lemonade-archive@odin.ietf.org>; Sun, 15 Jun 2003 21:36:34 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5G1a6e09507
	for lemonade-archive@odin.ietf.org; Sun, 15 Jun 2003 21:36:06 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G1a6m09504
	for <lemonade-web-archive@optimus.ietf.org>; Sun, 15 Jun 2003 21:36:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16297
	for <lemonade-web-archive@ietf.org>; Sun, 15 Jun 2003 21:36:04 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19RisZ-0006OK-00
	for lemonade-web-archive@ietf.org; Sun, 15 Jun 2003 21:33:51 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19RisY-0006OH-00
	for lemonade-web-archive@ietf.org; Sun, 15 Jun 2003 21:33:50 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FNP1a01728;
	Sun, 15 Jun 2003 19:25:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FNOdm01709
	for <lemonade@optimus.ietf.org>; Sun, 15 Jun 2003 19:24:39 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14127
	for <lemonade@ietf.org>; Sun, 15 Jun 2003 19:24:37 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19RgpN-0005qp-00
	for lemonade@ietf.org; Sun, 15 Jun 2003 19:22:25 -0400
Received: from panda.com
	([206.124.149.114] helo=Ikkoku-Kan.Panda.COM ident=noodle)
	by ietf-mx with esmtp (Exim 4.12)
	id 19RgpM-0005qm-00
	for lemonade@ietf.org; Sun, 15 Jun 2003 19:22:24 -0400
Received: from localhost (mrc@localhost) by Ikkoku-Kan.Panda.COM id QAA28671; Sun, 15 Jun 2003 16:24:35 -0700 (PDT)
Date: Sun, 15 Jun 2003 16:24:34 -0700 (PDT)
From: Mark Crispin <mrc@CAC.Washington.EDU>
To: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: Re: [lemonade] Mobile messaging clients barriers - Protocls vs. S
 erver Implementation
In-Reply-To: <3EECD8CD.1030300@Royer.com>
Message-ID: <Pine.NXT.4.56.0306151527450.11845@Ikkoku-Kan.Panda.COM>
References: <7D4344E32B34D511A6500002A560C60204D8931B@il-tlv-mail4.comverse.com>
 <Pine.NXT.4.56.0306150758140.11845@Ikkoku-Kan.Panda.COM> <3EECD8CD.1030300@Royer.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Sun, 15 Jun 2003, Doug Royer wrote:
> Or it could be on the same port with the real IMAP server hidden
> from the client. As long as it passes the IMAP data through, no
> existing client would know the difference.

Using the same port has the effect of constraining the mobile client to
accept IMAP in all its chatty glory; rumors to the contrary
notwithstanding an IMAP client does *not* control what an IMAP server can
wreak.  Unpleasant surprises await client implementors who do not realize
the full implications of the unsolicited data model

Have you considered the impact of RFC 2193 referrals on submit-in-IMAP?
If the server returns a referral, the mobile client must establish a new
IMAP connection to the referred-to server and reissue the submit to that
server.  It is also necessary to constrain submit-in-IMAP to reference
only one mailbox, to prevent unresolvable submissions.

Neither of these are issues with a proxy server on a different port.  The
proxy server can offer guarantees to the mobile client that no unwanted
chat from the IMAP server will reach it; in turn the mobile client can be
programmed with that assumption.  The proxy can also ensure that RFC 2193
referrals do not happen as far as the mobile client is concerned; this
also removes the restriction of only one mailbox reference in a submit.

A mobile client can't count upon any of this if it talks to a raw IMAP
server instead of a proxy.  If you use the same port, only a correct DNS
name stands between the mobile client and that fate.

-- 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 mailnull@www1.ietf.org  Mon Jun 16 03:09:33 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04204
	for <lemonade-archive@odin.ietf.org>; Mon, 16 Jun 2003 03:09:33 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5G795r09859
	for lemonade-archive@odin.ietf.org; Mon, 16 Jun 2003 03:09:05 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G795m09856
	for <lemonade-web-archive@optimus.ietf.org>; Mon, 16 Jun 2003 03:09:05 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04191
	for <lemonade-web-archive@ietf.org>; Mon, 16 Jun 2003 03:09:02 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Ro4m-0000Nt-00
	for lemonade-web-archive@ietf.org; Mon, 16 Jun 2003 03:06:48 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Ro4m-0000Nq-00
	for lemonade-web-archive@ietf.org; Mon, 16 Jun 2003 03:06:48 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G2B1a12364;
	Sun, 15 Jun 2003 22:11:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G2AZm12349
	for <lemonade@optimus.ietf.org>; Sun, 15 Jun 2003 22:10:35 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16899
	for <lemonade@ietf.org>; Sun, 15 Jun 2003 22:10:32 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19RjPw-0006WG-00
	for lemonade@ietf.org; Sun, 15 Jun 2003 22:08:20 -0400
Received: from inet-consulting.com ([4.23.9.166] helo=royer.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19RjPu-0006WD-00
	for lemonade@ietf.org; Sun, 15 Jun 2003 22:08:18 -0400
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h5G2APbt015436
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <lemonade@ietf.org>; Sun, 15 Jun 2003 19:10:30 -0700
Message-ID: <3EED2703.3010103@Royer.com>
Date: Sun, 15 Jun 2003 20:10:11 -0600
From: Doug Royer <Doug@Royer.com>
Reply-To: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: Re: [lemonade] Mobile messaging clients barriers - Protocls vs. S
 erver Implementation
References: <7D4344E32B34D511A6500002A560C60204D8931B@il-tlv-mail4.comverse.com> <Pine.NXT.4.56.0306150758140.11845@Ikkoku-Kan.Panda.COM> <3EECD8CD.1030300@Royer.com> <Pine.NXT.4.56.0306151527450.11845@Ikkoku-Kan.Panda.COM>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090503070305030909090404"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This is a cryptographically signed message in MIME format.

--------------ms090503070305030909090404
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Mark Crispin wrote:
> On Sun, 15 Jun 2003, Doug Royer wrote:
> 
>>Or it could be on the same port with the real IMAP server hidden
>>from the client. As long as it passes the IMAP data through, no
>>existing client would know the difference.
> 
> 
> Using the same port has the effect of constraining the mobile client to
> accept IMAP in all its chatty glory; rumors to the contrary
> notwithstanding an IMAP client does *not* control what an IMAP server can
> wreak.  Unpleasant surprises await client implementors who do not realize
> the full implications of the unsolicited data model

The proposal was not to create an new protocol anyway. The e-mail from
Ned suggests exactly that. So - not an issue as we were not proposing
a new wire protocol, just an extension intercepted by a proxy.


> Have you considered the impact of RFC 2193 referrals on submit-in-IMAP?
> If the server returns a referral, the mobile client must establish a new
> IMAP connection to the referred-to server and reissue the submit to that
> server.  It is also necessary to constrain submit-in-IMAP to reference
> only one mailbox, to prevent unresolvable submissions.

Currently ALL imap clients that connect to servers that return
'MAILBOX-REFERRALS' or any other extension would have this problem.
Nothing new.

> Neither of these are issues with a proxy server on a different port. 

The port number has nothing to do with it. It has to do with
submit and forward without download. The proposal was to
transparently forward IMAP commands to and from a real IMAP
server intercepting the SUBMIT command and sending the data
to an SMTP server.

> The
> proxy server can offer guarantees to the mobile client that no unwanted
> chat from the IMAP server will reach it; in turn the mobile client can be
> programmed with that assumption.  The proxy can also ensure that RFC 2193
> referrals do not happen as far as the mobile client is concerned; this
> also removes the restriction of only one mailbox reference in a submit.

This could be done on the same port number by the proxy anyway,
or not done if the client understands MAILBOX-REFERRALS or any
other extension or IMAP feature.

The problem being solved is not how to make the mobile client use
some completely new protocol.

And we are not solving the problem of IMAP clients that do not want
to understand IMAP.

The problem we are solving is how to forward without download.

> A mobile client can't count upon any of this if it talks to a raw IMAP
> server instead of a proxy.  If you use the same port, only a correct DNS
> name stands between the mobile client and that fate.

I have not seen any proposal that prevents a mobile client from talking IMAP
Nor have I seen a proposal for any other IMAP-like protocol.

The proposal is for a proxy that understands how to include messages
for the client and submit while making minimum changes to the wire
protocol which happens to be IMAP.

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  Doug@Royer.com                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

--------------ms090503070305030909090404
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC
A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j
cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB
MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T
BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN
VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre
qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+
5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA
MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg
TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD
QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx
ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz
IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq
hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34
1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA
gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK
YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd
SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC
AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF
BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl
cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl
IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs
MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq
1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2
TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail
MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE
AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO
b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG
MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD
VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV
BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv
43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y
lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP
D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn
0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK
bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg
hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT
IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI
AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t
L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk
OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW
yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1
MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl
ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTYwMjEwMTFaMCMGCSqGSIb3DQEJBDEWBBRi
RnBKFrjTEX9tJX+9acn1JDJJ4zBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL
KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAZiOJ2HsV38ZX
mUJRIYuPv7igmxwtvsIaiWfYw+cm+X+50We+FMQX3cZJsldlBht8YAlyUpy777FQ3CQZp7Zp
SHYT3lI6NaB9hbCqPUhT2Pz7L+4VVPqH8woHirML0aMRUGoIfvkIKmvaDfPeAnRpwVeu+St+
do81GojhW1lCB3vnztNHESl/UXlz96uYAzMsyP1P4o3rPoPI63s1ErnEgfoL4aGSEyqiO5Nd
9aQdpaiNxOR+7RfPPtwAWdqeVv3/Jqv4fNQQkv19pM1J3SkdWd8pToZVChreoxtEQmJNlo58
P2JC4ZN59PlZSkf1ilGtYY0YsOJ1c1PC8b+ydW0l6AAAAAAAAA==
--------------ms090503070305030909090404--

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



From mailnull@www1.ietf.org  Mon Jun 16 09:57:32 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14040
	for <lemonade-archive@odin.ietf.org>; Mon, 16 Jun 2003 09:57:32 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5GDv5k04410
	for lemonade-archive@odin.ietf.org; Mon, 16 Jun 2003 09:57:05 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GDv4m04407
	for <lemonade-web-archive@optimus.ietf.org>; Mon, 16 Jun 2003 09:57:04 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14037
	for <lemonade-web-archive@ietf.org>; Mon, 16 Jun 2003 09:57:01 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19RuRb-0002mk-00
	for lemonade-web-archive@ietf.org; Mon, 16 Jun 2003 09:54:47 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19RuRb-0002mg-00
	for lemonade-web-archive@ietf.org; Mon, 16 Jun 2003 09:54:47 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G831a13183;
	Mon, 16 Jun 2003 04:03:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G825m12925
	for <lemonade@optimus.ietf.org>; Mon, 16 Jun 2003 04:02:05 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04950
	for <lemonade@ietf.org>; Mon, 16 Jun 2003 04:02:03 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Rou5-0000ab-00
	for lemonade@ietf.org; Mon, 16 Jun 2003 03:59:49 -0400
Received: from comversegw.icomverse.com ([192.118.48.248] helo=il-tlv-smtpout2.icomverse.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Rou4-0000aY-00
	for lemonade@ietf.org; Mon, 16 Jun 2003 03:59:48 -0400
Received: from il-tlv-mbdg1.comverse.com (localhost.localdomain [127.0.0.1])
	by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id h5G81Wl06463;
	Mon, 16 Jun 2003 11:01:33 +0300
Received: by il-tlv-mbdg1.comverse.com with Internet Mail Service (5.5.2655.55)
	id <M2S5LJNN>; Mon, 16 Jun 2003 11:01:37 +0300
Message-ID: <E1542177268FD511866B0002A560C8080512E90C@il-tlv-mail5.comverse.com>
From: Mendelovich Meir <Meir.Mendelovich@comverse.com>
To: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>, ned.freed@mrochek.com,
        "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: RE: [lemonade] Mobile messaging clients barriers - IMAP4 "passiva
	tion"
Date: Mon, 16 Jun 2003 11:01:34 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C333DD.811439E2"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C333DD.811439E2
Content-Type: text/plain;
	charset="windows-1255"

Hi,
 
 I want to reply to Greg and Ned about the session maintenance issue.
 
 Mobile clients are working in very "noisy" environments: they change cells,
bearers and sometimes get out of signal. Every time that there is a sudden
momentary disconnection, the old session hangs and new one should be
initiated. Though part of the problem would be solved by underlying
standards like mobile IP, disconnections will still be a problem.
 
We solved it by building proxy that gets HTTP requests and translate them to
IMAP4. But, if the IMAP4 will include a mechanism to "passivate" a session
and reinitiate; it will scientifically improve the system. It is also very
useful in WebMail environments where the server want to reduce the number of
open IMAP4 connections by passivating sessions.
 
About the RSERPOOL WG: If I understand their goals correctly, they try to
solve the problem of server availability. We are having problems with the
connection availability.
 
        Meir :->
 


-----Original Message-----
From: ned.freed@mrochek.com [ <mailto:ned.freed@mrochek.com>
mailto:ned.freed@mrochek.com] 
Sent: Sunday, June 15, 2003 6:33 PM
To: Lawrence Greenfield
Cc: Pete Resnick; Mark Crispin; IETF LEMONADE (E-mail)
Subject: Re: [lemonade] Mobile messaging clients barriers

 
I also would like to understand the long running session / session
initiation issue(s). I will also point out that if reliable connections to
servers really are an issue there is an entire IETF WG devoted to solving
this particular

problem:

 <http://www.ietf.org/html.charters/rserpool-charter.html>
http://www.ietf.org/html.charters/rserpool-charter.html

If the WG decides that work in this space is in order the RSERPOOL approach
needs to at least be considered.

 
 -----Original Message-----
From: Vaudreuil, Greg M (Greg) [mailto:gregv@lucent.com] 
Sent: Friday, June 13, 2003 10:59 PM
To: 'Mendelovich Meir'; IETF LEMONADE (E-mail)
Subject: RE: [lemonade] Mobile messaging clients barriers


It sounds like you are asking for an IMAP "session" to extend across
multiple short-lived TCP connections?   Can you elaborate on why leaving the
TCP connection open is a burden for the client.... is it that a wireless
circuit must be maintained?  The cost of the TCP keep-alives?    
 
If the desire is to reduce the cost of "checking messages" over a circuit
data session, then something like a suspend command that would return from
the server a session token would be useful.  A new message-checking action
could rapid-start with this token as a means to access the last shared
state.... maybe check for new messages in just 3-4 round-trips.
 
Greg V.
 
-----Original Message-----
From: Mendelovich Meir [mailto:Meir.Mendelovich@comverse.com]
Sent: Friday, June 13, 2003 4:55 AM
To: IETF LEMONADE (E-mail)
Subject: [lemonade] Mobile messaging clients barriers



Hi, 
 I'm very happy to see that a consensus is forming about the need to add
message submission to IMAP4. 
 But, this is only one of several barriers that prevent us from building
good mobile messaging clients. I want to raise two major problems. All the
details are in section 7.1 of the requirements document that was presented
by Wong and me in San-Francisco (
<http://www.ietf.org/internet-drafts/draft-wong-umcli-02.txt>
http://www.ietf.org/internet-drafts/draft-wong-umcli-02.txt).

1. As Alan Stebbens mentioned, server-side processing of media is crucial.
We can't download 3 mega pixel image with 30bit color depth to device that
has 100X100 pixels screen and 8bit color depth. We don't expect mail servers
to implement image processing but it is needed to allow IMAP4 servers or
mobile messaging gateways to use external transcoding engines to provide
their mobile client better experience. 

In the MMS arena it is very hot issue. OMA prepares now a standard interface
for transcoding servers. 

2. It is very hard to maintain long sessions in mobile networks. The current
statefull nature of IMAP4 prevent many clients from providing good
experience. Most of the mobile handsets that has IMAP4 client open and close
new session for each command. This kind of behaviour cause enormous load on
the server and spend lots of bandwidth. We MUST solve this problem if we
want to see real mobile e-mail solution in GPRS and CDMA1X networks.

From our experience in mobile messaging clients these two problems must be
solve to fulfill the LEMONADE goals. 

        Meir :-> 

__________________________________ 

Meir Mendelovich 
Product Engineer 
Comverse 
              
Tel:     +972-3-765 5834 
Cell:    +972-5854-3834 
Fax:    +972-3-765 5834 
E-mail: meir_m@mail.com 





------_=_NextPart_001_01C333DD.811439E2
Content-Type: text/html;
	charset="windows-1255"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1255">
<TITLE>Message</TITLE>

<META content="MSHTML 5.00.3513.900" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#800000 face="Arial (Hebrew)" size=2><SPAN 
class=256312607-16062003>Hi,</SPAN></FONT></DIV>
<DIV><FONT color=#800000 face="Arial (Hebrew)" size=2><SPAN 
class=256312607-16062003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#800000 face="Arial (Hebrew)" size=2><SPAN 
class=256312607-16062003>&nbsp;I want to reply to Greg and Ned about the session 
maintenance issue.</SPAN></FONT></DIV>
<DIV><FONT color=#800000 face="Arial (Hebrew)" size=2><SPAN 
class=256312607-16062003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#800000 face="Arial (Hebrew)" size=2><SPAN 
class=256312607-16062003>&nbsp;Mobile clients are working in very "noisy" 
environments: they change cells, bearers and sometimes get out of signal. Every 
time that there is a sudden momentary disconnection, the old session hangs and 
new one should be initiated. Though part of the problem would be solved by 
underlying standards like mobile IP, disconnections will still be a 
problem.</SPAN></FONT></DIV>
<DIV><FONT color=#800000 face="Arial (Hebrew)" size=2><SPAN 
class=256312607-16062003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#800000 face="Arial (Hebrew)" size=2><SPAN 
class=256312607-16062003>We solved it by building proxy that gets HTTP requests 
and translate&nbsp;them to IMAP4. But, if the IMAP4 will include a mechanism to 
"passivate" a session and reinitiate; it will scientifically improve the system. 
It is also very useful in WebMail environments where the server want to reduce 
the number of open IMAP4 connections by passivating 
sessions.</SPAN></FONT></DIV>
<DIV><FONT color=#800000 face="Arial (Hebrew)" size=2><SPAN 
class=256312607-16062003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#800000 face="Arial (Hebrew)" size=2><SPAN 
class=256312607-16062003>About the RSERPOOL WG: If I understand&nbsp;their goals 
correctly, they try to solve the problem of server availability. We are having 
problems with the connection availability.</SPAN></FONT></DIV>
<DIV><FONT color=#800000 face="Arial (Hebrew)" size=2><SPAN 
class=256312607-16062003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#800000 face="Arial (Hebrew)" size=2><SPAN 
class=256312607-16062003>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Meir 
:-&gt;</SPAN></FONT></DIV>
<DIV><FONT color=#800000 face="Arial (Hebrew)" size=2><SPAN 
class=256312607-16062003></SPAN></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV></DIV><SPAN class=256312607-16062003>
  <DIV><FONT face=Arial size=2>-----Original Message-----</FONT></DIV>
  <DIV class=OutlookMessageHeader dir=ltr lang=en-us><FONT face=Arial 
  size=2>From: ned.freed@mrochek.com [</FONT><A 
  href="mailto:ned.freed@mrochek.com"><FONT color=#000000 face=Arial 
  size=2>mailto:ned.freed@mrochek.com</FONT></A><FONT face=Arial size=2>] 
  </FONT></DIV>
  <DIV class=OutlookMessageHeader dir=ltr lang=en-us><FONT face=Arial 
  size=2>Sent: Sunday, June 15, 2003 6:33 PM</FONT></DIV>
  <DIV class=OutlookMessageHeader dir=ltr lang=en-us><FONT face=Arial size=2>To: 
  Lawrence Greenfield</FONT></DIV>
  <DIV class=OutlookMessageHeader dir=ltr lang=en-us><FONT face=Arial size=2>Cc: 
  Pete Resnick; Mark Crispin; IETF LEMONADE (E-mail)</FONT></DIV>
  <DIV class=OutlookMessageHeader dir=ltr lang=en-us><FONT face=Arial 
  size=2>Subject: Re: [lemonade] Mobile messaging clients 
  barriers</FONT></DIV><FONT size=2><FONT face=Arial>
  <DIV class=OutlookMessageHeader dir=ltr lang=en-us>&nbsp;</DIV>
  <DIV class=OutlookMessageHeader dir=ltr lang=en-us><FONT size=2>
  <P>I also would like to understand the long running session / session 
  initiation issue(s). I will also point out that if reliable connections to 
  servers really are an issue there is an entire IETF WG devoted to solving this 
  particular</P>
  <P>problem:</P>
  <P></FONT><A 
  href="http://www.ietf.org/html.charters/rserpool-charter.html"><U><FONT 
  color=#0000ff 
  size=2>http://www.ietf.org/html.charters/rserpool-charter.html</U></FONT></A></P><FONT 
  size=2>
  <P>If the WG decides that work in this space is in order the RSERPOOL approach 
  needs to at least be considered.</P></FONT></SPAN></FONT></FONT></DIV>
  <DIV align=left class=OutlookMessageHeader dir=ltr lang=en-us><FONT 
  size=2><FONT face=Tahoma><SPAN 
  class=256312607-16062003></SPAN></FONT></FONT>&nbsp;</DIV>
  <DIV align=left class=OutlookMessageHeader dir=ltr lang=en-us><FONT 
  size=2><FONT face=Tahoma><SPAN 
  class=256312607-16062003>&nbsp;</SPAN>-----Original 
  Message-----<BR><B>From:</B> Vaudreuil, Greg M (Greg) 
  [mailto:gregv@lucent.com] <BR><B>Sent:</B> Friday, June 13, 2003 10:59 
  PM<BR><B>To:</B> 'Mendelovich Meir'; IETF LEMONADE (E-mail)<BR><B>Subject:</B> 
  RE: [lemonade] Mobile messaging clients barriers<BR><BR></DIV></FONT></FONT>
  <DIV><SPAN class=740565219-13062003><FONT color=#0000ff face=Arial size=2>It 
  sounds like you are asking for&nbsp;an IMAP "session"&nbsp;to extend across 
  multiple short-lived TCP connections?&nbsp;&nbsp; </FONT></SPAN><SPAN 
  class=740565219-13062003><FONT color=#0000ff face=Arial size=2>Can you 
  elaborate on why leaving the TCP connection open is a burden for the 
  client.... is it that a wireless circuit must be maintained?&nbsp; The cost of 
  the TCP keep-alives?&nbsp;&nbsp;&nbsp; </FONT></SPAN></DIV>
  <DIV><SPAN class=740565219-13062003><FONT color=#0000ff face=Arial 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=740565219-13062003><FONT color=#0000ff face=Arial size=2>If 
  the desire is to reduce the cost of "checking messages" over a circuit data 
  session, then something like a suspend command that would return from the 
  server a session token would be useful.&nbsp; A new message-checking action 
  could rapid-start with this token as a means to access the last shared 
  state.... maybe check for new messages in just 3-4 
  round-trips.</FONT></SPAN></DIV>
  <DIV><SPAN class=740565219-13062003><FONT color=#0000ff face=Arial 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=740565219-13062003><FONT color=#0000ff face=Arial size=2>Greg 
  V.</FONT></SPAN></DIV>
  <DIV><SPAN class=740565219-13062003><FONT color=#0000ff face=Arial 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=740565219-13062003></SPAN><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Mendelovich Meir 
  [mailto:Meir.Mendelovich@comverse.com]<BR><B>Sent:</B> Friday, June 13, 2003 
  4:55 AM<BR><B>To:</B> IETF LEMONADE (E-mail)<BR><B>Subject:</B> [lemonade] 
  Mobile messaging clients barriers<BR><BR></DIV></FONT>
  <BLOCKQUOTE>
    <P><FONT face=Arial size=2>Hi,</FONT> <BR><FONT face=Arial size=2>&nbsp;I'm 
    very happy to see that a consensus is forming about the need to add message 
    submission to IMAP4.</FONT> <BR><FONT face=Arial size=2>&nbsp;But, this is 
    only one of several barriers that prevent us from building good mobile 
    messaging clients. I want to raise two major problems. All the details are 
    in section 7.1 of the requirements document that was presented by Wong and 
    me in San-Francisco (</FONT><A 
    href="http://www.ietf.org/internet-drafts/draft-wong-umcli-02.txt"><U><FONT 
    color=#0000ff face=Arial 
    size=2>http://www.ietf.org/internet-drafts/draft-wong-umcli-02.txt</FONT></U></A><FONT 
    face=Arial size=2>).</FONT></P>
    <P><FONT face=Arial size=2>1. As Alan</FONT><FONT face=Arial size=2> 
    Stebbens</FONT> <FONT face=Arial size=2>mentioned, server-side processing of 
    media is crucial. We can't download 3 mega pixel image with 30bit color 
    depth to device that has 100X100 pixels screen and 8bit color depth. We 
    don't expect mail servers to implement image processing but it is needed to 
    allow IMAP4 servers or mobile messaging gateways to use external transcoding 
    engines to provide their mobile client better experience. </FONT></P>
    <P><FONT face=Arial size=2>In the MMS arena it is very hot issue. OMA 
    prepares now a standard interface for transcoding servers.</FONT> </P>
    <P><FONT face=Arial size=2>2. It is very hard to maintain long sessions in 
    mobile networks. The current statefull nature of IMAP4 prevent many clients 
    from providing good experience. Most of the mobile handsets that has IMAP4 
    client open and close new session for each command. This kind of behaviour 
    cause enormous load on the server and spend lots of bandwidth. We MUST solve 
    this problem if we want to see real mobile e-mail solution in GPRS and 
    CDMA1X networks.</FONT></P>
    <P><FONT face=Arial size=2>From our experience in mobile messaging clients 
    these two problems must be solve to fulfill the LEMONADE goals.</FONT> </P>
    <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial size=2>Meir 
    :-&gt;</FONT> </P>
    <P><FONT color=#3366ff face=Arial 
    size=2>__________________________________</FONT> </P>
    <P><B><FONT color=#000080 face=Arial size=2>Meir Mendelovich</FONT></B> 
    <BR><FONT color=#000080 face=Arial size=2>Product Engineer</FONT> <BR><FONT 
    color=#000080 face=Arial size=2>Comverse</FONT> <BR><FONT face=Arial 
    size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT><B> 
    </B><BR><B><FONT color=#808080 face=Arial size=2>Tel:</FONT></B><FONT 
    face=Arial size=2>&nbsp;&nbsp;&nbsp;&nbsp; </FONT><FONT color=#993300 
    face=Arial size=2>+972-3-765 5834</FONT> <BR><B><FONT color=#808080 
    face=Arial size=2>Cell:</FONT><FONT face=Arial size=2></FONT></B> <FONT 
    face=Arial size=2>&nbsp;&nbsp; </FONT><FONT color=#993300 face=Arial 
    size=2>+972-5854-3834</FONT> <BR><B><FONT color=#808080 face=Arial 
    size=2>Fax:</FONT></B><FONT color=#808080 face=Arial size=2>&nbsp;</FONT> 
    <FONT face=Arial size=2>&nbsp; </FONT><FONT color=#993300 face=Arial 
    size=2>+972-3-765 5834</FONT> <BR><B><FONT color=#808080 face=Arial 
    size=2>E-mail:</FONT></B><FONT face=Arial size=2> </FONT><FONT color=#993300 
    face=Arial size=2>meir_m@mail.com</FONT> 
</P><BR><BR><BR></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C333DD.811439E2--
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From mailnull@www1.ietf.org  Mon Jun 16 16:59:41 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02083
	for <lemonade-archive@odin.ietf.org>; Mon, 16 Jun 2003 16:59:41 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5GKxEV03013
	for lemonade-archive@odin.ietf.org; Mon, 16 Jun 2003 16:59:14 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GKxEm03010
	for <lemonade-web-archive@optimus.ietf.org>; Mon, 16 Jun 2003 16:59:14 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02045
	for <lemonade-web-archive@ietf.org>; Mon, 16 Jun 2003 16:59:11 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19S129-0006hd-00
	for lemonade-web-archive@ietf.org; Mon, 16 Jun 2003 16:56:57 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19S128-0006ha-00
	for lemonade-web-archive@ietf.org; Mon, 16 Jun 2003 16:56:56 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GEu1a08900;
	Mon, 16 Jun 2003 10:56:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GEtTm08878
	for <lemonade@optimus.ietf.org>; Mon, 16 Jun 2003 10:55:29 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16988
	for <lemonade@ietf.org>; Mon, 16 Jun 2003 10:55:25 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19RvM8-0003BV-00
	for lemonade@ietf.org; Mon, 16 Jun 2003 10:53:12 -0400
Received: from panda.com
	([206.124.149.114] helo=Ikkoku-Kan.Panda.COM ident=wml)
	by ietf-mx with esmtp (Exim 4.12)
	id 19RvM6-0003BS-00
	for lemonade@ietf.org; Mon, 16 Jun 2003 10:53:11 -0400
Received: from localhost (mrc@localhost) by Ikkoku-Kan.Panda.COM id HAA29779; Mon, 16 Jun 2003 07:54:59 -0700 (PDT)
Date: Mon, 16 Jun 2003 07:54:58 -0700 (PDT)
From: Mark Crispin <mrc@CAC.Washington.EDU>
To: Mendelovich Meir <Meir.Mendelovich@comverse.com>
cc: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>, ned.freed@mrochek.com,
        "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: RE: [lemonade] Mobile messaging clients barriers - IMAP4 "passiva
 tion"
In-Reply-To: <E1542177268FD511866B0002A560C8080512E90C@il-tlv-mail5.comverse.com>
Message-ID: <Pine.NXT.4.56.0306160745000.11845@Ikkoku-Kan.Panda.COM>
References: <E1542177268FD511866B0002A560C8080512E90C@il-tlv-mail5.comverse.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Mon, 16 Jun 2003, Mendelovich Meir wrote:
>  Mobile clients are working in very "noisy" environments: they change cells,
> bearers and sometimes get out of signal. Every time that there is a sudden
> momentary disconnection, the old session hangs and new one should be
> initiated. Though part of the problem would be solved by underlying
> standards like mobile IP, disconnections will still be a problem.

This sounds like a bug in the TCP/IP implementation.  Abandoning a
perfectly good connection because of a momentary outage is, to my mind, a
bad idea.  Abandoning that connection to initiate a new one is a terrible
idea.

Back in the old days, we went to great effort to preserve sessions across
network outages, and to restore communication in the session promptly when
network connectivity is restored.  A fair amount of the architecture of
TCP becomes pointless if sessions (especially in highly stateful protocols
like IMAP) are destroyed before of a hiccup in a radio link.

Nor are the "noisy environment" problems new.  Refer to the old packet
radio work of 20-30 years ago.

-- 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 mailnull@www1.ietf.org  Mon Jun 16 23:33:09 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14944
	for <lemonade-archive@odin.ietf.org>; Mon, 16 Jun 2003 23:33:09 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5H3WdR31700
	for lemonade-archive@odin.ietf.org; Mon, 16 Jun 2003 23:32:39 -0400
Received: from ietf.org (lists.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H3WVm31697
	for <lemonade-web-archive@optimus.ietf.org>; Mon, 16 Jun 2003 23:32:31 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14936
	for <lemonade-web-archive@ietf.org>; Mon, 16 Jun 2003 23:32:27 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19S7Aj-00027R-00
	for lemonade-web-archive@ietf.org; Mon, 16 Jun 2003 23:30:13 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19S7Ai-00027O-00
	for lemonade-web-archive@ietf.org; Mon, 16 Jun 2003 23:30:12 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GFZ1a11847;
	Mon, 16 Jun 2003 11:35:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GFYem11815
	for <lemonade@optimus.ietf.org>; Mon, 16 Jun 2003 11:34:40 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18051
	for <lemonade@ietf.org>; Mon, 16 Jun 2003 11:34:37 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Rvy4-0003OH-00
	for lemonade@ietf.org; Mon, 16 Jun 2003 11:32:24 -0400
Received: from panda.com
	([206.124.149.114] helo=Ikkoku-Kan.Panda.COM ident=bruce)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Rvy3-0003OE-00
	for lemonade@ietf.org; Mon, 16 Jun 2003 11:32:23 -0400
Received: from localhost (mrc@localhost) by Ikkoku-Kan.Panda.COM id IAA29867; Mon, 16 Jun 2003 08:34:32 -0700 (PDT)
Date: Mon, 16 Jun 2003 08:34:31 -0700 (PDT)
From: Mark Crispin <mrc@CAC.Washington.EDU>
To: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: Re: [lemonade] Mobile messaging clients barriers - Protocls vs. S
 erver Implementation
In-Reply-To: <3EED2703.3010103@Royer.com>
Message-ID: <Pine.NXT.4.56.0306160757550.11845@Ikkoku-Kan.Panda.COM>
References: <7D4344E32B34D511A6500002A560C60204D8931B@il-tlv-mail4.comverse.com>
 <Pine.NXT.4.56.0306150758140.11845@Ikkoku-Kan.Panda.COM> <3EECD8CD.1030300@Royer.com>
 <Pine.NXT.4.56.0306151527450.11845@Ikkoku-Kan.Panda.COM> <3EED2703.3010103@Royer.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Sun, 15 Jun 2003, Doug Royer wrote:
> The proposal was not to create an new protocol anyway. The e-mail from
> Ned suggests exactly that. So - not an issue as we were not proposing
> a new wire protocol, just an extension intercepted by a proxy.

Did you miss the part where Ned said that a charter revision for this
purpose would not be difficult?

> > Have you considered the impact of RFC 2193 referrals on submit-in-IMAP?
> > If the server returns a referral, the mobile client must establish a new
> > IMAP connection to the referred-to server and reissue the submit to that
> > server.  It is also necessary to constrain submit-in-IMAP to reference
> > only one mailbox, to prevent unresolvable submissions.
> Currently ALL imap clients that connect to servers that return
> 'MAILBOX-REFERRALS' or any other extension would have this problem.
> Nothing new.

All good IMAP clients implement RFC 2193 and thus have no problem.  The
problem will be if mobile clients are mis-designed in such a way that they
can not work in an RFC 2193 environment.

> > Neither of these are issues with a proxy server on a different port.
> The port number has nothing to do with it. It has to do with
> submit and forward without download. The proposal was to
> transparently forward IMAP commands to and from a real IMAP
> server intercepting the SUBMIT command and sending the data
> to an SMTP server.

By using the same port, the implication is that this is a service that can
(and should) be expected from all IMAP servers.  However, a server which
offers this service could not do RFC 2193.  It could do one or the other
but not both.

> > The
> > proxy server can offer guarantees to the mobile client that no unwanted
> > chat from the IMAP server will reach it; in turn the mobile client can be
> > programmed with that assumption.  The proxy can also ensure that RFC 2193
> > referrals do not happen as far as the mobile client is concerned; this
> > also removes the restriction of only one mailbox reference in a submit.
> This could be done on the same port number by the proxy anyway,
> or not done if the client understands MAILBOX-REFERRALS or any
> other extension or IMAP feature.

If you require that the client understand referrals in submit, then the
entire "efficiency" argument for submit-in-IMAP is in tatters as the
client will open a new connection.

Furthermore, the restriction of "only one mailbox in a submit" remains,
and that restriction must be documented in the submit-in-IMAP
specification.

> And we are not solving the problem of IMAP clients that do not want
> to understand IMAP.

So IMAP being chatty is no longer a problem?

> I have not seen any proposal that prevents a mobile client from talking IMAP
> Nor have I seen a proposal for any other IMAP-like protocol.

I propose both as possible alternatives that should be considered.

> The proposal is for a proxy that understands how to include messages
> for the client and submit while making minimum changes to the wire
> protocol which happens to be IMAP.

Are you saying that all mechanisms which do not lead to submit-in-IMAP are
out of order, and this WG has no purpose other than to rubber-stamp?

If that is not what you are saying, then you should not attempt to
restrict the discussion of possible alternatives.

-- 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 mailnull@www1.ietf.org  Tue Jun 17 12:18:29 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25197
	for <lemonade-archive@odin.ietf.org>; Tue, 17 Jun 2003 12:18:29 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5HGI1O11332
	for lemonade-archive@odin.ietf.org; Tue, 17 Jun 2003 12:18:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HGI1m11327
	for <lemonade-web-archive@optimus.ietf.org>; Tue, 17 Jun 2003 12:18:01 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25185
	for <lemonade-web-archive@ietf.org>; Tue, 17 Jun 2003 12:17:58 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SJ7X-0001SR-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 12:15:43 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SJ7W-0001SN-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 12:15:42 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H8U2a05521;
	Tue, 17 Jun 2003 04:30:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H8TLm05474
	for <lemonade@optimus.ietf.org>; Tue, 17 Jun 2003 04:29:21 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03681
	for <lemonade@ietf.org>; Tue, 17 Jun 2003 04:29:19 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SBo0-00045p-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 04:27:04 -0400
Received: from comversegw.icomverse.com ([192.118.48.248] helo=il-tlv-smtpout1.icomverse.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SBnz-00045f-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 04:27:03 -0400
Received: from il-tlv-mbdg1.comverse.com (localhost.localdomain [127.0.0.1])
	by il-tlv-smtpout1.icomverse.com (8.11.6/8.11.6) with ESMTP id h5H8SYf26336;
	Tue, 17 Jun 2003 11:28:35 +0300
Received: by il-tlv-mbdg1.comverse.com with Internet Mail Service (5.5.2655.55)
	id <NBN7537V>; Tue, 17 Jun 2003 11:28:41 +0300
Message-ID: <E1542177268FD511866B0002A560C808053FDC51@il-tlv-mail5.comverse.com>
From: Mendelovich Meir <Meir.Mendelovich@comverse.com>
To: Mark Crispin <mrc@CAC.Washington.EDU>
Cc: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>, ned.freed@mrochek.com,
        "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: RE: [lemonade] Mobile messaging clients barriers - IMAP4 "passiva
	tion"
Date: Tue, 17 Jun 2003 11:28:38 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C334AA.73A526D6"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C334AA.73A526D6
Content-Type: text/plain;
	charset="iso-8859-1"

Mark,
 I agree that ideally the TCP should handle these situations. But, today's
networks (GPRS & CDMA1X) don't solve it. E.g. they change the device IP.
 Even in the ideal network, I doubt that it would solve disconnection of
more than 10 seconds that are very common.
 Another situation that requires passivation is Web Mail (or the suggested
mobile proxy) that serves several hundreds of session simultaneously. Such
server needs to passivate IMAP4 sessions. E.g. if subscriber has 5 minutes
think time, we don't want to keep his IMAP4 session open. This really
influences the scalability of such systems.

	Meir :->

-----Original Message-----
From: Mark Crispin [mailto:mrc@CAC.Washington.EDU] 
Sent: Monday, June 16, 2003 5:55 PM
To: Mendelovich Meir
Cc: Vaudreuil, Greg M (Greg); ned.freed@mrochek.com; IETF LEMONADE (E-mail)
Subject: RE: [lemonade] Mobile messaging clients barriers - IMAP4 "passiva
tion"


On Mon, 16 Jun 2003, Mendelovich Meir wrote:
>  Mobile clients are working in very "noisy" environments: they change 
> cells, bearers and sometimes get out of signal. Every time that there 
> is a sudden momentary disconnection, the old session hangs and new one 
> should be initiated. Though part of the problem would be solved by 
> underlying standards like mobile IP, disconnections will still be a 
> problem.

This sounds like a bug in the TCP/IP implementation.  Abandoning a perfectly
good connection because of a momentary outage is, to my mind, a bad idea.
Abandoning that connection to initiate a new one is a terrible idea.

Back in the old days, we went to great effort to preserve sessions across
network outages, and to restore communication in the session promptly when
network connectivity is restored.  A fair amount of the architecture of TCP
becomes pointless if sessions (especially in highly stateful protocols like
IMAP) are destroyed before of a hiccup in a radio link.

Nor are the "noisy environment" problems new.  Refer to the old packet radio
work of 20-30 years ago.

-- 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

------_=_NextPart_001_01C334AA.73A526D6
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: [lemonade] Mobile messaging clients barriers - IMAP4 =
&quot;passivation&quot;</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Mark,</FONT>
<BR><FONT SIZE=3D2>&nbsp;I agree that ideally the TCP should handle =
these situations. But, today's networks (GPRS &amp; CDMA1X) don't solve =
it. E.g. they change the device IP.</FONT></P>

<P><FONT SIZE=3D2>&nbsp;Even in the ideal network, I doubt that it =
would solve disconnection of more than 10 seconds that are very =
common.</FONT>
<BR><FONT SIZE=3D2>&nbsp;Another situation that requires passivation is =
Web Mail (or the suggested mobile proxy) that serves several hundreds =
of session simultaneously. Such server needs to passivate IMAP4 =
sessions. E.g. if subscriber has 5 minutes think time, we don't want to =
keep his IMAP4 session open. This really influences the scalability of =
such systems.</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>Meir =
:-&gt;</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Mark Crispin [<A =
HREF=3D"mailto:mrc@CAC.Washington.EDU">mailto:mrc@CAC.Washington.EDU</A>=
] </FONT>
<BR><FONT SIZE=3D2>Sent: Monday, June 16, 2003 5:55 PM</FONT>
<BR><FONT SIZE=3D2>To: Mendelovich Meir</FONT>
<BR><FONT SIZE=3D2>Cc: Vaudreuil, Greg M (Greg); ned.freed@mrochek.com; =
IETF LEMONADE (E-mail)</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [lemonade] Mobile messaging clients =
barriers - IMAP4 &quot;passiva tion&quot;</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>On Mon, 16 Jun 2003, Mendelovich Meir wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; Mobile clients are working in very =
&quot;noisy&quot; environments: they change </FONT>
<BR><FONT SIZE=3D2>&gt; cells, bearers and sometimes get out of signal. =
Every time that there </FONT>
<BR><FONT SIZE=3D2>&gt; is a sudden momentary disconnection, the old =
session hangs and new one </FONT>
<BR><FONT SIZE=3D2>&gt; should be initiated. Though part of the problem =
would be solved by </FONT>
<BR><FONT SIZE=3D2>&gt; underlying standards like mobile IP, =
disconnections will still be a </FONT>
<BR><FONT SIZE=3D2>&gt; problem.</FONT>
</P>

<P><FONT SIZE=3D2>This sounds like a bug in the TCP/IP =
implementation.&nbsp; Abandoning a perfectly good connection because of =
a momentary outage is, to my mind, a bad idea.&nbsp; Abandoning that =
connection to initiate a new one is a terrible idea.</FONT></P>

<P><FONT SIZE=3D2>Back in the old days, we went to great effort to =
preserve sessions across network outages, and to restore communication =
in the session promptly when network connectivity is restored.&nbsp; A =
fair amount of the architecture of TCP becomes pointless if sessions =
(especially in highly stateful protocols like IMAP) are destroyed =
before of a hiccup in a radio link.</FONT></P>

<P><FONT SIZE=3D2>Nor are the &quot;noisy environment&quot; problems =
new.&nbsp; Refer to the old packet radio work of 20-30 years =
ago.</FONT>
</P>

<P><FONT SIZE=3D2>-- Mark --</FONT>
</P>

<P><FONT SIZE=3D2><A HREF=3D"http://staff.washington.edu/mrc" =
TARGET=3D"_blank">http://staff.washington.edu/mrc</A></FONT>
<BR><FONT SIZE=3D2>Science does not emerge from voting, party politics, =
or public debate. Si vis pacem, para bellum. =
_______________________________________________</FONT></P>

<P><FONT SIZE=3D2>lemonade mailing list</FONT>
<BR><FONT SIZE=3D2>lemonade@ietf.org <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/lemonade" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/lemonade</A></F=
ONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C334AA.73A526D6--
_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From exim@www1.ietf.org  Tue Jun 17 14:15:51 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29792
	for <lemonade-archive@odin.ietf.org>; Tue, 17 Jun 2003 14:15:51 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5HIFNa12487
	for lemonade-archive@odin.ietf.org; Tue, 17 Jun 2003 14:15:23 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SKbE-0001Av-As
	for lemonade-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 13:50:28 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28008
	for <lemonade-web-archive@ietf.org>; Tue, 17 Jun 2003 13:50:26 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SKYy-0002Ak-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 13:48:09 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SKYx-0002Ag-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 13:48:07 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HDU1a28125;
	Tue, 17 Jun 2003 09:30:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HDTnm28104
	for <lemonade@optimus.ietf.org>; Tue, 17 Jun 2003 09:29:49 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14552
	for <lemonade@ietf.org>; Tue, 17 Jun 2003 09:29:46 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SGUk-0006qY-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 09:27:30 -0400
Received: from smtp5.andrew.cmu.edu ([128.2.10.85])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SGUf-0006qE-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 09:27:26 -0400
Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172])
	(user=rjs3 mech=GSSAPI (0 bits))
	by smtp5.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h5HDTX2u002923;
	Tue, 17 Jun 2003 09:29:33 -0400
Date: Tue, 17 Jun 2003 09:29:33 -0400 (EDT)
From: Rob Siemborski <rjs3@andrew.cmu.edu>
To: Mark Crispin <mrc@cac.washington.edu>
cc: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: Re: [lemonade] Mobile messaging clients barriers - Protocls vs. S
 erver Implementation
In-Reply-To: <Pine.NXT.4.56.0306160757550.11845@Ikkoku-Kan.Panda.COM>
Message-ID: <Pine.LNX.4.55L-033.0306170911420.15492@gobo.andrew.cmu.edu>
References: <7D4344E32B34D511A6500002A560C60204D8931B@il-tlv-mail4.comverse.com>
 <Pine.NXT.4.56.0306150758140.11845@Ikkoku-Kan.Panda.COM> <3EECD8CD.1030300@Royer.com>
 <Pine.NXT.4.56.0306151527450.11845@Ikkoku-Kan.Panda.COM> <3EED2703.3010103@Royer.com>
 <Pine.NXT.4.56.0306160757550.11845@Ikkoku-Kan.Panda.COM>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Mon, 16 Jun 2003, Mark Crispin wrote:

> > Currently ALL IMAP clients that connect to servers that return
> > 'MAILBOX-REFERRALS' or any other extension would have this problem.
> > Nothing new.
>
> All good IMAP clients implement RFC 2193 and thus have no problem.

Could you give examples?  Our experience with a RFC2193 server has been
that very few clients (in fact, only pine and other c-client based
clients) support RFC2193.  For this reason (and the fact that the server
has no way of knowing other than if the client issues an RLIST command
that the client supports 2193), I don't think we'll see a large number of
servers issuing mailbox referrals unexpectedly in the foreseeable future.

> The problem will be if mobile clients are mis-designed in such a way
> that they can not work in an RFC 2193 environment.

Yes, if 2193 was ubiquitous, then this would be an issue.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

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



From exim@www1.ietf.org  Tue Jun 17 14:15:51 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29796
	for <lemonade-archive@odin.ietf.org>; Tue, 17 Jun 2003 14:15:51 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5HIFNv12521
	for lemonade-archive@odin.ietf.org; Tue, 17 Jun 2003 14:15:23 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SKbV-0001C5-2j
	for lemonade-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 13:50:45 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28020
	for <lemonade-web-archive@ietf.org>; Tue, 17 Jun 2003 13:50:42 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SKZF-0002B9-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 13:48:25 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SKZF-0002B6-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 13:48:25 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HDq1a29943;
	Tue, 17 Jun 2003 09:52:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HDpJm29915
	for <lemonade@optimus.ietf.org>; Tue, 17 Jun 2003 09:51:19 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15829
	for <lemonade@ietf.org>; Tue, 17 Jun 2003 09:51:17 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SGpZ-0007Ft-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 09:49:01 -0400
Received: from panda.com
	([206.124.149.114] helo=Ikkoku-Kan.Panda.COM ident=uhhl)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SGpX-0007Fq-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 09:49:00 -0400
Received: from localhost (mrc@localhost) by Ikkoku-Kan.Panda.COM id GAA01832; Tue, 17 Jun 2003 06:51:11 -0700 (PDT)
Date: Tue, 17 Jun 2003 06:51:10 -0700 (PDT)
From: Mark Crispin <mrc@CAC.Washington.EDU>
To: Rob Siemborski <rjs3@andrew.cmu.edu>
cc: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: Re: [lemonade] Mobile messaging clients barriers - Protocls vs. S
 erver Implementation
In-Reply-To: <Pine.LNX.4.55L-033.0306170911420.15492@gobo.andrew.cmu.edu>
Message-ID: <Pine.NXT.4.56.0306170641250.477@Ikkoku-Kan.Panda.COM>
References: <7D4344E32B34D511A6500002A560C60204D8931B@il-tlv-mail4.comverse.com>
 <Pine.NXT.4.56.0306150758140.11845@Ikkoku-Kan.Panda.COM> <3EECD8CD.1030300@Royer.com>
 <Pine.NXT.4.56.0306151527450.11845@Ikkoku-Kan.Panda.COM> <3EED2703.3010103@Royer.com>
 <Pine.NXT.4.56.0306160757550.11845@Ikkoku-Kan.Panda.COM>
 <Pine.LNX.4.55L-033.0306170911420.15492@gobo.andrew.cmu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Tue, 17 Jun 2003, Rob Siemborski wrote:
> > All good IMAP clients implement RFC 2193 and thus have no problem.
> Could you give examples?  Our experience with a RFC2193 server has been
> that very few clients (in fact, only pine and other c-client based
> clients) support RFC2193.

I said "all good IMAP clients", didn't I?  :-)

> For this reason (and the fact that the server
> has no way of knowing other than if the client issues an RLIST command
> that the client supports 2193), I don't think we'll see a large number of
> servers issuing mailbox referrals unexpectedly in the foreseeable future.

Building an enterprise facility which requires 2193 is an excellent way of
getting rid of the pretty-picture virus-spreaders.  It's a standard trick
of IS managers to preclude the use of unauthorized software.

> > The problem will be if mobile clients are mis-designed in such a way
> > that they can not work in an RFC 2193 environment.
> Yes, if 2193 was ubiquitous, then this would be an issue.

Which leads to the obvious question: is LEMONADE willing to put itself in
the position of building a submit facility that breaks with 2193, on the
grounds that LEMONADE believes that nobody uses 2193?

If so, sooner or later there will have to be a showdown in the
standardization process.

-- 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 exim@www1.ietf.org  Tue Jun 17 14:15:53 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29831
	for <lemonade-archive@odin.ietf.org>; Tue, 17 Jun 2003 14:15:52 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5HIFO112565
	for lemonade-archive@odin.ietf.org; Tue, 17 Jun 2003 14:15:24 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SKcq-0001Hz-Rl
	for lemonade-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 13:52:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28109
	for <lemonade-web-archive@ietf.org>; Tue, 17 Jun 2003 13:52:06 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SKab-0002CS-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 13:49:49 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SKaa-0002CP-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 13:49:48 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HBv1a20865;
	Tue, 17 Jun 2003 07:57:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HBuVm20845
	for <lemonade@optimus.ietf.org>; Tue, 17 Jun 2003 07:56:31 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08281;
	Tue, 17 Jun 2003 07:56:30 -0400 (EDT)
Message-Id: <200306171156.HAA08281@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: lemonade@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Tue, 17 Jun 2003 07:56:29 -0400
Subject: [lemonade] I-D ACTION:draft-royer-lemonade-submit-00.txt
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: IMAP-PROXY service for mobile clients to do submitting
                          and forwarding
	Author(s)	: D. Royer
	Filename	: draft-royer-lemonade-submit-00.txt
	Pages		: 7
	Date		: 2003-6-16
	
This memo describes a method that allows mobile clients to use the
IMAP protocol and submit messages to a IMAP-PROXY service that
understands [E]SMTP and IMAP.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-royer-lemonade-submit-00.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-royer-lemonade-submit-00.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:	<2003-6-17075258.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-royer-lemonade-submit-00.txt

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

Content-Type: text/plain
Content-ID:	<2003-6-17075258.I-D@ietf.org>

--OtherAccess--

--NextPart--


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



From exim@www1.ietf.org  Tue Jun 17 14:15:53 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29837
	for <lemonade-archive@odin.ietf.org>; Tue, 17 Jun 2003 14:15:53 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5HIFOe12633
	for lemonade-archive@odin.ietf.org; Tue, 17 Jun 2003 14:15:24 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SKdT-0001LZ-B2
	for lemonade-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 13:52:47 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28186
	for <lemonade-web-archive@ietf.org>; Tue, 17 Jun 2003 13:52:45 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SKbD-0002DN-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 13:50:27 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SKbD-0002DK-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 13:50:27 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HEp1a02436;
	Tue, 17 Jun 2003 10:51:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HEoNm02400
	for <lemonade@optimus.ietf.org>; Tue, 17 Jun 2003 10:50:23 -0400
Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20408
	for <lemonade@ietf.org>; Tue, 17 Jun 2003 10:50:19 -0400 (EDT)
Received: from iere.net.avaya.com (localhost [127.0.0.1])
	by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id h5HEl7922962
	for <lemonade@ietf.org>; Tue, 17 Jun 2003 10:47:07 -0400 (EDT)
Received: from bighorn.dr.avaya.com (h135-9-1-59.avaya.com [135.9.1.59])
	by iere.net.avaya.com (8.11.2/8.9.3) with SMTP id h5HEl6q22934;
	Tue, 17 Jun 2003 10:47:06 -0400 (EDT)
Received: from avaya.com by bighorn.dr.avaya.com (SMI-8.6/EMS-1.5 sol2)
	id IAA03500; Tue, 17 Jun 2003 08:50:17 -0600
Message-ID: <3EEF2AD3.7010308@avaya.com>
Date: Tue, 17 Jun 2003 08:50:59 -0600
From: Rick Block <rickblock@avaya.com>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: hardie@qualcomm.com
CC: Mark Crispin <mrc@CAC.Washington.EDU>, Erev Ari
 <Ari.Erev@comverse.com>,
        "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: Re: [lemonade] Mobile messaging clients barriers - Protocls vs. S
  erver Implementation
References: <7D4344E32B34D511A6500002A560C60204D8931B@il-tlv-mail4.comverse.com> <Pine.NXT.4.56.0306150758140.11845@Ikkoku-Kan.Panda.COM> <p06001201bb128284b404@[205.214.163.27]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


hardie@qualcomm.com wrote:
> Folks,
>     I encourage those who have put forward straw proposals
> to the group to get them into I-D form, however rough they may
> be.  I also encourage those taking on that work to re-read the
> charter as they do that writing.

OK.  Not in the form of an I-D, but here's a detailed "proxy" straw
proposal for a "new" protocol (oops, I mean an extension of IMAP4)
intended for use by mobile clients which (for now) let's call imap++.
I don't think there's a large semantic difference between this
being considered a new protocol to be offered on some well known
port other than 143 versus being considered an IMAP4 extension
advertised via a CAPABILITY response.

1) imap++ is a strict superset of IMAP4 as defined in RFC3501

2) in the selected state, imap++ also supports "mail from",
"rcpt to", "rset", and "data" commands as defined for SMTP in RFC2821.
Selecting another mailbox will reset any SMTP-related state (i.e.
effectively perform an SMTP "rset").  To better fit the IMAP4
command structure, these "SMTP" commands will be preceded by
an IMAP4 tag.  [other imap4 parsing accommodations to be specified]

3) The MIME content transmitted following the "data" command can
include a syntax [to be specified] indicating inclusion of body
parts of messages in the currently selected mailbox.

4) the CAPABILITY response may include both extensions defined for
IMAP4 as well as extensions defined for SMTP [I haven't checked,
but hopefully existing extension names don't intersect]


Rick Block
Avaya Inc.


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



From exim@www1.ietf.org  Tue Jun 17 15:02:03 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29862
	for <lemonade-archive@odin.ietf.org>; Tue, 17 Jun 2003 14:15:54 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5HIFPx12710
	for lemonade-archive@odin.ietf.org; Tue, 17 Jun 2003 14:15:25 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SKiu-0001kc-RD
	for lemonade-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 13:58:24 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28528
	for <lemonade-web-archive@ietf.org>; Tue, 17 Jun 2003 13:58:22 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SKgf-0002Ie-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 13:56:05 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SKge-0002Ib-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 13:56:04 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HDg1a29523;
	Tue, 17 Jun 2003 09:42:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HDfbm29489
	for <lemonade@optimus.ietf.org>; Tue, 17 Jun 2003 09:41:37 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15466
	for <lemonade@ietf.org>; Tue, 17 Jun 2003 09:41:35 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SGgA-00079K-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 09:39:18 -0400
Received: from panda.com
	([206.124.149.114] helo=Ikkoku-Kan.Panda.COM ident=tpb)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SGg9-00079H-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 09:39:17 -0400
Received: from localhost (mrc@localhost) by Ikkoku-Kan.Panda.COM id GAA01823; Tue, 17 Jun 2003 06:41:04 -0700 (PDT)
Date: Tue, 17 Jun 2003 06:41:03 -0700 (PDT)
From: Mark Crispin <mrc@CAC.Washington.EDU>
To: Mendelovich Meir <Meir.Mendelovich@comverse.com>
cc: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>, ned.freed@mrochek.com,
        "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: RE: [lemonade] Mobile messaging clients barriers - IMAP4 "passiva
 tion"
In-Reply-To: <E1542177268FD511866B0002A560C808053FDC51@il-tlv-mail5.comverse.com>
Message-ID: <Pine.NXT.4.56.0306170623230.477@Ikkoku-Kan.Panda.COM>
References: <E1542177268FD511866B0002A560C808053FDC51@il-tlv-mail5.comverse.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Tue, 17 Jun 2003, Mendelovich Meir wrote:
>  I agree that ideally the TCP should handle these situations. But, today's
> networks (GPRS & CDMA1X) don't solve it. E.g. they change the device IP.

Changing the IP address is a very serious problem.  CDPD manages not to
have that problem.  Will this issue go away with IPv6?

>  Even in the ideal network, I doubt that it would solve disconnection of
> more than 10 seconds that are very common.

I am very unhappy with any product that unilaterally breaks my connection
because of a mere 10 second network outage.  The benefit of TCP/IP
technology is that I could have a 10 *minute* network outage and still
recover my session when connectivity is restored.

There is a reason why RFC 3501 says that the server should wait 30 minutes
before abandoning a session due to inactivity.  Similarly, the client
should not abandon a session without permission from the user.

>  Another situation that requires passivation is Web Mail (or the suggested
> mobile proxy) that serves several hundreds of session simultaneously. Such
> server needs to passivate IMAP4 sessions. E.g. if subscriber has 5 minutes
> think time, we don't want to keep his IMAP4 session open. This really
> influences the scalability of such systems.

Yes, I've seen many poorly-designed Web Mail systems that drop sessions or
spawn extraneous sessions for no good reason, and I've seen scalability
problems created by this excessive session-creation/destruction.  The
mentality of the designers of such systems clearly is to be aggressive in
destroying TCP connections, in the false believe that such connections are
expensive.

We did not make that mistake in our Web Mail system.

TCP connections are cheap.  Renegotiating authentication and TLS, and
rebuilding IMAP state, is not.

-- 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 exim@www1.ietf.org  Tue Jun 17 15:23:47 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06007
	for <lemonade-archive@odin.ietf.org>; Tue, 17 Jun 2003 15:23:47 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5HJNHE11121
	for lemonade-archive@odin.ietf.org; Tue, 17 Jun 2003 15:23:17 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SLD0-0004Dh-Fz
	for lemonade-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 14:29:30 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01376
	for <lemonade-web-archive@ietf.org>; Tue, 17 Jun 2003 14:29:27 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SLAk-0002yj-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 14:27:10 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SLAk-0002yg-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 14:27:10 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HFB1a04493;
	Tue, 17 Jun 2003 11:11:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HFA5m04451
	for <lemonade@optimus.ietf.org>; Tue, 17 Jun 2003 11:10:05 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21582
	for <lemonade@ietf.org>; Tue, 17 Jun 2003 11:10:01 -0400 (EDT)
From: ned.freed@mrochek.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SI3l-0000VN-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 11:07:45 -0400
Received: from mauve.mrochek.com ([209.55.107.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SI3k-0000VK-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 11:07:44 -0400
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243)
 id <01KX6FWI326800AIOP@mauve.mrochek.com> for lemonade@ietf.org; Tue,
 17 Jun 2003 08:09:44 -0700 (PDT)
Date: Tue, 17 Jun 2003 07:55:39 -0700 (PDT)
Subject: RE: [lemonade] Mobile messaging clients barriers - IMAP4 "passiva tion"
In-reply-to: "Your message dated Tue, 17 Jun 2003 06:41:03 -0700 (PDT)"
 <Pine.NXT.4.56.0306170623230.477@Ikkoku-Kan.Panda.COM>
To: Mark Crispin <mrc@CAC.Washington.EDU>
Cc: Mendelovich Meir <Meir.Mendelovich@comverse.com>,
        "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>, ned.freed@mrochek.com,
        "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Message-id: <01KX702FLI0Q00AIOP@mauve.mrochek.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: 
 <E1542177268FD511866B0002A560C808053FDC51@il-tlv-mail5.comverse.com>
 <Pine.NXT.4.56.0306170623230.477@Ikkoku-Kan.Panda.COM>
Content-Transfer-Encoding: 7BIT
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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-Transfer-Encoding: 7BIT
Content-Transfer-Encoding: 7BIT

> On Tue, 17 Jun 2003, Mendelovich Meir wrote:
> >  I agree that ideally the TCP should handle these situations. But, today's
> > networks (GPRS & CDMA1X) don't solve it. E.g. they change the device IP.

> Changing the IP address is a very serious problem.  CDPD manages not to
> have that problem.  Will this issue go away with IPv6?

Agreed. IMO if IP address stability really is an issue that needs to be solved
we should at least look at things like RSERPOOL as a means to solve it.

> >  Even in the ideal network, I doubt that it would solve disconnection of
> > more than 10 seconds that are very common.

> I am very unhappy with any product that unilaterally breaks my connection
> because of a mere 10 second network outage.  The benefit of TCP/IP
> technology is that I could have a 10 *minute* network outage and still
> recover my session when connectivity is restored.

Agreed again. A TCP stack that breaks connections when there's a very short
network outage is BROKEN, and the way to fix that is to fix the stack. No other
approach is reasonable, really, since even if you were to deploy something on
top of a broken TCP implementation to restablish connections in the face of
frequent spurious disconnects due to short outages the resulting overhead and
latency would be unacceptable.

> There is a reason why RFC 3501 says that the server should wait 30 minutes
> before abandoning a session due to inactivity.  Similarly, the client
> should not abandon a session without permission from the user.

> >  Another situation that requires passivation is Web Mail (or the suggested
> > mobile proxy) that serves several hundreds of session simultaneously. Such
> > server needs to passivate IMAP4 sessions. E.g. if subscriber has 5 minutes
> > think time, we don't want to keep his IMAP4 session open. This really
> > influences the scalability of such systems.

> Yes, I've seen many poorly-designed Web Mail systems that drop sessions or
> spawn extraneous sessions for no good reason, and I've seen scalability
> problems created by this excessive session-creation/destruction.  The
> mentality of the designers of such systems clearly is to be aggressive in
> destroying TCP connections, in the false believe that such connections are
> expensive.

Yep. This is a belief that seems to surface periodically and for no good
reason. The amount of overhead associated with a connection in a well designed
stack is surprisingly small.

> We did not make that mistake in our Web Mail system.

> TCP connections are cheap.  Renegotiating authentication and TLS, and
> rebuilding IMAP state, is not.

Once again I agree. And let me add a meta-comment as well: This group seems to
be conflating geniune issues that crop up in the wireless space with issues
caused by exceedingly poor implementations. To the extent things fall in the
latter category, trying to solve such implementation problems with protocol
hacks is not only silly, it has been shown over and over and over again that it
just doesn't work. Instead what you end up doing is having your protocol
designs chase around after the latest round of implementations botches, with no
end in sight.

Let's please try not to heed the siren song of fixing broken implementations
with protocol hacks. Let's instead focus on the real issues. There are more
than enough of those that need to be addressed to keep us busy.

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



From exim@www1.ietf.org  Tue Jun 17 16:06:17 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08427
	for <lemonade-archive@odin.ietf.org>; Tue, 17 Jun 2003 16:06:16 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5HK5m726326
	for lemonade-archive@odin.ietf.org; Tue, 17 Jun 2003 16:05:48 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SMU1-0006Lz-OU
	for lemonade-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 15:51:09 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07779
	for <lemonade-web-archive@ietf.org>; Tue, 17 Jun 2003 15:51:07 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SMRn-0004GG-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 15:48:51 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SMRm-0004GD-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 15:48:50 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SMKG-0004sV-E7; Tue, 17 Jun 2003 15:41:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SM3I-00032D-QM
	for lemonade@optimus.ietf.org; Tue, 17 Jun 2003 15:23:32 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05921
	for <lemonade@ietf.org>; Tue, 17 Jun 2003 15:23:31 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SM14-0003sF-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 15:21:14 -0400
Received: from inet-consulting.com ([4.23.9.166] helo=royer.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SM0x-0003ry-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 15:21:08 -0400
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h5HJNEbt002817
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <lemonade@ietf.org>; Tue, 17 Jun 2003 12:23:20 -0700
Message-ID: <3EEF6A96.7000406@Royer.com>
Date: Tue, 17 Jun 2003 13:23:02 -0600
From: Doug Royer <Doug@Royer.com>
Reply-To: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: Re: [lemonade] Mobile messaging clients barriers - Protocls vs. S
 erver Implementation
References: <7D4344E32B34D511A6500002A560C60204D8931B@il-tlv-mail4.comverse.com> <Pine.NXT.4.56.0306150758140.11845@Ikkoku-Kan.Panda.COM> <3EECD8CD.1030300@Royer.com> <Pine.NXT.4.56.0306151527450.11845@Ikkoku-Kan.Panda.COM> <3EED2703.3010103@Royer.com> <Pine.NXT.4.56.0306160757550.11845@Ikkoku-Kan.Panda.COM> <Pine.LNX.4.55L-033.0306170911420.15492@gobo.andrew.cmu.edu> <Pine.NXT.4.56.0306170641250.477@Ikkoku-Kan.Panda.COM>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070606020602030206040806"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This is a cryptographically signed message in MIME format.

--------------ms070606020602030206040806
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Mark Crispin wrote:

>>>The problem will be if mobile clients are mis-designed in such a way
>>>that they can not work in an RFC 2193 environment.
>>
>>Yes, if 2193 was ubiquitous, then this would be an issue.
> 
> 
> Which leads to the obvious question: is LEMONADE willing to put itself in
> the position of building a submit facility that breaks with 2193, on the
> grounds that LEMONADE believes that nobody uses 2193?
> 
> If so, sooner or later there will have to be a showdown in the
> standardization process.

As the current focus is IMAP aware cell phones, this is not
an issue as they ether will or will not be compliant. If they
are compliant, not an issue.

Additionally the PROXY could perform the redirection for the cell
phone and the cell phone would never need to know. And as (per
previous emails) the IP address changes, this may be the preferred
way to solve the problem. That is the proxy connects to the correct
system via some redirect and the cell phone never cares - it just
connects to any IMAP server it knows about and the proxy ether
gets a redirect or not, and the proxy returns to the cell phone
the correct data with the cell phone never caring that the proxy
was redirected.

And a proxy submit will not break 2193 as the proxy is deciding
which SMTP server to connect to without the IMAP clients input.
If the client connects to an IMAP server that can not submit,
that is no change from now. If it can do a submit, it works.

So 2192 may be the salvation and not the nemesis when the
IMAP client uses a proxy.

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  Doug@Royer.com                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

--------------ms070606020602030206040806
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC
A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j
cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB
MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T
BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN
VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre
qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+
5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA
MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg
TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD
QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx
ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz
IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq
hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34
1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA
gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK
YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd
SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC
AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF
BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl
cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl
IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs
MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq
1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2
TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail
MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE
AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO
b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG
MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD
VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV
BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv
43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y
lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP
D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn
0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK
bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg
hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT
IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI
AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t
L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk
OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW
yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1
MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl
ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTcxOTIzMDJaMCMGCSqGSIb3DQEJBDEWBBQW
LjEf8dsV6b4VLMP+sSVzknBAPTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL
KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAiZrjFx4ENL1F
+qUSg1FxAfAlaMwESL3uejBoLRlbDRy4bX5e0LD+yGDxpPvm3Ad0dYiOtpuKwBU1h7+aApGf
KtA6PmaH6qktU3dLUAIegZ5+SvoU9VaFoHbvuXlpWa84nbmsKkpH0/t4Tx7Qn1/VuTbHD2CD
+hyp/fXGZ2Fsl99l2dRXeoPol7VjTUNUmAapL4+cEz65p66FSVN/q/l1Cl3c9KTZILpWN68G
rTecRFRUyonfdVirBzX1gSWzFZa0n44SyDzVTnXOk8hCndXyx2mzxNeEIpXLRnUTmgBDMEqW
emec8JD/gD27o8A2nuD8BJBf2k24OoCoLWkPTw4f2QAAAAAAAA==
--------------ms070606020602030206040806--


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



From exim@www1.ietf.org  Tue Jun 17 16:40:31 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10123
	for <lemonade-archive@odin.ietf.org>; Tue, 17 Jun 2003 16:40:31 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5HKe3k02618
	for lemonade-archive@odin.ietf.org; Tue, 17 Jun 2003 16:40:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SNFL-0000g4-As
	for lemonade-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 16:40:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10083
	for <lemonade-web-archive@ietf.org>; Tue, 17 Jun 2003 16:40:00 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SND6-0004l2-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 16:37:44 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SND5-0004kz-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 16:37:43 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SNFI-0000do-OE; Tue, 17 Jun 2003 16:40:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SNEy-0000bj-Dt
	for lemonade@optimus.ietf.org; Tue, 17 Jun 2003 16:39:40 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10044
	for <lemonade@ietf.org>; Tue, 17 Jun 2003 16:39:37 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SNCj-0004ke-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 16:37:21 -0400
Received: from mxout2.cac.washington.edu ([140.142.33.4])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SNCi-0004kb-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 16:37:20 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139])
	by mxout2.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h5HKdZbr032432
	for <lemonade@ietf.org>; Tue, 17 Jun 2003 13:39:35 -0700
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
	(authenticated bits=0)
	by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h5HKdZ3i005399
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT)
	for <lemonade@ietf.org>; Tue, 17 Jun 2003 13:39:35 -0700
Date: Tue, 17 Jun 2003 13:39:34 -0700 (Pacific Daylight Time)
From: Mark Crispin <MRC@CAC.Washington.EDU>
To: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: Re: [lemonade] Mobile messaging clients barriers - Protocls vs. S
 erver Implementation
In-Reply-To: <3EEF6A96.7000406@Royer.com>
Message-ID: <Pine.WNT.4.60.0306171326440.1912@Tomobiki-Cho.CAC.Washington.EDU>
References: <7D4344E32B34D511A6500002A560C60204D8931B@il-tlv-mail4.comverse.com>
 <Pine.NXT.4.56.0306150758140.11845@Ikkoku-Kan.Panda.COM> <3EECD8CD.1030300@Royer.com>
 <Pine.NXT.4.56.0306151527450.11845@Ikkoku-Kan.Panda.COM> <3EED2703.3010103@Royer.com>
 <Pine.NXT.4.56.0306160757550.11845@Ikkoku-Kan.Panda.COM>
 <Pine.LNX.4.55L-033.0306170911420.15492@gobo.andrew.cmu.edu>
 <Pine.NXT.4.56.0306170641250.477@Ikkoku-Kan.Panda.COM> <3EEF6A96.7000406@Royer.com>
Organization: Networks & Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Tue, 17 Jun 2003, Doug Royer wrote:
> As the current focus is IMAP aware cell phones, this is not
> an issue as they ether will or will not be compliant.

It is very much an issue if a reference to more than one mailbox is
permitted in the submit request.  The result is an unresolvable submission
request.

If you propose to solve this by requiring a proxy (which you suggest would
resolve referrals so the cell phone never sees it), then that begs the
question of how the user of the cell phone is to understand that detail.

Specifically; the user knows from his desktop client that his IMAP server
is imap.foo.com.  So he configures his cell phone to use imap.foo.com,
which subsequently doesn't work because the port 143 server on
imap.foo.com is not a proxy server.  Since you insist upon using port
143 for the proxy, a proxy server can't co-exist on imap.foo.com.

So the user has to know, specially for his cell phone, that he must use
proxy-imap.foo.com.  And foo.com has to set up this separate IP address
specifically for cell phones instead of just installing a new server on a
different port on the existing IP address.

All of this just to shoehorn submit-in-IMAP into the port 143 IMAP
service.  Why?

Is it to create an attractive nuisance to desktop clients, in an attempt
to pressure all IMAP server vendors to implement it?

If it's a separate port, then other desirable things specifically tailored
for cell phones can be done.  Think mIMAP.  Think NNTP-style overviews
instead of IMAP envelopes.

Why tie up the IMAP session while a submit is going on?  A separate IMAP
session from a submit session could be downloading new mail while the
message being submitted is being uploaded.

-- 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 exim@www1.ietf.org  Tue Jun 17 17:12:00 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11950
	for <lemonade-archive@odin.ietf.org>; Tue, 17 Jun 2003 17:12:00 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5HLBWB10991
	for lemonade-archive@odin.ietf.org; Tue, 17 Jun 2003 17:11:32 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SNjo-0002rC-MW
	for lemonade-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 17:11:32 -0400
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11925
	for <lemonade-web-archive@ietf.org>; Tue, 17 Jun 2003 17:11:29 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SNjJ-0002on-S2; Tue, 17 Jun 2003 17:11:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SNjB-0002oH-Ue
	for lemonade@optimus.ietf.org; Tue, 17 Jun 2003 17:10:53 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11859
	for <lemonade@ietf.org>; Tue, 17 Jun 2003 17:10:50 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SNgw-0005DZ-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 17:08:34 -0400
Received: from inet-consulting.com ([4.23.9.166] helo=royer.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SNgn-0005Cy-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 17:08:25 -0400
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h5HLAPbt003989
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <lemonade@ietf.org>; Tue, 17 Jun 2003 14:10:33 -0700
Message-ID: <3EEF83B1.1090309@Royer.com>
Date: Tue, 17 Jun 2003 15:10:09 -0600
From: Doug Royer <Doug@Royer.com>
Reply-To: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: Re: [lemonade] Mobile messaging clients barriers - Protocls vs. S
 erver Implementation
References: <7D4344E32B34D511A6500002A560C60204D8931B@il-tlv-mail4.comverse.com> <Pine.NXT.4.56.0306150758140.11845@Ikkoku-Kan.Panda.COM> <3EECD8CD.1030300@Royer.com> <Pine.NXT.4.56.0306151527450.11845@Ikkoku-Kan.Panda.COM> <3EED2703.3010103@Royer.com> <Pine.NXT.4.56.0306160757550.11845@Ikkoku-Kan.Panda.COM> <Pine.LNX.4.55L-033.0306170911420.15492@gobo.andrew.cmu.edu> <Pine.NXT.4.56.0306170641250.477@Ikkoku-Kan.Panda.COM> <3EEF6A96.7000406@Royer.com> <Pine.WNT.4.60.0306171326440.1912@Tomobiki-Cho.CAC.Washington.EDU>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070109080503090701090109"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This is a cryptographically signed message in MIME format.

--------------ms070109080503090701090109
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Mark Crispin wrote:
> On Tue, 17 Jun 2003, Doug Royer wrote:
> 
>>As the current focus is IMAP aware cell phones, this is not
>>an issue as they ether will or will not be compliant.
> 
> 
> It is very much an issue if a reference to more than one mailbox is
> permitted in the submit request.  The result is an unresolvable submission
> request.

By mailbox do you mean MX host, or do you mean that you expect
the IMAP server to APPEND to the IMAP mailboxes - That was Alan's
proposal - not mine.

By having the PROXY do the SMTP submission, the IMAP client
would never need to know if the RCPT mailboxes were local,
remote, on one MX host, or several MX hosts. They just
submit the mime-blob.

> If you propose to solve this by requiring a proxy (which you suggest would
> resolve referrals so the cell phone never sees it), then that begs the
> question of how the user of the cell phone is to understand that detail.

They would never know or care. Just like an IMAP client now never
need to tell the user that the IMAP server redirected them to an alternate
IMAP server.

> Specifically; the user knows from his desktop client that his IMAP server
> is imap.foo.com.  So he configures his cell phone to use imap.foo.com,
> which subsequently doesn't work because the port 143 server on
> imap.foo.com is not a proxy server.  Since you insist upon using port
> 143 for the proxy, a proxy server can't co-exist on imap.foo.com.

So we agree. If you point your client to a server that does not
understand submit, then they can not submit. :-)

It can co-exist as to non IMAP submit clients - it is a transparent proxy
so existing clients can use the proxy and they never need to know they
are using a proxy.

> So the user has to know, specially for his cell phone, that he must use
> proxy-imap.foo.com.  And foo.com has to set up this separate IP address
> specifically for cell phones instead of just installing a new server on a
> different port on the existing IP address.

No. the ISP tells the user that they will be using imap.foo.com and they
will never need to know that it is a submit server. Their normal IMAP
client will work, and so will their cell phone. If their vendor
updates their IMAP client for submit, then it will also work for submit.

> All of this just to shoehorn submit-in-IMAP into the port 143 IMAP
> service.  Why?

Because it would be transparent to all existing IMAP clients, 143 and 993.

> Is it to create an attractive nuisance to desktop clients, in an attempt
> to pressure all IMAP server vendors to implement it?

No.

> If it's a separate port, then other desirable things specifically tailored
> for cell phones can be done.  Think mIMAP.  Think NNTP-style overviews
> instead of IMAP envelopes.

If it is a separate port then all existing IMAP clients would have
to be re-configured to use the new port.

> Why tie up the IMAP session while a submit is going on?  A separate IMAP
> session from a submit session could be downloading new mail while the
> message being submitted is being uploaded.

Tie up? Most IMAP sessions are persistent anyway. It should not
take any longer than an APPEND command.

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  Doug@Royer.com                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

--------------ms070109080503090701090109
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC
A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j
cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB
MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T
BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN
VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre
qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+
5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA
MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg
TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD
QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx
ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz
IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq
hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34
1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA
gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK
YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd
SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC
AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF
BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl
cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl
IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs
MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq
1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2
TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail
MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE
AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO
b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG
MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD
VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV
BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv
43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y
lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP
D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn
0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK
bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg
hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT
IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI
AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t
L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk
OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW
yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1
MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl
ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTcyMTEwMDlaMCMGCSqGSIb3DQEJBDEWBBS/
HxlhhMD255x77I/V8GqBBtePkDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL
KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAO60Obp4ltJJk
7qqeLKLHC0MuvgVSq10+iaRevtVhsXg7/WQz1ryIb5x4dpJAi0rl+eXjvNMiAZPC5U8IuCxS
82bys7h0Q/Uuby2ZtLYYA97KXwDqUxNovCiJ47d2X9pbOSKi4JuLqM2vMRYApi75sQS9cUCg
EqFsvQZ1N+yvWJ5Z9dy0lMfMsQYDvizKsSlpE1z0n8d8Iz6ovMUW0FK/0mQnkLhpU1CInN+I
31FAvfwmBN3VsSJWnwkm/9YZtb0EtQruuPgMh6bbRBqHUUAN1bHj9yQSVVugPgCt4uiCW3mx
DKoeuVm1KP81RWNOJXCWu3oJmEchXKTblMIgp8iRbAAAAAAAAA==
--------------ms070109080503090701090109--


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



From exim@www1.ietf.org  Tue Jun 17 17:12:58 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12008
	for <lemonade-archive@odin.ietf.org>; Tue, 17 Jun 2003 17:12:58 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5HLCUR11218
	for lemonade-archive@odin.ietf.org; Tue, 17 Jun 2003 17:12:30 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SNkk-0002ur-TM
	for lemonade-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 17:12:30 -0400
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11994
	for <lemonade-web-archive@ietf.org>; Tue, 17 Jun 2003 17:12:28 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SNkG-0002tA-Jn; Tue, 17 Jun 2003 17:12:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SNk1-0002sX-MX
	for lemonade@optimus.ietf.org; Tue, 17 Jun 2003 17:11:45 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11944
	for <lemonade@ietf.org>; Tue, 17 Jun 2003 17:11:42 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SNhm-0005FN-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 17:09:26 -0400
Received: from mxout4.cac.washington.edu ([140.142.33.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SNhl-0005FI-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 17:09:25 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9])
	by mxout4.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h5HLBgG4011106
	for <lemonade@ietf.org>; Tue, 17 Jun 2003 14:11:42 -0700
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
	(authenticated bits=0)
	by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h5HLBf3n005586
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT)
	for <lemonade@ietf.org>; Tue, 17 Jun 2003 14:11:41 -0700
Date: Tue, 17 Jun 2003 14:11:40 -0700 (Pacific Daylight Time)
From: Mark Crispin <MRC@CAC.Washington.EDU>
To: lemonade@ietf.org
In-Reply-To: <200306171156.HAA08281@ietf.org>
Message-ID: <Pine.WNT.4.60.0306171340380.1912@Tomobiki-Cho.CAC.Washington.EDU>
References: <200306171156.HAA08281@ietf.org>
Organization: Networks & Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [lemonade] draft-royer-lemonade-submit-00.txt
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

Why is this called an "IMAP proxy" instead of an "IMAP and SMTP proxy"?

This document very suspiciously refers to a "standard IMAP client" as
being a client of the proxy.  I thought that this was about about
providing an efficient means of forward and remail for mobile clients, not
a backdoor attempt (without going through IMAPEXT) to force submit into
IMAP for all clients.

Nothing, other than some handwaving in section 2, gives any indication of
how this is an "IMAP proxy" rather an added CAN-SUBMIT extension to the
IMAP protocol (which belongs in IMAPEXT not LEMONADE).

The SUBMIT command apparently relies upon parsing of the RFC 2822 header
to extract the SMTP envelope information.  If that was a good idea, then
SMTP could have been much simpler.  I wonder why this great insight wasn't
presented during the RFC 2821 effort.

The document fails to discuss the following requirements of such a
mechanism:
 1) Any bcc headers must be removed prior to transmission.
 2) Handling of RFC 2822 group syntax (are the contents suppressed?) needs
    to be fully specified
 3) How is the SMTP Return-Path derived?
 4) How is the From: header line validated?

I hope that nobody claims that (3) and (4) are done from the IMAP login.

I also hope that you're not going to tell me that I can't use a valid
From: address just because the IMAP server doesn't have a clue about that
address.

There is further handwaving about "might replac[e] the Message-ID,
remov[e] any Received-By [sic] lines, Date, and so on."  Exactly what
processing is this mechanism to do?

I also note with considerable irony that the raison d'e^tre for the
effort, forwarding and resending of existing IMAP mailbox content, is
completely overlooked by this document.  Where is the tagging mechanism by
which data from the IMAP server is inserted in this message.

The tagged NO response adds a leading comma syntax not used by any other
IMAP command.  Why doesn't this use the standard status response code
mechanism?

As far as I can tell, this document is about one thing and one thing only:
adding a SUBMIT command to IMAP.  It uses the word "proxy" but in no
respects (other than an ASCII-art picture) exhibits any aspects of a
proxy.  Nor is it about any form of efficient forward/remail to mobile
clients.

-- 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 exim@www1.ietf.org  Tue Jun 17 17:32:29 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12413
	for <lemonade-archive@odin.ietf.org>; Tue, 17 Jun 2003 17:32:29 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5HLW2A12670
	for lemonade-archive@odin.ietf.org; Tue, 17 Jun 2003 17:32:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SO3e-0003IH-K2
	for lemonade-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 17:32:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12407
	for <lemonade-web-archive@ietf.org>; Tue, 17 Jun 2003 17:31:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SO1P-0005M4-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 17:29:43 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SO1O-0005M1-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 17:29:42 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SO3d-0003Hq-45; Tue, 17 Jun 2003 17:32:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SO3W-0003HU-TA
	for lemonade@optimus.ietf.org; Tue, 17 Jun 2003 17:31:54 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12404
	for <lemonade@ietf.org>; Tue, 17 Jun 2003 17:31:51 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SO1H-0005Lx-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 17:29:35 -0400
Received: from mxout5.cac.washington.edu ([140.142.32.135])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SO1G-0005Lu-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 17:29:34 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139])
	by mxout5.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h5HLVoGb025855
	for <lemonade@ietf.org>; Tue, 17 Jun 2003 14:31:50 -0700
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
	(authenticated bits=0)
	by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h5HLVo3i008336
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT)
	for <lemonade@ietf.org>; Tue, 17 Jun 2003 14:31:50 -0700
Date: Tue, 17 Jun 2003 14:31:49 -0700 (Pacific Daylight Time)
From: Mark Crispin <MRC@CAC.Washington.EDU>
To: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: Re: [lemonade] Mobile messaging clients barriers - Protocls vs. S
 erver Implementation
In-Reply-To: <3EEF83B1.1090309@Royer.com>
Message-ID: <Pine.WNT.4.60.0306171411560.1912@Tomobiki-Cho.CAC.Washington.EDU>
References: <7D4344E32B34D511A6500002A560C60204D8931B@il-tlv-mail4.comverse.com>
 <Pine.NXT.4.56.0306150758140.11845@Ikkoku-Kan.Panda.COM> <3EECD8CD.1030300@Royer.com>
 <Pine.NXT.4.56.0306151527450.11845@Ikkoku-Kan.Panda.COM> <3EED2703.3010103@Royer.com>
 <Pine.NXT.4.56.0306160757550.11845@Ikkoku-Kan.Panda.COM>
 <Pine.LNX.4.55L-033.0306170911420.15492@gobo.andrew.cmu.edu>
 <Pine.NXT.4.56.0306170641250.477@Ikkoku-Kan.Panda.COM> <3EEF6A96.7000406@Royer.com>
 <Pine.WNT.4.60.0306171326440.1912@Tomobiki-Cho.CAC.Washington.EDU>
 <3EEF83B1.1090309@Royer.com>
Organization: Networks & Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Tue, 17 Jun 2003, Doug Royer wrote:
> > It is very much an issue if a reference to more than one mailbox is
> > permitted in the submit request.  The result is an unresolvable submission
> > request.
> By mailbox do you mean MX host, or do you mean that you expect
> the IMAP server to APPEND to the IMAP mailboxes - That was Alan's
> proposal - not mine.

The term "mailbox" is defined in the IMAP base specification, RFC 3501.
You lectured me in public about how you are a great expect on all matters
related to IMAP; you should not need to ask me what a mailbox is.

The purpose of the exercise is to provide an efficient means of
forwarding/resending messages stored on an IMAP server.  This necessitates
a reference to a mailbox in the submit request.  That reference is either
implicit (selected mailbox) or explicit (by name).  If the latter, the
specification for the SUBMIT command has to stipulate one of three things:
 1) only one mailbox can be used in a submit request
 2) the server can not support RFC 2193 referrals
 3) the server must proxy RFC 2193 referrals (it can not return NO with a
     referral).

> By having the PROXY do the SMTP submission, the IMAP client
> would never need to know if the RCPT mailboxes were local,
> remote, on one MX host, or several MX hosts. They just
> submit the mime-blob.

What does an "MX host", which has to do with MTA operations, have to do
with RFC 2193 referrals or the submit operation?

If your answer is "proxy", then how is the client to know that it is
talking to a proxy as opposed to a non-proxy, since you insist that it be
on the same port as IMAP?

What you are creating is a separate fork in the IMAP protocol, sharing the
same fork with IMAP, which adds one capability (SUBMIT) and removes at
least one (referrals).  Is this something that the IETF wants to have?
Ned???

> > If you propose to solve this by requiring a proxy (which you suggest would
> > resolve referrals so the cell phone never sees it), then that begs the
> > question of how the user of the cell phone is to understand that detail.
> They would never know or care. Just like an IMAP client now never
> need to tell the user that the IMAP server redirected them to an alternate
> IMAP server.

If the client does not know or care, how does it send a message?

> > Specifically; the user knows from his desktop client that his IMAP server
> > is imap.foo.com.  So he configures his cell phone to use imap.foo.com,
> > which subsequently doesn't work because the port 143 server on
> > imap.foo.com is not a proxy server.  Since you insist upon using port
> > 143 for the proxy, a proxy server can't co-exist on imap.foo.com.
> So we agree. If you point your client to a server that does not
> understand submit, then they can not submit. :-)

Are you admitting that "mobile clients" is just a backdoor means of
sneaking submit into IMAP for desktop clients?

> It can co-exist as to non IMAP submit clients - it is a transparent proxy
> so existing clients can use the proxy and they never need to know they
> are using a proxy.

As you are using the term "proxy", you are referring to an internal
implementation detail and not a protocol element.  It therefore does not
belong in an IETF protocol specification, and all references to the term
"proxy" should be removed.

> > So the user has to know, specially for his cell phone, that he must use
> > proxy-imap.foo.com.  And foo.com has to set up this separate IP address
> > specifically for cell phones instead of just installing a new server on a
> > different port on the existing IP address.
> No. the ISP tells the user that they will be using imap.foo.com and they
> will never need to know that it is a submit server. Their normal IMAP
> client will work, and so will their cell phone.

Just how will the cell phone "work" with an existing IMAP server that does
not have submit?

You are making a completely dishonest argument.

> If their vendor
> updates their IMAP client for submit, then it will also work for submit.

Oh, so now desktop IMAP clients are expected to use this feature?

This is outside of the scope of LEMONADE.  It belongs in IMAPEXT.

> > All of this just to shoehorn submit-in-IMAP into the port 143 IMAP
> > service.  Why?
> Because it would be transparent to all existing IMAP clients, 143 and 993.

No, it's a fork within IMAP, and an attempt to make one of the two forks
mandatory by making it impossible to send mail with some clients.

> If it is a separate port then all existing IMAP clients would have
> to be re-configured to use the new port.

There is no reason for existing IMAP clients to use the new port.

The sole purpose of this WG is mobile clients.  If the scope is to expand
to other clients, the WG needs to be rechartered.

> > Why tie up the IMAP session while a submit is going on?  A separate IMAP
> > session from a submit session could be downloading new mail while the
> > message being submitted is being uploaded.
> Tie up? Most IMAP sessions are persistent anyway. It should not
> take any longer than an APPEND command.

The APPEND command does not have to validate recipient addresses, while
your document explicitly shows that a submit would do that.

-- 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 exim@www1.ietf.org  Tue Jun 17 17:53:29 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12808
	for <lemonade-archive@odin.ietf.org>; Tue, 17 Jun 2003 17:53:29 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5HLr2J15075
	for lemonade-archive@odin.ietf.org; Tue, 17 Jun 2003 17:53:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SONy-0003v4-Qk
	for lemonade-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 17:53:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12802
	for <lemonade-web-archive@ietf.org>; Tue, 17 Jun 2003 17:52:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SOLj-0005Rb-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 17:50:43 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SOLi-0005RY-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 17:50:42 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SONx-0003ud-CU; Tue, 17 Jun 2003 17:53:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SONs-0003uR-Te
	for lemonade@optimus.ietf.org; Tue, 17 Jun 2003 17:52:56 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12799
	for <lemonade@ietf.org>; Tue, 17 Jun 2003 17:52:53 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SOLd-0005RV-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 17:50:37 -0400
Received: from inet-consulting.com ([4.23.9.166] helo=royer.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SOLb-0005RS-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 17:50:35 -0400
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h5HLqcbt004395
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <lemonade@ietf.org>; Tue, 17 Jun 2003 14:52:48 -0700
Message-ID: <3EEF8D99.4060305@Royer.com>
Date: Tue, 17 Jun 2003 15:52:25 -0600
From: Doug Royer <Doug@Royer.com>
Reply-To: lemonade@ietf.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: lemonade@ietf.org
Subject: Re: [lemonade] draft-royer-lemonade-submit-00.txt
References: <200306171156.HAA08281@ietf.org> <Pine.WNT.4.60.0306171340380.1912@Tomobiki-Cho.CAC.Washington.EDU>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090507070900090707000308"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This is a cryptographically signed message in MIME format.

--------------ms090507070900090707000308
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Mark Crispin wrote:
> Why is this called an "IMAP proxy" instead of an "IMAP and SMTP proxy"?

Its just a strings of characters that made a readable name.

> This document very suspiciously refers to a "standard IMAP client" as
> being a client of the proxy.  I thought that this was about about
> providing an efficient means of forward and remail for mobile clients, not
> a backdoor attempt (without going through IMAPEXT) to force submit into
> IMAP for all clients.

Why is is 'suspicious'? There have been no hidden e-mail between
conspirators to do horrible things. Even with the proxy, no one would
be FORCING anything. It is an optional over the wire extension use it, or not.

> Nothing, other than some handwaving in section 2, gives any indication of
> how this is an "IMAP proxy" rather an added CAN-SUBMIT extension to the
> IMAP protocol (which belongs in IMAPEXT not LEMONADE).

Yet it is part of this lemonade debate.

> The SUBMIT command apparently relies upon parsing of the RFC 2822 header
> to extract the SMTP envelope information.  If that was a good idea, then
> SMTP could have been much simpler.  I wonder why this great insight wasn't
> presented during the RFC 2821 effort.

I do not know. Did you ask Pete?
I suspect that it had a lot to do with the fact they wanted to
be compatible with 82[12].


> The document fails to discuss the following requirements of such a
> mechanism:
>  1) Any bcc headers must be removed prior to transmission.

Good point. I am sure we can add something.

>  2) Handling of RFC 2822 group syntax (are the contents suppressed?) needs
>     to be fully specified

I forgot about those. Good point.

>  3) How is the SMTP Return-Path derived?

The proxy can be configured to conform to the ISPs standards.

>  4) How is the From: header line validated?

Same as (3).

> I hope that nobody claims that (3) and (4) are done from the IMAP login.

That would be up to the ISP and vendor. It does not need to be
hard coded in the spec. It just needs to be mentioned.

> I also hope that you're not going to tell me that I can't use a valid
> From: address just because the IMAP server doesn't have a clue about that
> address.

Correct, I was not proposing that the validation information come
from the IMAP server. I was suggesting that an implementation
may add validation checking at that point so they do not have
to alter their SMTP or IMAP server.

> There is further handwaving about "might replac[e] the Message-ID,
> remov[e] any Received-By [sic] lines, Date, and so on."  Exactly what
> processing is this mechanism to do?

What is need to enforce site policy and track spam sources. No specific
thing must be done. Just a catch all to allow those to be done.

> I also note with considerable irony that the raison d'e^tre for the
> effort, forwarding and resending of existing IMAP mailbox content, is
> completely overlooked by this document.  Where is the tagging mechanism by
> which data from the IMAP server is inserted in this message.

It is not overlooked, it is skipped and it says that it is skipped.
It was not a proposal for the include mechanism, it is a proposal
for a proxy mechanism that uses the include mechanism.

> The tagged NO response adds a leading comma syntax not used by any other
> IMAP command.  Why doesn't this use the standard status response code
> mechanism?

Off of the top of my head I do not recall any formatted NO responses.
If there is one, I would be happy to use that format.

> As far as I can tell, this document is about one thing and one thing only:
> adding a SUBMIT command to IMAP.  It uses the word "proxy" but in no
> respects (other than an ASCII-art picture) exhibits any aspects of a
> proxy.  Nor is it about any form of efficient forward/remail to mobile
> clients.

It is about how to allow IMAP clients the ability to submit. This
plus the yet undefined include mechanism would solve the problem
of forward and include without download for IMAP clients with
minimum over the wire protocol changes.

If you are correct and it is horrible or impossible to add this
to an IMAP server, then this would work and not effect existing clients.

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  Doug@Royer.com                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

--------------ms090507070900090707000308
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC
A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j
cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB
MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T
BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN
VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre
qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+
5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA
MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg
TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD
QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx
ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz
IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq
hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34
1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA
gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK
YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd
SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC
AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF
BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl
cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl
IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs
MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq
1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2
TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail
MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE
AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO
b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG
MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD
VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV
BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv
43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y
lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP
D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn
0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK
bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg
hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT
IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI
AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t
L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk
OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW
yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1
MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl
ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTcyMTUyMjZaMCMGCSqGSIb3DQEJBDEWBBQF
/doQNQ2Ty95+XEpFrP0T/ZB52TBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL
KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAZ3GgLumJNd4d
NTZmgajKMj5fiA11TgRHJOitjY+Jnns1b/0TaYov4vo/OnvOiGXGbHD5jB4BAcVA7ZftRU1Q
c+X8oD3Mt3gwl+BfBA0z5beBRelvrkS02bEgk61iRFHqmbC2t1YeZMnK8JfNUaHWM2yHLDmF
yBTlhmHvK+8zb4cgFrIZjsnaWimwU8vhITotmUTQ0pPcUnlUufYC0zBwzaN+dBcMwsN3/6zD
NwzCzGwBdVZ2b21sheigWSodx0vln0rMRdQqGbBdbkJZpiInJUW+9/DHPY7PEd7FGxhnvMis
cSaBRuJ/Ur6mQbcSAtlM+3bwqVsbOLJTmSf2t5QFBwAAAAAAAA==
--------------ms090507070900090707000308--


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



From exim@www1.ietf.org  Tue Jun 17 17:59:29 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12963
	for <lemonade-archive@odin.ietf.org>; Tue, 17 Jun 2003 17:59:29 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5HLx2e16048
	for lemonade-archive@odin.ietf.org; Tue, 17 Jun 2003 17:59:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SOTm-0004Al-Nz
	for lemonade-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 17:59:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12960
	for <lemonade-web-archive@ietf.org>; Tue, 17 Jun 2003 17:58:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SORX-0005Tv-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 17:56:43 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SORW-0005Ts-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 17:56:42 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SOTl-00049c-HW; Tue, 17 Jun 2003 17:59:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SOTI-00049M-Mw
	for lemonade@optimus.ietf.org; Tue, 17 Jun 2003 17:58:32 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12957
	for <lemonade@ietf.org>; Tue, 17 Jun 2003 17:58:29 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SOR3-0005Ti-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 17:56:13 -0400
Received: from inet-consulting.com ([4.23.9.166] helo=royer.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SOR1-0005Tf-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 17:56:11 -0400
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h5HLwIbt004445
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <lemonade@ietf.org>; Tue, 17 Jun 2003 14:58:26 -0700
Message-ID: <3EEF8EF4.2020505@Royer.com>
Date: Tue, 17 Jun 2003 15:58:12 -0600
From: Doug Royer <Doug@Royer.com>
Reply-To: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: Re: [lemonade] Mobile messaging clients barriers - Protocls vs. S
 erver Implementation
References: <7D4344E32B34D511A6500002A560C60204D8931B@il-tlv-mail4.comverse.com> <Pine.NXT.4.56.0306150758140.11845@Ikkoku-Kan.Panda.COM> <3EECD8CD.1030300@Royer.com> <Pine.NXT.4.56.0306151527450.11845@Ikkoku-Kan.Panda.COM> <3EED2703.3010103@Royer.com> <Pine.NXT.4.56.0306160757550.11845@Ikkoku-Kan.Panda.COM> <Pine.LNX.4.55L-033.0306170911420.15492@gobo.andrew.cmu.edu> <Pine.NXT.4.56.0306170641250.477@Ikkoku-Kan.Panda.COM> <3EEF6A96.7000406@Royer.com> <Pine.WNT.4.60.0306171326440.1912@Tomobiki-Cho.CAC.Washington.EDU> <3EEF83B1.1090309@Royer.com> <Pine.WNT.4.60.0306171411560.1912@Tomobiki-Cho.CAC.Washington.EDU>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060302010802010903020100"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This is a cryptographically signed message in MIME format.

--------------ms060302010802010903020100
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Mark Crispin wrote:
> On Tue, 17 Jun 2003, Doug Royer wrote:
> 
>>>It is very much an issue if a reference to more than one mailbox is
>>>permitted in the submit request.  The result is an unresolvable submission
>>>request.
>>
>>By mailbox do you mean MX host, or do you mean that you expect
>>the IMAP server to APPEND to the IMAP mailboxes - That was Alan's
>>proposal - not mine.
> 
> 
> The term "mailbox" is defined in the IMAP base specification, RFC 3501.
> You lectured me in public about how you are a great expect on all matters
> related to IMAP; you should not need to ask me what a mailbox is.

So could you answer the question? Were you refering to my proposal
or Alan's? My draft did not include the word 'mailbox'. So
I assume you are refering to the APPEND to OUTBOX and some
background process does the work?

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  Doug@Royer.com                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

--------------ms060302010802010903020100
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC
A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j
cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB
MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T
BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN
VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre
qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+
5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA
MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg
TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD
QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx
ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz
IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq
hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34
1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA
gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK
YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd
SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC
AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF
BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl
cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl
IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs
MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq
1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2
TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail
MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE
AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO
b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG
MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD
VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV
BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv
43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y
lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP
D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn
0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK
bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg
hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT
IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI
AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t
L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk
OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW
yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1
MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl
ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTcyMTU4MTNaMCMGCSqGSIb3DQEJBDEWBBSy
Hxz4jH0prPBdWBNVGyPVuxj2vDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL
KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAOOqFnql0BbxN
fM1j/WKZmbaTJb1qTXTtb/ZMwgKf+Ihslnubf4oRyFyUt79ODN/H7RRWaLXQXSkM02Up9uM7
glxORPh2xBJ5zePLlENOlMI2ApeZ5f9G2x6ChDwuVbjza6m+j7XmgbgVP9Y7DHm/xOJjQ1ha
Xsz+wWJIDG1HoZasbRK9QgNZIjsm/vYGc9VRWynSsyu/THVwsNmyPPL9nwDzRbCcBdyo0sib
JWvs+TJKMg22jOUDRLyA6wp6ihpUvgoFHO0VcWuz5Tso9OreWVFvzDBhff+9xD1zj0vMFsM9
bU4LgUoO9SxMo0x06TO4tLleu+OqG2qR6bt4+D7qcAAAAAAAAA==
--------------ms060302010802010903020100--


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



From exim@www1.ietf.org  Tue Jun 17 18:11:29 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13975
	for <lemonade-archive@odin.ietf.org>; Tue, 17 Jun 2003 18:11:29 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5HMB3r17505
	for lemonade-archive@odin.ietf.org; Tue, 17 Jun 2003 18:11:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SOfO-0004YG-Vm
	for lemonade-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 18:11:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13898
	for <lemonade-web-archive@ietf.org>; Tue, 17 Jun 2003 18:10:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SOd9-0005Wi-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 18:08:43 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SOd8-0005Wf-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 18:08:42 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SOfN-0004Wx-7v; Tue, 17 Jun 2003 18:11:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SOf7-0004WW-QU
	for lemonade@optimus.ietf.org; Tue, 17 Jun 2003 18:10:45 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13863
	for <lemonade@ietf.org>; Tue, 17 Jun 2003 18:10:41 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SOcs-0005WQ-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 18:08:26 -0400
Received: from mxout5.cac.washington.edu ([140.142.32.135])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SOcr-0005WN-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 18:08:25 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139])
	by mxout5.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h5HMAfGb000606
	for <lemonade@ietf.org>; Tue, 17 Jun 2003 15:10:41 -0700
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
	(authenticated bits=0)
	by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h5HMAf3i010706
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT)
	for <lemonade@ietf.org>; Tue, 17 Jun 2003 15:10:41 -0700
Date: Tue, 17 Jun 2003 15:10:40 -0700 (Pacific Daylight Time)
From: Mark Crispin <MRC@CAC.Washington.EDU>
To: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: Re: [lemonade] Mobile messaging clients barriers - Protocls vs. S
 erver Implementation
In-Reply-To: <3EEF8EF4.2020505@Royer.com>
Message-ID: <Pine.WNT.4.60.0306171503060.1912@Tomobiki-Cho.CAC.Washington.EDU>
References: <7D4344E32B34D511A6500002A560C60204D8931B@il-tlv-mail4.comverse.com>
 <Pine.NXT.4.56.0306150758140.11845@Ikkoku-Kan.Panda.COM> <3EECD8CD.1030300@Royer.com>
 <Pine.NXT.4.56.0306151527450.11845@Ikkoku-Kan.Panda.COM> <3EED2703.3010103@Royer.com>
 <Pine.NXT.4.56.0306160757550.11845@Ikkoku-Kan.Panda.COM>
 <Pine.LNX.4.55L-033.0306170911420.15492@gobo.andrew.cmu.edu>
 <Pine.NXT.4.56.0306170641250.477@Ikkoku-Kan.Panda.COM> <3EEF6A96.7000406@Royer.com>
 <Pine.WNT.4.60.0306171326440.1912@Tomobiki-Cho.CAC.Washington.EDU>
 <3EEF83B1.1090309@Royer.com> <Pine.WNT.4.60.0306171411560.1912@Tomobiki-Cho.CAC.Washington.EDU>
 <3EEF8EF4.2020505@Royer.com>
Organization: Networks & Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Tue, 17 Jun 2003, Doug Royer wrote:
> So could you answer the question? Were you refering to my proposal
> or Alan's?

The answer is "yes".

Any submit-in-IMAP proposal has to deal with the issue of how RFC 2193
affects a mailbox reference in the submit request.  There are three
possible ways of doing this, which I listed in my previous message.

> So
> I assume you are refering to the APPEND to OUTBOX and some
> background process does the work?

No, I am not referring to a mechanism which does submit via APPEND to a
special name such as OUTBOX.

I am referring to the entire reason why this exercise is taking place: an
efficient means of forward/resend, and a restriction which is unique to
the submit-in-IMAP mechanism as opposed to other mechanisms.

-- 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 exim@www1.ietf.org  Tue Jun 17 18:34:29 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14928
	for <lemonade-archive@odin.ietf.org>; Tue, 17 Jun 2003 18:34:29 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5HMY2519255
	for lemonade-archive@odin.ietf.org; Tue, 17 Jun 2003 18:34:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SP1e-00050L-S6
	for lemonade-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 18:34:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14857
	for <lemonade-web-archive@ietf.org>; Tue, 17 Jun 2003 18:33:58 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SOzP-0005do-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 18:31:43 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SOzO-0005dl-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 18:31:42 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SP1d-0004zo-Hd; Tue, 17 Jun 2003 18:34:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SP0w-0004vV-6e
	for lemonade@optimus.ietf.org; Tue, 17 Jun 2003 18:33:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14798
	for <lemonade@ietf.org>; Tue, 17 Jun 2003 18:33:14 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SOyg-0005dC-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 18:30:58 -0400
Received: from inet-consulting.com ([4.23.9.166] helo=royer.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SOye-0005d9-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 18:30:57 -0400
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h5HMX0bt004742
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <lemonade@ietf.org>; Tue, 17 Jun 2003 15:33:10 -0700
Message-ID: <3EEF970E.9050708@Royer.com>
Date: Tue, 17 Jun 2003 16:32:46 -0600
From: Doug Royer <Doug@Royer.com>
Reply-To: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: Re: [lemonade] Mobile messaging clients barriers - Protocls vs. S
 erver Implementation
References: <7D4344E32B34D511A6500002A560C60204D8931B@il-tlv-mail4.comverse.com> <Pine.NXT.4.56.0306150758140.11845@Ikkoku-Kan.Panda.COM> <3EECD8CD.1030300@Royer.com> <Pine.NXT.4.56.0306151527450.11845@Ikkoku-Kan.Panda.COM> <3EED2703.3010103@Royer.com> <Pine.NXT.4.56.0306160757550.11845@Ikkoku-Kan.Panda.COM> <Pine.LNX.4.55L-033.0306170911420.15492@gobo.andrew.cmu.edu> <Pine.NXT.4.56.0306170641250.477@Ikkoku-Kan.Panda.COM> <3EEF6A96.7000406@Royer.com> <Pine.WNT.4.60.0306171326440.1912@Tomobiki-Cho.CAC.Washington.EDU> <3EEF83B1.1090309@Royer.com> <Pine.WNT.4.60.0306171411560.1912@Tomobiki-Cho.CAC.Washington.EDU> <3EEF8EF4.2020505@Royer.com> <Pine.WNT.4.60.0306171503060.1912@Tomobiki-Cho.CAC.Washington.EDU>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040207030408020308060203"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This is a cryptographically signed message in MIME format.

--------------ms040207030408020308060203
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Mark Crispin wrote:
> On Tue, 17 Jun 2003, Doug Royer wrote:
> 
>>So could you answer the question? Were you refering to my proposal
>>or Alan's?
> 
> 
> The answer is "yes".

Thanks - I'll let Alan answer.


-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  Doug@Royer.com                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

--------------ms040207030408020308060203
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC
A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j
cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB
MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T
BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN
VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre
qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+
5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA
MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg
TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD
QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx
ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz
IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq
hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34
1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA
gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK
YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd
SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC
AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF
BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl
cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl
IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs
MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq
1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2
TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail
MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE
AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO
b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG
MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD
VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV
BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv
43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y
lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP
D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn
0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK
bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg
hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT
IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI
AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t
L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk
OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW
yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1
MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl
ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTcyMjMyNDdaMCMGCSqGSIb3DQEJBDEWBBRq
BT4U7M8h47/IPcQ7YKRN95DGojBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL
KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAgFOv5wFsu+sy
/lp6xIg73TPH3L7ncwt3ZYMNX3rrFeA+FyBEC/iTfFeuXazPGEi8K+obIFXuB87o5ECW1nKy
mGtpaNrMPzj9VZQAKLh0V7nSKz2tFKKkqu++hrARx+EUCit5yFWcXl9BwKXQp10SlTTe6H8h
HRe04Olp1+hOi0gBV2c6LF/JmG9dEJszlwvhvONyueDd3c8axt9hU9Oi19TbdZx0DlEaGpBV
8yxVJwApGmoilrZ6f1axVfjWsIfIL+uhJQcPjE8Po8hWV+Vjj/Xdnp9ac/zxk03C6gUD+/r8
4zzmEV49HwtWrf7OTFEBWZ2q+2NBf5mR9/jjP4zmFgAAAAAAAA==
--------------ms040207030408020308060203--


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



From exim@www1.ietf.org  Tue Jun 17 18:41:31 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15195
	for <lemonade-archive@odin.ietf.org>; Tue, 17 Jun 2003 18:41:31 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5HMf5420931
	for lemonade-archive@odin.ietf.org; Tue, 17 Jun 2003 18:41:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SP8T-0005RW-6Z
	for lemonade-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 18:41:05 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15182
	for <lemonade-web-archive@ietf.org>; Tue, 17 Jun 2003 18:41:01 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SP6D-0005gj-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 18:38:45 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SP6C-0005gg-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 18:38:44 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SP8Q-0005QJ-16; Tue, 17 Jun 2003 18:41:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SP8B-0005Q1-0s
	for lemonade@optimus.ietf.org; Tue, 17 Jun 2003 18:40:47 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15151
	for <lemonade@ietf.org>; Tue, 17 Jun 2003 18:40:42 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SP5v-0005gQ-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 18:38:27 -0400
Received: from champdsl-25-66.mcleodusa.net ([216.43.25.66] helo=episteme-software.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SP5u-0005g1-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 18:38:26 -0400
Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with
 ESMTP (Eudora Internet Mail Server X 3.2.2b1);
 Tue, 17 Jun 2003 17:39:58 -0500
Mime-Version: 1.0
X-Sender: resnick@resnick1.qualcomm.com
Message-Id: <p06001522bb15389605f3@[216.43.25.67]>
In-Reply-To: 
 <Pine.WNT.4.60.0306171340380.1912@Tomobiki-Cho.CAC.Washington.EDU>
References: <200306171156.HAA08281@ietf.org>
 <Pine.WNT.4.60.0306171340380.1912@Tomobiki-Cho.CAC.Washington.EDU>
X-Mailer: Eudora [Macintosh version 6.0a15]
Date: Tue, 17 Jun 2003 17:40:04 -0500
To: Mark Crispin <MRC@CAC.Washington.EDU>
From: Pete Resnick <presnick@qualcomm.com>
Cc: lemonade@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Subject: [lemonade] Point-of-order re IMAPEXT (Was:
 draft-royer-lemonade-submit-00.txt)
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

With my "chair-of-IMAPEXT" hat planted firmly on my head:

On 6/17/03 at 2:11 PM -0700, Mark Crispin wrote:

>...a backdoor attempt (without going through IMAPEXT) to force 
>submit into IMAP for all clients.
>
>...extension to the IMAP protocol (which belongs in IMAPEXT not LEMONADE).

Though the length of its life would seem to indicate otherwise, 
IMAPEXT is not some sort of a permanent standing working group that 
works on any IMAP extension that comes along. IMAPEXT has a charter 
which indicates certain tasks to be completed, and after those task 
are completed, it is finished. (Perhaps it would have been better to 
name the group "IMAPSORTTHREADANNOTATE".) Nothing *belongs* in 
IMAPEXT that isn't already on the charter of IMAPEXT. There are folks 
who work on IMAP issues, and they can just as well participate in 
LEMONADE as any other group if there is a suggestion to solve a 
LEMONADE problem with an IMAP extension. That a proposed solution is 
an IMAP extension is not a basis for saying it does not belong in 
LEMONADE.

End of point of order.

pr
-- 
Pete Resnick <mailto:presnick@qualcomm.com>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

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



From exim@www1.ietf.org  Tue Jun 17 18:50:29 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15412
	for <lemonade-archive@odin.ietf.org>; Tue, 17 Jun 2003 18:50:28 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5HMo2O21949
	for lemonade-archive@odin.ietf.org; Tue, 17 Jun 2003 18:50:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SPH8-0005hw-Qa
	for lemonade-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 18:50:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15394
	for <lemonade-web-archive@ietf.org>; Tue, 17 Jun 2003 18:49:58 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SPEs-0005jA-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 18:47:42 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SPEs-0005j7-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 18:47:42 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SPH7-0005gn-HW; Tue, 17 Jun 2003 18:50:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SPGZ-0005gJ-OA
	for lemonade@optimus.ietf.org; Tue, 17 Jun 2003 18:49:27 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15377
	for <lemonade@ietf.org>; Tue, 17 Jun 2003 18:49:23 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SPEJ-0005j2-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 18:47:07 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SPEI-0005iz-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 18:47:06 -0400
Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151])
	by ithilien.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h5HMnEZf028759;
	Tue, 17 Jun 2003 15:49:14 -0700 (PDT)
Received: from [129.46.74.63] (loud.qualcomm.com [129.46.74.63])
	by crowley.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h5HMnBix010995;
	Tue, 17 Jun 2003 15:49:11 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <a060014bbbb154add24b2@[129.46.74.63]>
In-Reply-To: <Pine.NXT.4.56.0306170623230.477@Ikkoku-Kan.Panda.COM>
References: 
 <E1542177268FD511866B0002A560C808053FDC51@il-tlv-mail5.comverse.com>
 <Pine.NXT.4.56.0306170623230.477@Ikkoku-Kan.Panda.COM>
X-Mailer: Eudora for Mac OS X v6.0a
Date: Tue, 17 Jun 2003 15:48:50 -0700
To: Mark Crispin <mrc@CAC.Washington.EDU>,
        Mendelovich Meir <Meir.Mendelovich@comverse.com>
From: Randall Gellens <randy@qualcomm.com>
Subject: RE: [lemonade] Mobile messaging clients barriers - IMAP4
 "passiva  tion"
Cc: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>, ned.freed@mrochek.com,
        "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b25
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

At 6:41 AM -0700 6/17/03, Mark Crispin wrote:

>  The benefit of TCP/IP
>  technology is that I could have a 10 *minute* network outage and still
>  recover my session when connectivity is restored.

I regularly put my PowerBook to sleep and carry it to meetings.  It 
generally takes much several minutes for me to get there and 
reconnect to the network.  My ssh tunnels stay up during this period.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Anyone can do any amount of work provided it isn't the work he is
supposed to be doing at the moment.               --Robert Benchley

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



From exim@www1.ietf.org  Tue Jun 17 18:54:28 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15491
	for <lemonade-archive@odin.ietf.org>; Tue, 17 Jun 2003 18:54:28 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5HMs2w22507
	for lemonade-archive@odin.ietf.org; Tue, 17 Jun 2003 18:54:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SPL0-0005qw-MM
	for lemonade-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 18:54:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15488
	for <lemonade-web-archive@ietf.org>; Tue, 17 Jun 2003 18:53:58 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SPIk-0005kb-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 18:51:42 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SPIk-0005kY-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 18:51:42 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SPKz-0005pO-8T; Tue, 17 Jun 2003 18:54:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SPKG-0005nR-Uv
	for lemonade@optimus.ietf.org; Tue, 17 Jun 2003 18:53:16 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15464
	for <lemonade@ietf.org>; Tue, 17 Jun 2003 18:53:12 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SPI0-0005kE-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 18:50:56 -0400
Received: from mxout2.cac.washington.edu ([140.142.33.4])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SPI0-0005kB-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 18:50:56 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9])
	by mxout2.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h5HMrCbr024587;
	Tue, 17 Jun 2003 15:53:12 -0700
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
	(authenticated bits=0)
	by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h5HMrB3n011804
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Tue, 17 Jun 2003 15:53:11 -0700
Date: Tue, 17 Jun 2003 15:53:10 -0700 (Pacific Daylight Time)
From: Mark Crispin <MRC@CAC.Washington.EDU>
To: Pete Resnick <presnick@qualcomm.com>
cc: lemonade@ietf.org
In-Reply-To: <p06001522bb15389605f3@[216.43.25.67]>
Message-ID: <Pine.WNT.4.60.0306171542121.1912@Tomobiki-Cho.CAC.Washington.EDU>
References: <200306171156.HAA08281@ietf.org>
 <Pine.WNT.4.60.0306171340380.1912@Tomobiki-Cho.CAC.Washington.EDU>
 <p06001522bb15389605f3@[216.43.25.67]>
Organization: Networks & Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [lemonade] Re: Point-of-order re IMAPEXT (Was: draft-royer-lemonade-submit-00.txt)
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

Well, Pete, I agree with you that "nothing belongs in IMAPEXT that isn't
already on the charter of IMAPEXT", and confess a backdoor motivation;
shove "submit as a general extension for all clients, not just mobile
clients" from LEMONADE (where extensions for non-mobile clients are
outside of charter) to IMAPEXT, which promptly tosses it as outside of its
charter.

> That a proposed solution is
> an IMAP extension is not a basis for saying it does not belong in
> LEMONADE.

No, but...:

The charter states that "Lemonade is tasked to provide a set of
enhancements and profiles of Internet email submission, transport, and
retrieval protocols to facilitate operation on platforms with constrained
resources, or communications links with high latency or limited
bandwidth."

The submit document explicitly states that it is to be used on others
platforms.  What's more, the submit document does not address work item
(2) at all.

Since the submit document covers platforms other than what is in the
charter, and because it does not address any of the work items of the
charter, I claim that it does not belong in LEMONADE.

A possible fix to this document would be to remove all references to
non-mobile clients and to add the functionality for work item (2).

-- 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 exim@www1.ietf.org  Tue Jun 17 19:13:28 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15809
	for <lemonade-archive@odin.ietf.org>; Tue, 17 Jun 2003 19:13:28 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5HND0X24360
	for lemonade-archive@odin.ietf.org; Tue, 17 Jun 2003 19:13:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SPdM-0006Kp-ER
	for lemonade-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 19:13:00 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15774
	for <lemonade-web-archive@ietf.org>; Tue, 17 Jun 2003 19:12:57 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SPb8-0005oI-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 19:10:42 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SPb7-0005oF-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 19:10:41 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SPdL-0006Jo-0B; Tue, 17 Jun 2003 19:12:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SPcq-0006JX-46
	for lemonade@optimus.ietf.org; Tue, 17 Jun 2003 19:12:28 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15769
	for <lemonade@ietf.org>; Tue, 17 Jun 2003 19:12:25 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SPab-0005oB-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 19:10:09 -0400
Received: from mxout2.cac.washington.edu ([140.142.33.4])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SPaa-0005o8-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 19:10:08 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139])
	by mxout2.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h5HNCObr027881;
	Tue, 17 Jun 2003 16:12:25 -0700
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
	(authenticated bits=0)
	by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h5HNCO3i014530
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Tue, 17 Jun 2003 16:12:24 -0700
Date: Tue, 17 Jun 2003 16:12:23 -0700 (Pacific Daylight Time)
From: Mark Crispin <MRC@CAC.Washington.EDU>
To: Randall Gellens <randy@qualcomm.com>
cc: "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Subject: RE: [lemonade] Mobile messaging clients barriers - IMAP4 "passiva 
 tion"
In-Reply-To: <a060014bbbb154add24b2@[129.46.74.63]>
Message-ID: <Pine.WNT.4.60.0306171553380.1912@Tomobiki-Cho.CAC.Washington.EDU>
References: <E1542177268FD511866B0002A560C808053FDC51@il-tlv-mail5.comverse.com>
 <Pine.NXT.4.56.0306170623230.477@Ikkoku-Kan.Panda.COM> <a060014bbbb154add24b2@[129.46.74.63]>
Organization: Networks & Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Tue, 17 Jun 2003, Randall Gellens wrote:
> I regularly put my PowerBook to sleep and carry it to meetings.  It
> generally takes much several minutes for me to get there and
> reconnect to the network.  My ssh tunnels stay up during this period.

This works like a champ in TOPS-20.  My favorite trick is to put TOPS-20,
running under VMware, to sleep, *reboot* the underlying machine, resume
TOPS-20 (perhaps after a few hours), and show folks that its TCP sessions
are still alive and communicating.  That's how TCP is supposed to work!

It also seems to work in UNIX, but I don't use UNIX on a laptop that much.

It doesn't seem to work in Windows XP; putting the PC to sleep seems to be
treated as a request to kill all open network connections.

I could perhaps understand if it threw up a panel and ask what I wanted to
do if it can't regain the lease on the same IP address.  But unilaterally
killing perfectly good TCP connections is a bug.

Data is not the same as voice calls.  An outage should not destroy a data
call without the user's permission.

-- 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 exim@www1.ietf.org  Tue Jun 17 20:00:33 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16502
	for <lemonade-archive@odin.ietf.org>; Tue, 17 Jun 2003 20:00:33 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5I003q27384
	for lemonade-archive@odin.ietf.org; Tue, 17 Jun 2003 20:00:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SQMt-00077b-OX
	for lemonade-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 20:00:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16482
	for <lemonade-web-archive@ietf.org>; Tue, 17 Jun 2003 20:00:02 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SQKe-00060N-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 19:57:45 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SQKe-00060K-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 19:57:44 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SQMr-00077A-2j; Tue, 17 Jun 2003 20:00:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SQMQ-00076T-6D
	for lemonade@optimus.ietf.org; Tue, 17 Jun 2003 19:59:34 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16476
	for <lemonade@ietf.org>; Tue, 17 Jun 2003 19:59:32 -0400 (EDT)
From: ned.freed@mrochek.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SQKB-00060C-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 19:57:15 -0400
Received: from mauve.mrochek.com ([209.55.107.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SQKA-000604-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 19:57:14 -0400
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243)
 id <01KX5QV6BNCG00CUGD@mauve.mrochek.com> for lemonade@ietf.org; Tue,
 17 Jun 2003 16:59:14 -0700 (PDT)
Date: Tue, 17 Jun 2003 16:51:46 -0700 (PDT)
Subject: RE: [lemonade] Mobile messaging clients barriers - IMAP4
 "passiva  tion"
In-reply-to: "Your message dated Tue, 17 Jun 2003 15:48:50 -0700"
 <a060014bbbb154add24b2@[129.46.74.63]>
To: Randall Gellens <randy@qualcomm.com>
Cc: Mark Crispin <mrc@CAC.Washington.EDU>,
        Mendelovich Meir <Meir.Mendelovich@comverse.com>,
        "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>, ned.freed@mrochek.com,
        "IETF LEMONADE (E-mail)" <lemonade@ietf.org>
Message-id: <01KX7IJX93NG00CUGD@mauve.mrochek.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
References: 
 <E1542177268FD511866B0002A560C808053FDC51@il-tlv-mail5.comverse.com>
 <Pine.NXT.4.56.0306170623230.477@Ikkoku-Kan.Panda.COM>
 <a060014bbbb154add24b2@[129.46.74.63]>
Content-Transfer-Encoding: 7BIT
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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-Transfer-Encoding: 7BIT
Content-Transfer-Encoding: 7BIT

> At 6:41 AM -0700 6/17/03, Mark Crispin wrote:

> >  The benefit of TCP/IP
> >  technology is that I could have a 10 *minute* network outage and still
> >  recover my session when connectivity is restored.

> I regularly put my PowerBook to sleep and carry it to meetings.  It
> generally takes much several minutes for me to get there and
> reconnect to the network.  My ssh tunnels stay up during this period.

Indeed. I have to say that one of the most compelling reasons I've found for
upgrading from OS 9 to OS X is that OS 9 closed all connections when it went to
sleep whereas OS X does not. I take advantage of this several times every day
now.

I have to confess that until I experienced the OS X way I didn't realize just
how important this is and how much of a botch OS 9's behavior was.

				Ned

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



From exim@www1.ietf.org  Tue Jun 17 20:07:31 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16624
	for <lemonade-archive@odin.ietf.org>; Tue, 17 Jun 2003 20:07:31 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5I072927892
	for lemonade-archive@odin.ietf.org; Tue, 17 Jun 2003 20:07:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SQTe-0007Fn-2O
	for lemonade-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 20:07:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16616
	for <lemonade-web-archive@ietf.org>; Tue, 17 Jun 2003 20:07:00 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SQRP-00061x-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 20:04:43 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SQRO-00061u-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 20:04:42 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SQTc-0007Ee-Qh; Tue, 17 Jun 2003 20:07:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SQSw-0007Dy-H2
	for lemonade@optimus.ietf.org; Tue, 17 Jun 2003 20:06:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16610
	for <lemonade@ietf.org>; Tue, 17 Jun 2003 20:06:17 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SQQh-00061o-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 20:03:59 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SQQg-00061l-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 20:03:59 -0400
Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149])
	by numenor.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h5I06DBd010429
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
	for <lemonade@ietf.org>; Tue, 17 Jun 2003 17:06:14 -0700 (PDT)
Received: from [129.46.74.63] (loud.qualcomm.com [129.46.74.63])
	by neophyte.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h5I06Buh012435
	for <lemonade@ietf.org>; Tue, 17 Jun 2003 17:06:12 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <a06001501bb1559c0a1d1@[129.46.74.63]>
X-Mailer: Eudora for Mac OS X v6.0a
Date: Tue, 17 Jun 2003 17:02:28 -0700
To: lemonade@ietf.org
From: Randall Gellens <randy@qualcomm.com>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Subject: [lemonade] IMAP "Proxy"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

There's been a lot of discussion about how to allow IMAP clients to 
accomplish forward-without-download.  The two main camps could be 
termed "IMAP Push" and "IMAP Pull".  There has been some excellent 
technical debate about the merits and pitfalls of both techniques.

A third approach has been proposed, called "IMAP Proxy".

To the extent that such a mechanism in fact is a proxy for IMAP and 
Submit, it would be invisible to clients, and hence what we are 
really discussing is "IMAP Push" and a potential implementation path. 
To the extent that such a mechanism is not a proxy, it is instead a 
new protocol that subsumes the functionality of both IMAP and Submit, 
and hence allows the chattiness and verbosity of these protocols to 
go away.

While it is awful tempting to start fresh with IMAP and Submit, and 
in fact a lot of problems could be solved this way, it would also 
represent a very significant step, and one would face great 
uncertainty for success.

Earlier in the discussion some of us expressed concern that any 
potential "IMAP Push" mechanism could lead to two separate ways of 
doing message submission: one for IMAP clients and one for all other 
clients (which include POP-only as well as submit-only).  New 
features would then have to be added separately to each submission 
mechanism.  This danger would be several times worse with the "IMAP 
Proxy/IMAP II" approach.  If we go down this path, we'd have to 
officially deprecate IMAP, or else we'd end up with two separate 
mechanisms for doing IMAP-like things: IMAP and IMAP II.

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



From exim@www1.ietf.org  Tue Jun 17 20:10:32 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16675
	for <lemonade-archive@odin.ietf.org>; Tue, 17 Jun 2003 20:10:32 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5I0A3L29040
	for lemonade-archive@odin.ietf.org; Tue, 17 Jun 2003 20:10:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SQWZ-0007YJ-54
	for lemonade-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 20:10:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16665
	for <lemonade-web-archive@ietf.org>; Tue, 17 Jun 2003 20:10:01 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SQUK-00062Z-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 20:07:44 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SQUJ-00062W-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 20:07:43 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SQWX-0007XA-QZ; Tue, 17 Jun 2003 20:10:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SQWG-0007Wk-Ck
	for lemonade@optimus.ietf.org; Tue, 17 Jun 2003 20:09:44 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16661
	for <lemonade@ietf.org>; Tue, 17 Jun 2003 20:09:42 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SQU1-00062S-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 20:07:25 -0400
Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SQU0-00062P-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 20:07:24 -0400
Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83])
	by ihemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h5I098P10686
	for <lemonade@ietf.org>; Tue, 17 Jun 2003 19:09:09 -0500 (CDT)
Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19)
	id <L2XMPPS5>; Tue, 17 Jun 2003 19:09:08 -0500
Message-ID: <54E40201497DF142B06B27255953F79705DADA36@il0015exch007u.ih.lucent.com>
From: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
To: Mark Crispin <MRC@CAC.Washington.EDU>,
        Pete Resnick
	 <presnick@qualcomm.com>
Cc: lemonade@ietf.org
Subject: RE: [lemonade] Re: Point-of-order re IMAPEXT (Was: draft-royer-le
	monade-submit-00.txt)
Date: Tue, 17 Jun 2003 19:08:59 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>


Lemonade is addressing the needs of "diverse endpoints", one of which, and the most challenging of which, it mobile clients.  There is also a strong constituency for addressing the needs of the telephone user interface, one that has different demands in terms of low, predictable latency, real-time streaming, and support for message context in sorting and counting messages.

This is not a mobile-only working group.  Forward without download is just as important for a telephone user interface.

Greg V.

-----Original Message-----
From: Mark Crispin [mailto:MRC@CAC.Washington.EDU]
Sent: Tuesday, June 17, 2003 5:53 PM
To: Pete Resnick
Cc: lemonade@ietf.org
Subject: [lemonade] Re: Point-of-order re IMAPEXT (Was:
draft-royer-lemonade-submit-00.txt)


Well, Pete, I agree with you that "nothing belongs in IMAPEXT that isn't
already on the charter of IMAPEXT", and confess a backdoor motivation;
shove "submit as a general extension for all clients, not just mobile
clients" from LEMONADE (where extensions for non-mobile clients are
outside of charter) to IMAPEXT, which promptly tosses it as outside of its
charter.

> That a proposed solution is
> an IMAP extension is not a basis for saying it does not belong in
> LEMONADE.

No, but...:

The charter states that "Lemonade is tasked to provide a set of
enhancements and profiles of Internet email submission, transport, and
retrieval protocols to facilitate operation on platforms with constrained
resources, or communications links with high latency or limited
bandwidth."

The submit document explicitly states that it is to be used on others
platforms.  What's more, the submit document does not address work item
(2) at all.

Since the submit document covers platforms other than what is in the
charter, and because it does not address any of the work items of the
charter, I claim that it does not belong in LEMONADE.

A possible fix to this document would be to remove all references to
non-mobile clients and to add the functionality for work item (2).

-- 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

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



From exim@www1.ietf.org  Tue Jun 17 20:53:31 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17485
	for <lemonade-archive@odin.ietf.org>; Tue, 17 Jun 2003 20:53:31 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5I0r2U32440
	for lemonade-archive@odin.ietf.org; Tue, 17 Jun 2003 20:53:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SRCA-0008R9-R7
	for lemonade-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 20:53:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17480
	for <lemonade-web-archive@ietf.org>; Tue, 17 Jun 2003 20:53:00 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SR9v-0006Fi-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 20:50:43 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SR9v-0006Ff-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 20:50:43 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SRC9-0008Qj-5u; Tue, 17 Jun 2003 20:53:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SRBR-0008Q3-HA
	for lemonade@optimus.ietf.org; Tue, 17 Jun 2003 20:52:17 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17477
	for <lemonade@ietf.org>; Tue, 17 Jun 2003 20:52:15 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SR9C-0006FV-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 20:49:58 -0400
Received: from inet-consulting.com ([4.23.9.166] helo=royer.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SR99-0006FQ-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 20:49:56 -0400
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h5I0pvbt005999
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <lemonade@ietf.org>; Tue, 17 Jun 2003 17:52:08 -0700
Message-ID: <3EEFB7A3.4050509@Royer.com>
Date: Tue, 17 Jun 2003 18:51:47 -0600
From: Doug Royer <Doug@Royer.com>
Reply-To: lemonade@ietf.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: lemonade@ietf.org
Subject: Re: [lemonade] Re: Point-of-order re IMAPEXT (Was: draft-royer-lemonade-submit-00.txt)
References: <200306171156.HAA08281@ietf.org> <Pine.WNT.4.60.0306171340380.1912@Tomobiki-Cho.CAC.Washington.EDU> <p06001522bb15389605f3@[216.43.25.67]> <Pine.WNT.4.60.0306171542121.1912@Tomobiki-Cho.CAC.Washington.EDU>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070409030502070300010903"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This is a cryptographically signed message in MIME format.

--------------ms070409030502070300010903
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Mark Crispin wrote:

> 
> The submit document explicitly states that it is to be used on others
> platforms.

Where is that 'explicitly' stated? Or do you mean that it should be
disqualified or declared sneaky because it would work with existing
IMAP clients?

 >  What's more, the submit document does not address work item
 > (2) at all.

How about we specify a new message/external-body 'access-type'
of 'include' that must also specify a URL. Example below
using a "Relative IMAP URL" defined in 2192 (sorry
I do not recall the exact syntax of the URL).


Example:

      Content-type: message/external-body;
                    access-type=include;
		   url=imap:mailboxname;uid=123




-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  Doug@Royer.com                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

--------------ms070409030502070300010903
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC
A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j
cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB
MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T
BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN
VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre
qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+
5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA
MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg
TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD
QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx
ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz
IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq
hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34
1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA
gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK
YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd
SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC
AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF
BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl
cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl
IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs
MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq
1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2
TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail
MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE
AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO
b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG
MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD
VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV
BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv
43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y
lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP
D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn
0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK
bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg
hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT
IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI
AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t
L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk
OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW
yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1
MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl
ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTgwMDUxNDdaMCMGCSqGSIb3DQEJBDEWBBQm
a5XNUlicuOE7qdsFLPbXQYAIvTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL
KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAt0eqUwjk4Bwd
dLoCFd5Kl2yvNowEw9uJ5bc813SbTceVGWM/PJwoqRxDjMqf7DW3G354MU0t/DusZYEKOx+Y
6Aq8gfei+bPsXnmcBmEHmV85EYMgBH88K8yvlO7uJ9RVBT/km1jgM4RJKHizINbgeWFrv6Bw
vxQ+heYNaECOw65G8gtJwWpjiWuhr5VFeVwGmf3W2LuQVtGPk+lqEMDYGOjPFiC9qN7WGmPP
CedyzjTHfkfuriRWxBeplXjX9Li1P3ZiEp9mgqCeOsQdEUDqF+wqe6GLwTYhN78tF8iuD+mY
CgdVhPxVLYCI1TzFc5cSzCGJeSY4DJes2NxdolIPEAAAAAAAAA==
--------------ms070409030502070300010903--


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



From exim@www1.ietf.org  Tue Jun 17 21:45:30 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18488
	for <lemonade-archive@odin.ietf.org>; Tue, 17 Jun 2003 21:45:30 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5I1j2c04982
	for lemonade-archive@odin.ietf.org; Tue, 17 Jun 2003 21:45:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SS0U-0001IH-F4
	for lemonade-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 21:45:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18386
	for <lemonade-web-archive@ietf.org>; Tue, 17 Jun 2003 21:44:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SRyE-0006UN-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 21:42:42 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SRyE-0006UK-00
	for lemonade-web-archive@ietf.org; Tue, 17 Jun 2003 21:42:42 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SS0T-0001Hr-12; Tue, 17 Jun 2003 21:45:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SRzp-0001Gs-QH
	for lemonade@optimus.ietf.org; Tue, 17 Jun 2003 21:44:21 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18321
	for <lemonade@ietf.org>; Tue, 17 Jun 2003 21:44:19 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SRxa-0006Sy-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 21:42:02 -0400
Received: from orthanc.ab.ca ([216.123.230.114])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SRxZ-0006Sk-00
	for lemonade@ietf.org; Tue, 17 Jun 2003 21:42:01 -0400
Received: from orthanc.ab.ca ([192.168.42.253])
	by orthanc.ab.ca (8.12.6p2/8.12.6) with ESMTP id h5I1iAUW039477;
	Tue, 17 Jun 2003 19:44:10 -0600 (MDT)
	(envelope-from lyndon@orthanc.ab.ca)
Date: Tue, 17 Jun 2003 19:44:08 -0600
Subject: Re: [lemonade] Re: Point-of-order re IMAPEXT (Was: draft-royer-le monade-submit-00.txt)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: lemonade@ietf.org
To: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
From: Lyndon Nerenberg <lyndon@orthanc.ab.ca>
In-Reply-To: <54E40201497DF142B06B27255953F79705DADA36@il0015exch007u.ih.lucent.com>
Message-Id: <5A1C3760-A12E-11D7-B9DC-000393D34A62@orthanc.ab.ca>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
Content-Transfer-Encoding: 7bit
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

> Lemonade is addressing the needs of "diverse endpoints", one of which, 
> and the most challenging of which, it mobile clients.  There is also a 
> strong constituency for addressing the needs of the telephone user 
> interface

So before we get totally mired in details, it would be a good idea to 
enumerate the characteristics of these various endpoint devices. 
Otherwise, we don't know what problems we're trying to solve.

--lyndon


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



From exim@www1.ietf.org  Wed Jun 18 16:42:45 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28946
	for <lemonade-archive@odin.ietf.org>; Wed, 18 Jun 2003 16:42:44 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5IKgHi19677
	for lemonade-archive@odin.ietf.org; Wed, 18 Jun 2003 16:42:17 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Sjat-0004V1-5f
	for lemonade-web-archive@optimus.ietf.org; Wed, 18 Jun 2003 16:31:47 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28197
	for <lemonade-web-archive@ietf.org>; Wed, 18 Jun 2003 16:31:44 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SjYc-0001l2-00
	for lemonade-web-archive@ietf.org; Wed, 18 Jun 2003 16:29:26 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SjYc-0001ky-00
	for lemonade-web-archive@ietf.org; Wed, 18 Jun 2003 16:29:26 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SjTO-0004GK-6O; Wed, 18 Jun 2003 16:24:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SjJH-0003ji-Gr
	for lemonade@optimus.ietf.org; Wed, 18 Jun 2003 16:13:35 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27145
	for <lemonade@ietf.org>; Wed, 18 Jun 2003 16:13:33 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SjH0-0001Sz-00
	for lemonade@ietf.org; Wed, 18 Jun 2003 16:11:14 -0400
Received: from inet-consulting.com ([4.23.9.166] helo=royer.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SjGz-0001ST-00
	for lemonade@ietf.org; Wed, 18 Jun 2003 16:11:13 -0400
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h5IKDFOR004872
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <lemonade@ietf.org>; Wed, 18 Jun 2003 13:13:25 -0700
Message-ID: <3EF0C7CE.7020302@Royer.com>
Date: Wed, 18 Jun 2003 14:13:02 -0600
From: Doug Royer <Doug@Royer.com>
Reply-To: lemonade@ietf.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: lemonade@ietf.org
Subject: Re: [lemonade] Re: Point-of-order re IMAPEXT (Was: draft-royer-lemonade-submit-00.txt)
References: <200306171156.HAA08281@ietf.org> <Pine.WNT.4.60.0306171340380.1912@Tomobiki-Cho.CAC.Washington.EDU> <p06001522bb15389605f3@[216.43.25.67]> <Pine.WNT.4.60.0306171542121.1912@Tomobiki-Cho.CAC.Washington.EDU>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060208050706050606010300"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This is a cryptographically signed message in MIME format.

--------------ms060208050706050606010300
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Mark Crispin wrote:
> Well, Pete, I agree with you that "nothing belongs in IMAPEXT that isn't
> already on the charter of IMAPEXT", and confess a backdoor motivation;
> shove "submit as a general extension for all clients, not just mobile
> clients" from LEMONADE (where extensions for non-mobile clients are
> outside of charter) to IMAPEXT, which promptly tosses it as outside of its
> charter.

Having re-read the charter, I see nothing in it that says that if
it is compatible with existing clients that it must be tossed.
And I see it as a plus that it is compatable.

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  Doug@Royer.com                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

--------------ms060208050706050606010300
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC
A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j
cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB
MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T
BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN
VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre
qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+
5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA
MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg
TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD
QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx
ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz
IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq
hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34
1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA
gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK
YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd
SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC
AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF
BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl
cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl
IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs
MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq
1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2
TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail
MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE
AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO
b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG
MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD
VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV
BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv
43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y
lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP
D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn
0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK
bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg
hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT
IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI
AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t
L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk
OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW
yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1
MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl
ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTgyMDEzMDNaMCMGCSqGSIb3DQEJBDEWBBR2
d0VOyFR34tBEKBan3Lx+1C4IazBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL
KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAnzo1c5ur/NLR
20KI+4lVGrEnHkOrUK8wP9II83eTyusxOE/sf+Ev+ypjcFCnMDDztdeOR1nJhAhRmINkEPQ9
fC8iQKRzOs4PYaCscdDz5IC4RbY0wRWfaNElHWyuBEj0owJRzwr3r3F5D4XH7WcODcXfGOGI
91FzCadpdyfoFZibM/TZkGMrjHwwO8804BRCQuaihvjIH4TJVGI41l/Ta0gFeuFGkmMgUK90
0+qAUqi0m0DLnUoFgfqLkqGXKx+Rbfr81gwYz86lvfPmvc0mS8VI7mAKqMYtvS6QaqvKYArr
JdDfI77eBdZNjCpL/WvxXUggIlnU7E5fUglLQWkuEQAAAAAAAA==
--------------ms060208050706050606010300--


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



From exim@www1.ietf.org  Wed Jun 18 17:02:57 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29847
	for <lemonade-archive@odin.ietf.org>; Wed, 18 Jun 2003 17:02:56 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5IL2TP23384
	for lemonade-archive@odin.ietf.org; Wed, 18 Jun 2003 17:02:29 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SjuR-0005Xz-5H
	for lemonade-web-archive@optimus.ietf.org; Wed, 18 Jun 2003 16:51:59 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29284
	for <lemonade-web-archive@ietf.org>; Wed, 18 Jun 2003 16:51:56 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SjsA-00022z-00
	for lemonade-web-archive@ietf.org; Wed, 18 Jun 2003 16:49:38 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Sjs9-00022w-00
	for lemonade-web-archive@ietf.org; Wed, 18 Jun 2003 16:49:37 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Sjll-00058C-At; Wed, 18 Jun 2003 16:43:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SjZW-0004Sy-F5
	for lemonade@optimus.ietf.org; Wed, 18 Jun 2003 16:30:22 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28124
	for <lemonade@ietf.org>; Wed, 18 Jun 2003 16:30:20 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SjXF-0001js-00
	for lemonade@ietf.org; Wed, 18 Jun 2003 16:28:01 -0400
Received: from inet-consulting.com ([4.23.9.166] helo=royer.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SjXE-0001jo-00
	for lemonade@ietf.org; Wed, 18 Jun 2003 16:28:00 -0400
Received: from Royer.com (inet-products.com [12.110.12.238])
	(authenticated bits=0)
	by royer.com (8.12.2/8.12.2) with ESMTP id h5IKUAOR005034
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <lemonade@ietf.org>; Wed, 18 Jun 2003 13:30:18 -0700
Message-ID: <3EF0CBC4.70408@Royer.com>
Date: Wed, 18 Jun 2003 14:29:56 -0600
From: Doug Royer <Doug@Royer.com>
Reply-To: lemonade@ietf.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: lemonade@ietf.org
Subject: Re: [lemonade] Re: Point-of-order re IMAPEXT (Was: draft-royer-le
 monade-submit-00.txt)
References: <5A1C3760-A12E-11D7-B9DC-000393D34A62@orthanc.ab.ca>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050200010908090302090008"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This is a cryptographically signed message in MIME format.

--------------ms050200010908090302090008
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Lyndon Nerenberg wrote:
>> Lemonade is addressing the needs of "diverse endpoints", one of which, 
>> and the most challenging of which, it mobile clients.  There is also a 
>> strong constituency for addressing the needs of the telephone user 
>> interface
> 
> 
> So before we get totally mired in details, it would be a good idea to 
> enumerate the characteristics of these various endpoint devices. 
> Otherwise, we don't know what problems we're trying to solve.

As I understand it, one problem is limited bandwidh and limited
memory or storage on the client. And I think that the key item is
forwarding of message or body parts without download.

The charter clearly says IMAP (among other things) So that looks
to me to mean extending existing protocols.

There are other goals and it does not look to me as if the charter
says that everything must be in one unified spec.

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  Doug@Royer.com                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

--------------ms050200010908090302090008
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC
A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j
cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB
MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T
BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN
VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre
qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+
5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA
MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg
TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD
QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx
ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG
A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz
IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq
hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34
1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA
gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK
YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd
SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC
AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF
BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl
cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl
IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs
MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq
1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2
TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail
MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE
AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO
b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG
MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD
VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV
BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv
43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y
lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP
D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn
0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK
bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg
hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ
UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT
IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI
AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t
L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk
OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW
yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1
MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl
ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTgyMDI5NTZaMCMGCSqGSIb3DQEJBDEWBBSL
k66FEh54sFpFH9A7S8VY/bezNTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL
KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAHO4Icz0o5DmT
O/ftyA0m7wUimZy+EEtqL/iiJvk1ZoVpXV2SCZcJRw9iNDb7haxXvDG38xkMqCOME4yxA/11
MfUSWTXABHNnLfO453p0DFiXba0x3pIIStGdzfJ0Zoas/rLh26T24ihuQbLTyucE44Iudgao
d5afOL9tDDWkRvKZijSyibkxaQV3aWQPGkBu1yTDW8GVSXAHQDEiGId0j5OrpDxPS0pbwCUG
OHtxR3+jZi89fGjE7e0RV6qkDMWlWpAc3EaoJzCwZwELsblhJul7D8l808/IPWxXUOneNZeJ
/BfRbCrc2yezuEpTueJWwy7Md3Y16lxdaK6VGswJbAAAAAAAAA==
--------------ms050200010908090302090008--


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



From exim@www1.ietf.org  Thu Jun 19 01:41:15 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17191
	for <lemonade-archive@odin.ietf.org>; Thu, 19 Jun 2003 01:41:15 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5J5elX32551
	for lemonade-archive@odin.ietf.org; Thu, 19 Jun 2003 01:40:47 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SrsX-0007jp-Ok
	for lemonade-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 01:22:33 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16358
	for <lemonade-web-archive@ietf.org>; Thu, 19 Jun 2003 01:22:32 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SrqG-0006Ug-00
	for lemonade-web-archive@ietf.org; Thu, 19 Jun 2003 01:20:12 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SrqD-0006UM-00
	for lemonade-web-archive@ietf.org; Thu, 19 Jun 2003 01:20:09 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SrdU-00076v-Q0; Thu, 19 Jun 2003 01:07:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SrOa-0006cS-Hj
	for lemonade@optimus.ietf.org; Thu, 19 Jun 2003 00:51:36 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15695
	for <lemonade@ietf.org>; Thu, 19 Jun 2003 00:51:33 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SrMJ-0006JD-00
	for lemonade@ietf.org; Thu, 19 Jun 2003 00:49:15 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SrMI-0006JA-00
	for lemonade@ietf.org; Thu, 19 Jun 2003 00:49:14 -0400
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150])
	by ithilien.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h5J4pWZf011255
	for <lemonade@ietf.org>; Wed, 18 Jun 2003 21:51:32 -0700 (PDT)
Received: from [192.168.1.13] (vpn-10-50-16-2.qualcomm.com [10.50.16.2])
	by sabrina.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h5J4pTBC007502
	for <lemonade@ietf.org>; Wed, 18 Jun 2003 21:51:30 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <a06001702bb16f13dc35a@[192.168.1.13]>
X-Mailer: Eudora for Mac OS X v6.0a
Date: Wed, 18 Jun 2003 21:50:58 -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.0b25
Subject: [lemonade] Submit Draft
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

I've sent in the submit draft.  You can see it before it gets 
processed by the I-D editor at 
<ftp://ftp.pensive.org/Public/Randy/lemonade-submit-00.txt>.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Mark's Dental-Chair Discovery:
    Dentists are incapable of asking questions that require a
    simple yes or no answer.

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



From exim@www1.ietf.org  Thu Jun 19 23:25:34 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01710
	for <lemonade-archive@odin.ietf.org>; Thu, 19 Jun 2003 23:25:34 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5K3P6Z30557
	for lemonade-archive@odin.ietf.org; Thu, 19 Jun 2003 23:25:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19TCWQ-0007wm-ER
	for lemonade-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 23:25:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01701
	for <lemonade-web-archive@ietf.org>; Thu, 19 Jun 2003 23:25:03 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19TCU7-0006ER-00
	for lemonade-web-archive@ietf.org; Thu, 19 Jun 2003 23:22:43 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19TCU7-0006EN-00
	for lemonade-web-archive@ietf.org; Thu, 19 Jun 2003 23:22:43 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19TCWL-0007wP-Bs; Thu, 19 Jun 2003 23:25:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19TCWJ-0007w7-8Z
	for lemonade@optimus.ietf.org; Thu, 19 Jun 2003 23:24:59 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01696
	for <lemonade@ietf.org>; Thu, 19 Jun 2003 23:24:56 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19TCU0-0006EK-00
	for lemonade@ietf.org; Thu, 19 Jun 2003 23:22:36 -0400
Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19TCTz-0006EG-00
	for lemonade@ietf.org; Thu, 19 Jun 2003 23:22:35 -0400
Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83])
	by auemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h5K3OOg07403
	for <lemonade@ietf.org>; Thu, 19 Jun 2003 22:24:24 -0500 (CDT)
Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19)
	id <L2XMVJPS>; Thu, 19 Jun 2003 22:24:23 -0500
Message-ID: <54E40201497DF142B06B27255953F79705E809AA@il0015exch007u.ih.lucent.com>
From: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
To: lemonade@ietf.org
Cc: Randall Gellens <randy@qualcomm.com>
Date: Thu, 19 Jun 2003 22:24:23 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [lemonade] Content conversion upon submission
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>


Let me throw one more use-case into this submission gunk.   

Say a client wishes to send a message with content generated on the end of a skinny, latent path, say a recorded audio clip.  Say that message is intended to be delivered via VPIM's 32kADPCM or some more common audio/basic construct.

The client here has the obvious choice to send the data in the bulky form over this link, or it could send it using a more compressed, maybe native format such as GSM, AMR, or EVRC.  What would be desireable is to send the audio data upstream via an external content-conversion device, with an indication that the data should be converted prior to submission into a more accessable form say mu-law (audio/basic). 

This is leading me to believe that the "template" as Randy is describing needs to be able to include references to external stuff, and deal with the security issues that are also present in the channel extension.... the alternative of requesting conversion as part of the submission process itself seems to be messy

Thoughts?

Greg V.

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



From exim@www1.ietf.org  Fri Jun 20 08:12:34 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01552
	for <lemonade-archive@odin.ietf.org>; Fri, 20 Jun 2003 08:12:34 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5KCC6t32679
	for lemonade-archive@odin.ietf.org; Fri, 20 Jun 2003 08:12:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19TKkQ-0008V0-21
	for lemonade-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 08:12:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01526
	for <lemonade-web-archive@ietf.org>; Fri, 20 Jun 2003 08:12:04 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19TKi4-0002vV-00
	for lemonade-web-archive@ietf.org; Fri, 20 Jun 2003 08:09:40 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19TKi3-0002vS-00
	for lemonade-web-archive@ietf.org; Fri, 20 Jun 2003 08:09:39 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19TKkL-0008Ua-Mm; Fri, 20 Jun 2003 08:12:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19TKk2-0008TQ-7Q
	for lemonade@optimus.ietf.org; Fri, 20 Jun 2003 08:11:42 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01460
	for <lemonade@ietf.org>; Fri, 20 Jun 2003 08:11:40 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19TKhg-0002uz-00
	for lemonade@ietf.org; Fri, 20 Jun 2003 08:09:16 -0400
Received: from panda.com
	([206.124.149.114] helo=Ikkoku-Kan.Panda.COM ident=bwi)
	by ietf-mx with esmtp (Exim 4.12)
	id 19TKhe-0002un-00
	for lemonade@ietf.org; Fri, 20 Jun 2003 08:09:15 -0400
Received: from localhost (mrc@localhost) by Ikkoku-Kan.Panda.COM id FAA07252; Fri, 20 Jun 2003 05:11:31 -0700 (PDT)
X-Received: via tmail-2000(13) (invoked by user mailnull) for mrc+ietf; Fri, 20 Jun 2003 04:58:54 -0700 (PDT)
X-Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1])
	by ndcms.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h5KBws2S001880;
	Fri, 20 Jun 2003 04:58:54 -0700
X-Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40])
	by mx2.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h5KBrn7m007998;
	Fri, 20 Jun 2003 04:53:55 -0700
X-Received: from majordomo by asgard.ietf.org with local (Exim 4.14)
	id 19TKBO-0006RE-8Q
	for ietf-announce-list@asgard.ietf.org; Fri, 20 Jun 2003 07:35:54 -0400
X-Received: from ietf.org ([10.27.2.28])
	by asgard.ietf.org with esmtp (Exim 4.14)
	id 19TK9M-0006A1-5R
	for all-ietf@asgard.ietf.org; Fri, 20 Jun 2003 07:33:48 -0400
X-Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25935
	for <all-ietf@ietf.org>; Fri, 20 Jun 2003 07:33:47 -0400 (EDT)
Message-Id: <200306201133.HAA25935@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Fri, 20 Jun 2003 07:33:46 -0400
Precedence: bulk
X-Uwash-Spam: Gauge=XXXXIIIIII, Probability=46%, Report="NO_REAL_NAME, SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02, TO_MALFORMED"
ReSent-Date: Fri, 20 Jun 2003 05:11:23 -0700 (PDT)
ReSent-From: Mark Crispin <mrc@CAC.Washington.EDU>
ReSent-To: lemonade@ietf.org
ReSent-Subject: I-D ACTION:draft-crispin-imap-urlauth-00.txt
ReSent-Message-ID: <Pine.NXT.4.56.0306200511230.477@Ikkoku-Kan.Panda.COM>
Subject: [lemonade] I-D ACTION:draft-crispin-imap-urlauth-00.txt
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Internet Message Access Protocol (IMAP) - URLAUTH 
                          Extension
	Author(s)	: M. Crispin, C. Newman
	Filename	: draft-crispin-imap-urlauth-00.txt
	Pages		: 0
	Date		: 2003-6-19
	
This document describes the URLAUTH extension to the Internet
Message Access Protocol (IMAP) (RFC 3501) and the IMAP URL Scheme
(IMAPURL) (RFC 2192).  This extension provides a means by which an
IMAP client can create 'signed' URLs which can be used to access
limited message data on the IMAP server.
An IMAP server which supports this extension indicates this with a
capability name of 'URLAUTH'.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-crispin-imap-urlauth-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-crispin-imap-urlauth-00.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-crispin-imap-urlauth-00.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:	<2003-6-19154044.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-crispin-imap-urlauth-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-crispin-imap-urlauth-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-6-19154044.I-D@ietf.org>

--OtherAccess--

--NextPart--




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



From exim@www1.ietf.org  Fri Jun 20 08:35:31 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03366
	for <lemonade-archive@odin.ietf.org>; Fri, 20 Jun 2003 08:35:31 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5KCZ2b04403
	for lemonade-archive@odin.ietf.org; Fri, 20 Jun 2003 08:35:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19TL6c-00018w-Gy
	for lemonade-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 08:35:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03357
	for <lemonade-web-archive@ietf.org>; Fri, 20 Jun 2003 08:35:00 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19TL4H-0003RZ-00
	for lemonade-web-archive@ietf.org; Fri, 20 Jun 2003 08:32:37 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19TL4G-0003RW-00
	for lemonade-web-archive@ietf.org; Fri, 20 Jun 2003 08:32:36 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19TL6b-00018U-76; Fri, 20 Jun 2003 08:35:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19TL64-0000wg-OX
	for lemonade@optimus.ietf.org; Fri, 20 Jun 2003 08:34:28 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03323
	for <lemonade@ietf.org>; Fri, 20 Jun 2003 08:34:26 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19TL3j-0003R7-00
	for lemonade@ietf.org; Fri, 20 Jun 2003 08:32:03 -0400
Received: from panda.com
	([206.124.149.114] helo=Ikkoku-Kan.Panda.COM ident=den)
	by ietf-mx with esmtp (Exim 4.12)
	id 19TL3i-0003R2-00
	for lemonade@ietf.org; Fri, 20 Jun 2003 08:32:02 -0400
Received: from localhost (mrc@localhost) by Ikkoku-Kan.Panda.COM id FAA07288; Fri, 20 Jun 2003 05:34:22 -0700 (PDT)
Date: Fri, 20 Jun 2003 05:34:22 -0700 (PDT)
From: Mark Crispin <mrc@CAC.Washington.EDU>
To: lemonade@ietf.org
Subject: Re: [lemonade] I-D ACTION:draft-crispin-imap-urlauth-00.txt
In-Reply-To: <200306201133.HAA25935@ietf.org>
Message-ID: <Pine.NXT.4.56.0306200520380.477@Ikkoku-Kan.Panda.COM>
References: <200306201133.HAA25935@ietf.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

Although this document nees a bit more fleshing out (particularly in
security considerations and quality-of-implementation issues), URLAUTH
demonstrates how relatively simple it is to deploy an IMAP URL-based
mechanism for submit-without-download.

Most IMAP server and client implementations already have HMAC-MD5 and
BASE64 routines, as these are needed for SASL.

Since the mailbox private key is returned automatically at SELECT time,
there are no extra RTTs required of the mobile client; it's just another
bit of mailbox metadata.

Another beauty of URLAUTH is that it turns out that there is pent-up need
for a mechanism of this nature for other purposes.

-- 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 exim@www1.ietf.org  Fri Jun 20 10:54:28 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09992
	for <lemonade-archive@odin.ietf.org>; Fri, 20 Jun 2003 10:54:28 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5KEs2q10335
	for lemonade-archive@odin.ietf.org; Fri, 20 Jun 2003 10:54:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19TNH8-0002gc-0B
	for lemonade-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 10:54:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09976
	for <lemonade-web-archive@ietf.org>; Fri, 20 Jun 2003 10:53:58 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19TNH5-0004mv-00
	for lemonade-web-archive@ietf.org; Fri, 20 Jun 2003 10:53:59 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19TNH5-0004mq-00
	for lemonade-web-archive@ietf.org; Fri, 20 Jun 2003 10:53:59 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19TNH6-0002g6-Jr; Fri, 20 Jun 2003 10:54:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19TNGW-0002fh-6M
	for lemonade@optimus.ietf.org; Fri, 20 Jun 2003 10:53:24 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09953;
	Fri, 20 Jun 2003 10:53:20 -0400 (EDT)
Message-Id: <200306201453.KAA09953@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: lemonade@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Fri, 20 Jun 2003 10:53:19 -0400
Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-submit-00.txt
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

--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		: IMAP Submit Without Download
	Author(s)	: R. Gellens
	Filename	: draft-ietf-lemonade-submit-00.txt
	Pages		: 11
	Date		: 2003-6-19
	
IMAP clients operating over low-bandwidth or high-latency links,
such as cellular telephones, need to be able to submit mail messages
containing all or part of previously-received IMAP messages.
Clients need to be able to do this without sloshing the bits both
ways, that is, without being forced to download IMAP messages solely
to be able to upload the content in a submitted message.
This document currently identifies the two main approaches to doing
this (called 'IMAP push' and 'IMAP pull'), one which adds submission
to IMAP, and another which adds the expansion of IMAP references to
message submission.  This version of the document attempts to lay
out the protocol mechanisms along with associated trade-offs and
security considerations of each.  Once a decision has been made to
go with a particular technique, this document will describe the
specifics of that choice as a standards-track proposal.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-submit-00.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-submit-00.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:	<2003-6-19153942.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-lemonade-submit-00.txt

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

Content-Type: text/plain
Content-ID:	<2003-6-19153942.I-D@ietf.org>

--OtherAccess--

--NextPart--



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



From exim@www1.ietf.org  Fri Jun 20 14:02:32 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21014
	for <lemonade-archive@odin.ietf.org>; Fri, 20 Jun 2003 14:02:32 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5KI24M31683
	for lemonade-archive@odin.ietf.org; Fri, 20 Jun 2003 14:02:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19TQD6-0008Ew-7D
	for lemonade-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 14:02:04 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20968
	for <lemonade-web-archive@ietf.org>; Fri, 20 Jun 2003 14:02:01 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19TQD3-0007S6-00
	for lemonade-web-archive@ietf.org; Fri, 20 Jun 2003 14:02:01 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19TQD2-0007Rx-00
	for lemonade-web-archive@ietf.org; Fri, 20 Jun 2003 14:02:00 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19TQD3-00088u-D9; Fri, 20 Jun 2003 14:02:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19TQCj-000880-Ne
	for lemonade@optimus.ietf.org; Fri, 20 Jun 2003 14:01:42 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20952
	for <lemonade@ietf.org>; Fri, 20 Jun 2003 14:01:39 -0400 (EDT)
From: hardie@qualcomm.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19TQCh-0007Rb-00
	for lemonade@ietf.org; Fri, 20 Jun 2003 14:01:39 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx with esmtp (Exim 4.12)
	id 19TQCg-0007RV-00
	for lemonade@ietf.org; Fri, 20 Jun 2003 14:01:38 -0400
Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149])
	by numenor.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h5KI1IBd016115
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Fri, 20 Jun 2003 11:01:19 -0700 (PDT)
Received: from [205.214.163.81] (carbuncle.qualcomm.com [129.46.227.161])
	by neophyte.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h5KI1Guh004885;
	Fri, 20 Jun 2003 11:01:17 -0700 (PDT)
Mime-Version: 1.0
X-Sender: hardie@mage.qualcomm.com
Message-Id: <p06001210bb18f3f05c4c@[205.214.163.81]>
In-Reply-To: <Pine.NXT.4.56.0306200520380.477@Ikkoku-Kan.Panda.COM>
References: <200306201133.HAA25935@ietf.org>
 <Pine.NXT.4.56.0306200520380.477@Ikkoku-Kan.Panda.COM>
Date: Fri, 20 Jun 2003 11:01:20 -0700
To: Mark Crispin <mrc@CAC.Washington.EDU>, lemonade@ietf.org
Subject: Re: [lemonade] I-D ACTION:draft-crispin-imap-urlauth-00.txt
Cc: Chris.Newman@sun.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

Mark, Chris,
	I've read the draft.  The idea of embedding security
credentials in URIs has been discussed extensively, dating
back to the HTTP working group.  The fundamental problem
goes to how authentication and authorization are intertwined.
In the typical security model, there is first authorization ("You are who
you say you are") then authorization ("you have the rights to
do $FOO").  When you embed authorization credentials in an
identifier, you shift to a security model in which there is no
prior authentication for an authorization.  To put this another
way, anyone who knows the identifier has authorized access
to the resource.
	There are a couple of common responses to this:
creating a separate mechanism for prior authentication and limiting
access to the resource in some other way such that the risk
is appropriate to value of the resource being protected.  It is
also common to attempt to mitigate the risk by protecting the
channels by which the identifier is transmitted so that the
value of "anyone who knows the identifier" remains appropriate
to the situation at hand.
	The most common forms of prior authentication I
have seen are tied to some form of server-based ACL ("only servers presenting
the following credentials are allowed to present these URIs"); the
most common forms of limitations I have seen limit access to
the resource to a single attempt.  The one-shot access limitations have a
number of failure conditions that have no direct relationship to
security, as well as a bad tendency to layer denial of service
on top of an access compromise.
	To take the case of the server-based prior authentication
in more detail, one of the principle risks is that authorized use of 
the external
server can be used to create authenticated use of the target server.  Assuming
that this were to be used in an "IMAP pull" scenario and a submit server,
the "pulling" submit server is almost certain to be accessible to multiple
individuals.  Any such individual who has intercepted the credential-bearing
URI  can piggyback their authorized use of the submit server to create
the authentication needed to allow access to the URI.  To put this another
way, the difference in granularity of authentication creates a security risk.
	Fundamentally, I think your draft needs to be re-written
from a very different security perspective.  I think you either need
to demonstrate that access to these resources is appropriately
made based solely on essentially anonymous authorization or that
you have worked out the mechanisms of the larger security context
so that the granularity of authentication and authorization are
appropriately matched.  I also strongly believe that Mark's comment
below (that there is a pent-up need for this mechanism for other
purposes) needs to be understood within the limitations of this method.
The uses to which anonymous authorization can be put are quite
limited, and it is not clear to me that this use fits the model, much
less that there is a pent up demand for it outside this use.
				regards,
					Ted Hardie

At 5:34 AM -0700 6/20/03, Mark Crispin wrote:
>Although this document nees a bit more fleshing out (particularly in
>security considerations and quality-of-implementation issues), URLAUTH
>demonstrates how relatively simple it is to deploy an IMAP URL-based
>mechanism for submit-without-download.
>
>Most IMAP server and client implementations already have HMAC-MD5 and
>BASE64 routines, as these are needed for SASL.
>
>Since the mailbox private key is returned automatically at SELECT time,
>there are no extra RTTs required of the mobile client; it's just another
>bit of mailbox metadata.
>
>Another beauty of URLAUTH is that it turns out that there is pent-up need
>for a mechanism of this nature for other purposes.
>
>-- 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


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



From exim@www1.ietf.org  Fri Jun 20 18:37:29 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13248
	for <lemonade-archive@odin.ietf.org>; Fri, 20 Jun 2003 18:37:28 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5KMb2P30095
	for lemonade-archive@odin.ietf.org; Fri, 20 Jun 2003 18:37:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19TUVC-0007pK-Lw
	for lemonade-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 18:37:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13228
	for <lemonade-web-archive@ietf.org>; Fri, 20 Jun 2003 18:36:58 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19TUV9-00041m-00
	for lemonade-web-archive@ietf.org; Fri, 20 Jun 2003 18:36:59 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19TUV9-00041j-00
	for lemonade-web-archive@ietf.org; Fri, 20 Jun 2003 18:36:59 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19TUVA-0007oF-ML; Fri, 20 Jun 2003 18:37:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19TUUJ-0007mi-UO
	for lemonade@optimus.ietf.org; Fri, 20 Jun 2003 18:36:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13211
	for <lemonade@ietf.org>; Fri, 20 Jun 2003 18:36:03 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19TUUH-00041T-00
	for lemonade@ietf.org; Fri, 20 Jun 2003 18:36:05 -0400
Received: from mxout5.cac.washington.edu ([140.142.32.135])
	by ietf-mx with esmtp (Exim 4.12)
	id 19TUUG-00041Q-00
	for lemonade@ietf.org; Fri, 20 Jun 2003 18:36:04 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9])
	by mxout5.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h5KMZwkI002407;
	Fri, 20 Jun 2003 15:36:03 -0700
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
	(authenticated bits=0)
	by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h5KMZvXa027431
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Fri, 20 Jun 2003 15:35:57 -0700
Date: Fri, 20 Jun 2003 15:35:56 -0700 (Pacific Daylight Time)
From: Mark Crispin <MRC@CAC.Washington.EDU>
To: hardie@qualcomm.com
cc: lemonade@ietf.org, Chris.Newman@sun.com
Subject: Re: [lemonade] I-D ACTION:draft-crispin-imap-urlauth-00.txt
In-Reply-To: <p06001210bb18f3f05c4c@[205.214.163.81]>
Message-ID: <Pine.WNT.4.60.0306201440160.4048@Tomobiki-Cho.CAC.Washington.EDU>
References: <200306201133.HAA25935@ietf.org> <Pine.NXT.4.56.0306200520380.477@Ikkoku-Kan.Panda.COM>
 <p06001210bb18f3f05c4c@[205.214.163.81]>
Organization: Networks & Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

Ted -

Thank you very much for your well-considered and very helpful comments.
My response is below.

On Fri, 20 Jun 2003 hardie@qualcomm.com wrote:
> In the typical security model, there is first authorization ("You are who
                                                ^^^^^^^^^^^^^ authentication?
> you say you are") then authorization ("you have the rights to
> do $FOO").  When you embed authorization credentials in an
> identifier, you shift to a security model in which there is no
> prior authentication for an authorization.  To put this another
> way, anyone who knows the identifier has authorized access
> to the resource.

This analysis is correct; the mechanism that we propose has authorization
but not authentication.  The specific intent of the design was to provide
authorization to entities which can not (or should not) be authenticated.

To elaborate on the "should not" aspect; the goal was to create a
mechanism to grant access to entities that do not have authentication
credentials on the IMAP server *without* giving those entities the
authentication credentials of the owner of the data.

I thought about this, but decided for the 00 version of the draft not to
address authentication.  If you feel that authentication must be addressed
in this go-around, I think I know how to do that.

Can you give me some additional input; specifically, is it alright to
continue to have an authorization-only form, as long as a form with
authentication is defined?

The authorization-only form, in effect, would mean "anyone including
anonymous can use it".  A form with authentication would restrict access
to a certain IMAP-server authenticated user or users.

I briefly considered a signing form of authentication for the mail submit
case, but rejected this because of excessive complexity and no actual gain
in a submit environment.

> 	There are a couple of common responses to this:
> creating a separate mechanism for prior authentication and limiting
> access to the resource in some other way such that the risk
> is appropriate to value of the resource being protected.

This prior authentication, in the form with authentication, would be by
means of existing IMAP authentication mechanisms.

> It is
> also common to attempt to mitigate the risk by protecting the
> channels by which the identifier is transmitted so that the
> value of "anyone who knows the identifier" remains appropriate
> to the situation at hand.

In the case of submit, there is a presumption (which perhaps should be
stated in security considerations) that SSL/TLS-protected channels should
be used to transmit the identifier, along with short-term expiration.

> 	The most common forms of prior authentication I
> have seen are tied to some form of server-based ACL ("only servers presenting
> the following credentials are allowed to present these URIs"); the
> most common forms of limitations I have seen limit access to
> the resource to a single attempt.

I don't propose doing either of these.  Server-based ACL isn't completely
out of the question, but I think that it's better to give authentication
credentials on the IMAP server to users of the URLs (perhaps limited
solely to use of URLs).  One-shot access limitations seem to me to be a
gad idea.

> Assuming
> that this were to be used in an "IMAP pull" scenario and a submit server,
> the "pulling" submit server is almost certain to be accessible to multiple
> individuals.  Any such individual who has intercepted the credential-bearing
> URI  can piggyback their authorized use of the submit server to create
> the authentication needed to allow access to the URI.

Hence my presumption of the use of SSL/TLS.

Also, it's important to do an appropriate risk assessment.  If the
credential-bearing URI is intercepted, the other components of the message
are also intercepted.  More significantly, the ultimate fate of the
message, *including* the data accessed by the credential-bearing URI, is
likely to be the totally-unprotected SMTP infrastructure.

> I think you either need
> to demonstrate that access to these resources is appropriately
> made based solely on essentially anonymous authorization or that
> you have worked out the mechanisms of the larger security context
> so that the granularity of authentication and authorization are
> appropriately matched.

I would like to do both, if possible; and would very much appreciate your
assistance in accomplishing this.

We glossed over some important security issues, but were focused on
getting out a 00 draft in time for the IETF cutoff.  Hence the focus was
to create a mechanism that was defensible from a security standpoint even
if the details of that defense were not fully worked out.  I think that
this proposal succeeds in doing so; but you're correct in calling out the
glossings-over.

> I also strongly believe that Mark's comment
> below (that there is a pent-up need for this mechanism for other
> purposes) needs to be understood within the limitations of this method.

Well, there are a couple of needs that come immediately to mind, but both
boil down to a desire for a finer granularity of authorization, both for
anonymous and for non-anonymous access, and to do it in a way that is
revokable and which has an optional expiration.

IMAP itself only offers authorization at the level of authentication
(although authorization is commonly imposed via external means); the ACL
extension to IMAP brings it down to the mailbox level.

> The uses to which anonymous authorization can be put are quite
> limited, and it is not clear to me that this use fits the model, much
> less that there is a pent up demand for it outside this use.

Within an enterprise, one could imagine members sending each other URIs to
the data instead of the data itself.  Right now, the only way to do this
is by forward or resend, which has other implications.

-- 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 exim@www1.ietf.org  Fri Jun 20 19:44:30 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14605
	for <lemonade-archive@odin.ietf.org>; Fri, 20 Jun 2003 19:44:29 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5KNi2K09046
	for lemonade-archive@odin.ietf.org; Fri, 20 Jun 2003 19:44:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19TVY2-0002Lp-EI
	for lemonade-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 19:44:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14602
	for <lemonade-web-archive@ietf.org>; Fri, 20 Jun 2003 19:43:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19TVY0-0004OP-00
	for lemonade-web-archive@ietf.org; Fri, 20 Jun 2003 19:44:00 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19TVY0-0004OM-00
	for lemonade-web-archive@ietf.org; Fri, 20 Jun 2003 19:44:00 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19TVY0-0002Kb-Nq; Fri, 20 Jun 2003 19:44:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19TVXc-0002KG-11
	for lemonade@optimus.ietf.org; Fri, 20 Jun 2003 19:43:36 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14596
	for <lemonade@ietf.org>; Fri, 20 Jun 2003 19:43:32 -0400 (EDT)
From: hardie@qualcomm.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19TVXa-0004OD-00
	for lemonade@ietf.org; Fri, 20 Jun 2003 19:43:34 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx with esmtp (Exim 4.12)
	id 19TVXZ-0004OA-00
	for lemonade@ietf.org; Fri, 20 Jun 2003 19:43:33 -0400
Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148])
	by numenor.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h5KNhSBd003371
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Fri, 20 Jun 2003 16:43:28 -0700 (PDT)
Received: from [205.214.163.81] (carbuncle.qualcomm.com [129.46.227.161])
	by magus.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h5KNhQsh002357;
	Fri, 20 Jun 2003 16:43:26 -0700 (PDT)
Mime-Version: 1.0
X-Sender: hardie@mage.qualcomm.com
Message-Id: <p06001215bb19421dd4b0@[205.214.163.81]>
In-Reply-To: 
 <Pine.WNT.4.60.0306201440160.4048@Tomobiki-Cho.CAC.Washington.EDU>
References: <200306201133.HAA25935@ietf.org>
 <Pine.NXT.4.56.0306200520380.477@Ikkoku-Kan.Panda.COM>
 <p06001210bb18f3f05c4c@[205.214.163.81]>
 <Pine.WNT.4.60.0306201440160.4048@Tomobiki-Cho.CAC.Washington.EDU>
Date: Fri, 20 Jun 2003 16:43:30 -0700
To: Mark Crispin <MRC@CAC.Washington.EDU>
Subject: Re: [lemonade] I-D ACTION:draft-crispin-imap-urlauth-00.txt
Cc: lemonade@ietf.org, Chris.Newman@sun.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

Hi Mark,

Thanks for your response; some comments in line.

At 3:35 PM -0700 6/20/03, Mark Crispin wrote:
>Ted -
>
>Thank you very much for your well-considered and very helpful comments.
>My response is below.
>On Fri, 20 Jun 2003 hardie@qualcomm.com wrote:
>  > In the typical security model, there is first authorization ("You are who
>
>                                                 ^^^^^^^^^^^^^ authentication?

(*blush*).  Yes.  Given the rest of the message, that's an 
embarrassing mistake;
sorry for any confusion.

>  > you say you are") then authorization ("you have the rights to
>>  do $FOO").  When you embed authorization credentials in an
>...snip...
>>... authentication for an authorization.  To put this another
>>  way, anyone who knows the identifier has authorized access
>>  to the resource.
>
>This analysis is correct; the mechanism that we propose has authorization
>but not authentication.  The specific intent of the design was to provide
>authorization to entities which can not (or should not) be authenticated.
>
>To elaborate on the "should not" aspect; the goal was to create a
>mechanism to grant access to entities that do not have authentication
>credentials on the IMAP server *without* giving those entities the
>authentication credentials of the owner of the data.
>
>I thought about this, but decided for the 00 version of the draft not to
>address authentication.  If you feel that authentication must be addressed
>in this go-around, I think I know how to do that.
>
>Can you give me some additional input; specifically, is it alright to
>continue to have an authorization-only form, as long as a form with
>authentication is defined?

I think that depends on what the working group decides the use cases
warrant.  And just to be clear, Ned is the Area Advisor for the group
and I was speaking without any hat on at all.  I happen to have been
around for the previous discussions of URIs as credentials, and thought
I should share my experience.  If the language below ("I think you need either
to demonstrate..." etc.) sounded directive, I apologize.  I did not
mean to short circuit the working group's discussion of the topic.
I meant to participate in it.

>The authorization-only form, in effect, would mean "anyone including
>anonymous can use it".  A form with authentication would restrict access
>to a certain IMAP-server authenticated user or users.

I guess I'm fuzzy on the use case for "anyone including anonymous can use it".
The case I thought we were focused on is "forward without download",
which seems to require that the access to the message being forwarded be
restricted to the user (or her agent) in whose message store the message sits.
(I suppose it might also be seen as access by the user to whom the 
message has been
forwarded, but that's not the viewpoint I think we've started from.)  Can you
elaborate on when the anonymous access would be used?


>I briefly considered a signing form of authentication for the mail submit
>case, but rejected this because of excessive complexity and no actual gain
>in a submit environment.
>
>  >	There are a couple of common responses to this:
>>  creating a separate mechanism for prior authentication and limiting
>>  access to the resource in some other way such that the risk
>>  is appropriate to value of the resource being protected.
>
>This prior authentication, in the form with authentication, would be by
>means of existing IMAP authentication mechanisms.

If I understand you, then, this authentication would not be the user's
normal IMAP credentials (and I can certainly see why you would not 
want to share those
with the submit server or embed them in a URI).  They would be user
specific, however, and possibly restricted in some other way?  I assume from
the text below that they would not be server-based (since you say 
server-based ACLs
are not the focus of your effort.)  Could a user theoretically present them
through any submit server, then?

>  > It is
>>  also common to attempt to mitigate the risk by protecting the
>>  channels by which the identifier is transmitted so that the
>>  value of "anyone who knows the identifier" remains appropriate
>>  to the situation at hand.
>
>In the case of submit, there is a presumption (which perhaps should be
>stated in security considerations) that SSL/TLS-protected channels should
>be used to transmit the identifier, along with short-term expiration.

I agree that it should be noted; using TLS does add overhead for both
traffic and credentials that the group should consider.  As you note
below, we also need to be sure in the risk assessment that it
matches the risks in these environments.


>  >	The most common forms of prior authentication I
>>  have seen are tied to some form of server-based ACL ("only servers 
>>presenting
>>  the following credentials are allowed to present these URIs"); the
>>  most common forms of limitations I have seen limit access to
>>  the resource to a single attempt.
>
>I don't propose doing either of these.  Server-based ACL isn't completely
>out of the question, but I think that it's better to give authentication
>credentials on the IMAP server to users of the URLs (perhaps limited
>solely to use of URLs).  One-shot access limitations seem to me to be a
>gad idea.

In the http-based systems where I've seen it, it has been a bad idea.  There
turn out to be a *lot* of corner cases (just the accept-ranges aspect of it
make it hard to work through).  I've not thought through the IMAP-specific
aspects in any detail, but I suspect there would be similar concerns.

>  > Assuming
>>  that this were to be used in an "IMAP pull" scenario and a submit server,
>>  the "pulling" submit server is almost certain ...
>...snip...
>  > URI  can piggyback their authorized use of the submit server to create
>>  the authentication needed to allow access to the URI.
>
>Hence my presumption of the use of SSL/TLS.
>
>Also, it's important to do an appropriate risk assessment.  If the
>credential-bearing URI is intercepted, the other components of the message
>are also intercepted.  More significantly, the ultimate fate of the
>message, *including* the data accessed by the credential-bearing URI, is
>likely to be the totally-unprotected SMTP infrastructure.

I agree that it is appropriate to do a risk assessment.  I'm not sure I
agree about the importance of the use of SMTP for later delivery (as the
protections there may depend on what has been negotiated between specific
hops).  I certainly agree that if an attacker has compromised the IMAP session,
she may well have trapped the credentials which will allow full 
access to the IMAP
store (or may be able to inject requests for access in other ways). 
I would also note,
though, that there are some cases where the attacker  may be listening to
the traffic between the user and the submit server in order to get
access to the data accessed by the credential-bearing URI.


>  > I think you either need
>>  to demonstrate that access to these resources is appropriately
>>  made based solely on essentially anonymous authorization or that
>>  you have worked out the mechanisms of the larger security context
>>  so that the granularity of authentication and authorization are
>>  appropriately matched.
>
>I would like to do both, if possible; and would very much appreciate your
>assistance in accomplishing this.
>
>We glossed over some important security issues, but were focused on
>getting out a 00 draft in time for the IETF cutoff.  Hence the focus was
>to create a mechanism that was defensible from a security standpoint even
>if the details of that defense were not fully worked out.  I think that
>this proposal succeeds in doing so; but you're correct in calling out the
>glossings-over.

Sorry if my response seemed an over-reaction to a -00 draft.   The burn
marks from previous attempts at embedding credentials in URIs still
throb occasionally, though, and I wanted to respond quickly.
If that came across as heavy-handed, I apologize.
				regards,
					Ted Hardie

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



From exim@www1.ietf.org  Fri Jun 20 21:54:30 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16694
	for <lemonade-archive@odin.ietf.org>; Fri, 20 Jun 2003 21:54:30 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5L1s3724177
	for lemonade-archive@odin.ietf.org; Fri, 20 Jun 2003 21:54:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19TXZr-0006Ha-Bo
	for lemonade-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 21:54:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16691
	for <lemonade-web-archive@ietf.org>; Fri, 20 Jun 2003 21:54:00 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19TXZo-0004sX-00
	for lemonade-web-archive@ietf.org; Fri, 20 Jun 2003 21:54:00 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19TXZo-0004sU-00
	for lemonade-web-archive@ietf.org; Fri, 20 Jun 2003 21:54:00 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19TXZp-0006Gj-6Q; Fri, 20 Jun 2003 21:54:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19TXZT-0006GW-1y
	for lemonade@optimus.ietf.org; Fri, 20 Jun 2003 21:53:39 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16688
	for <lemonade@ietf.org>; Fri, 20 Jun 2003 21:53:35 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19TXZQ-0004sR-00
	for lemonade@ietf.org; Fri, 20 Jun 2003 21:53:36 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx with esmtp (Exim 4.12)
	id 19TXZP-0004sO-00
	for lemonade@ietf.org; Fri, 20 Jun 2003 21:53:35 -0400
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150])
	by numenor.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h5L1rYBd007663
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
	for <lemonade@ietf.org>; Fri, 20 Jun 2003 18:53:34 -0700 (PDT)
Received: from [129.46.74.63] (vpn-10-50-0-66.qualcomm.com [10.50.0.66])
	by sabrina.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h5L1rOBC014795;
	Fri, 20 Jun 2003 18:53:25 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <a0600170fbb196af726a4@[129.46.74.63]>
X-Mailer: Eudora for Mac OS X v6.0a
Date: Fri, 20 Jun 2003 18:53:20 -0700
To: lemonade@ietf.org
From: Randall Gellens <randy@qualcomm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Random-Sig-Tag: 1.0b25
Subject: [lemonade] New I-D: draft-gellens-lemonade-mms-mapping-00.txt
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

I've sent in a draft on mapping between MMS and Internet mail.  You can see it before it gets processed by the I-D editor at: <ftp://ftp.pensive.org/Public/Randy/mms-mapping-00.txt>.  (The draft name is draft-gellens-lemonade-mms-mapping-00.txt).     

Abstract:
    The cellular telephone industry has defined a service known as the
    Multimedia Messaging Service (MMS).  This service uses formats and
    protocols which are similar to, but differ in key ways from those
    used in Internet mail.
    
    This document specifies how to exchange messages between these two
    services, including mapping information elements as used in MMS
    X-MMS-* headers to and from that used in ESMTP and Internet message
    headers.

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



From exim@www1.ietf.org  Sat Jun 21 10:40:29 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09511
	for <lemonade-archive@odin.ietf.org>; Sat, 21 Jun 2003 10:40:29 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5LEe3Z03008
	for lemonade-archive@odin.ietf.org; Sat, 21 Jun 2003 10:40:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19TjX8-0000mR-R6
	for lemonade-web-archive@optimus.ietf.org; Sat, 21 Jun 2003 10:40:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09508
	for <lemonade-web-archive@ietf.org>; Sat, 21 Jun 2003 10:39:58 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19TjX6-0007cb-00
	for lemonade-web-archive@ietf.org; Sat, 21 Jun 2003 10:40:00 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19TjX5-0007cY-00
	for lemonade-web-archive@ietf.org; Sat, 21 Jun 2003 10:39:59 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19TjX6-0000m8-Ks; Sat, 21 Jun 2003 10:40:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19TjWk-0000lY-42
	for lemonade@optimus.ietf.org; Sat, 21 Jun 2003 10:39:38 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09505
	for <lemonade@ietf.org>; Sat, 21 Jun 2003 10:39:34 -0400 (EDT)
From: ned.freed@mrochek.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19TjWh-0007cV-00
	for lemonade@ietf.org; Sat, 21 Jun 2003 10:39:35 -0400
Received: from mauve.mrochek.com ([209.55.107.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 19TjWg-0007cS-00
	for lemonade@ietf.org; Sat, 21 Jun 2003 10:39:35 -0400
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243)
 id <01KXCINR7MGG00D1EZ@mauve.mrochek.com> for lemonade@ietf.org; Sat,
 21 Jun 2003 07:39:23 -0700 (PDT)
Date: Sat, 21 Jun 2003 07:38:45 -0700 (PDT)
Subject: Re: [lemonade] New I-D: draft-gellens-lemonade-mms-mapping-00.txt
In-reply-to: "Your message dated Fri, 20 Jun 2003 18:53:20 -0700"
 <a0600170fbb196af726a4@[129.46.74.63]>
To: Randall Gellens <randy@qualcomm.com>
Cc: lemonade@ietf.org
Message-id: <01KXCK66NCK000D1EZ@mauve.mrochek.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <a0600170fbb196af726a4@[129.46.74.63]>
Content-Transfer-Encoding: 7BIT
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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-Transfer-Encoding: 7BIT
Content-Transfer-Encoding: 7BIT

> I've sent in a draft on mapping between MMS and Internet mail.  You can see it before it gets processed by the I-D editor at: <ftp://ftp.pensive.org/Public/Randy/mms-mapping-00.txt>.  (The draft name is draft-gellens-lemonade-mms-mapping-00.txt).

> Abstract:
>     The cellular telephone industry has defined a service known as the
>     Multimedia Messaging Service (MMS).  This service uses formats and
>     protocols which are similar to, but differ in key ways from those
>     used in Internet mail.
    
>     This document specifies how to exchange messages between these two
>     services, including mapping information elements as used in MMS
>     X-MMS-* headers to and from that used in ESMTP and Internet message
>     headers.

Randy, one point that jumps out immediately is that you should be using
MMS-* headers, not X-MMS-* headers.

				Ned

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



From exim@www1.ietf.org  Sat Jun 21 10:43:29 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09566
	for <lemonade-archive@odin.ietf.org>; Sat, 21 Jun 2003 10:43:28 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5LEh2m03262
	for lemonade-archive@odin.ietf.org; Sat, 21 Jun 2003 10:43:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Tja2-0000qX-Eo
	for lemonade-web-archive@optimus.ietf.org; Sat, 21 Jun 2003 10:43:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09547
	for <lemonade-web-archive@ietf.org>; Sat, 21 Jun 2003 10:42:58 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Tja0-0007cy-00
	for lemonade-web-archive@ietf.org; Sat, 21 Jun 2003 10:43:00 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19TjZz-0007cv-00
	for lemonade-web-archive@ietf.org; Sat, 21 Jun 2003 10:42:59 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Tja1-0000pO-3n; Sat, 21 Jun 2003 10:43:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19TjZN-0000p4-1B
	for lemonade@optimus.ietf.org; Sat, 21 Jun 2003 10:42:21 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09543
	for <lemonade@ietf.org>; Sat, 21 Jun 2003 10:42:17 -0400 (EDT)
From: ned.freed@mrochek.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19TjZK-0007cr-00
	for lemonade@ietf.org; Sat, 21 Jun 2003 10:42:18 -0400
Received: from mauve.mrochek.com ([209.55.107.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 19TjZJ-0007co-00
	for lemonade@ietf.org; Sat, 21 Jun 2003 10:42:18 -0400
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243)
 id <01KXCK81VAA800D1EZ@mauve.mrochek.com> for lemonade@ietf.org; Sat,
 21 Jun 2003 07:41:59 -0700 (PDT)
Date: Sat, 21 Jun 2003 07:41:26 -0700 (PDT)
Subject: Re: [lemonade] New I-D: draft-gellens-lemonade-mms-mapping-00.txt
In-reply-to: "Your message dated Sat, 21 Jun 2003 07:38:45 -0700 (PDT)"
 <01KXCK66NCK000D1EZ@mauve.mrochek.com>
To: ned.freed@mrochek.com
Cc: Randall Gellens <randy@qualcomm.com>, lemonade@ietf.org
Message-id: <01KXCK9EPG3W00D1EZ@mauve.mrochek.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <a0600170fbb196af726a4@[129.46.74.63]>
 <01KXCK66NCK000D1EZ@mauve.mrochek.com>
Content-Transfer-Encoding: 7BIT
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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-Transfer-Encoding: 7BIT
Content-Transfer-Encoding: 7BIT

> > I've sent in a draft on mapping between MMS and Internet mail.  You can see it before it gets processed by the I-D editor at: <ftp://ftp.pensive.org/Public/Randy/mms-mapping-00.txt>.  (The draft name is draft-gellens-lemonade-mms-mapping-00.txt).

> > Abstract:
> >     The cellular telephone industry has defined a service known as the
> >     Multimedia Messaging Service (MMS).  This service uses formats and
> >     protocols which are similar to, but differ in key ways from those
> >     used in Internet mail.
    
> >     This document specifies how to exchange messages between these two
> >     services, including mapping information elements as used in MMS
> >     X-MMS-* headers to and from that used in ESMTP and Internet message
> >     headers.

> Randy, one point that jumps out immediately is that you should be using
> MMS-* headers, not X-MMS-* headers.

Never mind. It is MMS that uses X- fields for standard purposes. Forgot
about that.

				Ned

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



From exim@www1.ietf.org  Sun Jun 22 01:51:56 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23855
	for <lemonade-archive@odin.ietf.org>; Sun, 22 Jun 2003 01:51:56 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5M5pSn13052
	for lemonade-archive@odin.ietf.org; Sun, 22 Jun 2003 01:51:28 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Txkv-0003O8-1V
	for lemonade-web-archive@optimus.ietf.org; Sun, 22 Jun 2003 01:51:28 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23851
	for <lemonade-web-archive@ietf.org>; Sun, 22 Jun 2003 01:51:11 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Txkr-0002oc-00
	for lemonade-web-archive@ietf.org; Sun, 22 Jun 2003 01:51:09 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Txkm-0002oY-00
	for lemonade-web-archive@ietf.org; Sun, 22 Jun 2003 01:51:04 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Txki-0003Mz-SY; Sun, 22 Jun 2003 01:51:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19TxjI-0003MB-2r
	for lemonade@optimus.ietf.org; Sun, 22 Jun 2003 01:50:51 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23839
	for <lemonade@ietf.org>; Sun, 22 Jun 2003 01:49:25 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Txj9-0002oM-00
	for lemonade@ietf.org; Sun, 22 Jun 2003 01:49:23 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Txiz-0002oI-00
	for lemonade@ietf.org; Sun, 22 Jun 2003 01:49:13 -0400
Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151])
	by numenor.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h5M5mcBd017321
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Sat, 21 Jun 2003 22:48:38 -0700 (PDT)
Received: from [192.168.1.13] (vpn-10-50-0-23.qualcomm.com [10.50.0.23])
	by crowley.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h5M5mTix027665;
	Sat, 21 Jun 2003 22:48:33 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <a06001703bb1af30b0b74@[192.168.1.13]>
In-Reply-To: 
 <Pine.WNT.4.60.0306201440160.4048@Tomobiki-Cho.CAC.Washington.EDU>
References: <200306201133.HAA25935@ietf.org>
 <Pine.NXT.4.56.0306200520380.477@Ikkoku-Kan.Panda.COM>
 <p06001210bb18f3f05c4c@[205.214.163.81]>
 <Pine.WNT.4.60.0306201440160.4048@Tomobiki-Cho.CAC.Washington.EDU>
X-Mailer: Eudora for Mac OS X v6.0a
Date: Sat, 21 Jun 2003 22:47:13 -0700
To: Mark Crispin <MRC@CAC.Washington.EDU>, hardie@qualcomm.com
From: Randall Gellens <randy@qualcomm.com>
Subject: Re: [lemonade] I-D ACTION:draft-crispin-imap-urlauth-00.txt
Cc: lemonade@ietf.org, Chris.Newman@sun.com, Allison Mankin <mankin@psg.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b25
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

At 3:35 PM -0700 6/20/03, Mark Crispin wrote:

>   > I also strongly believe that Mark's comment
>>  below (that there is a pent-up need for this mechanism for other
>>  purposes) needs to be understood within the limitations of this method.
>
>  Well, there are a couple of needs that come immediately to mind, but both
>  boil down to a desire for a finer granularity of authorization, both for
>  anonymous and for non-anonymous access, and to do it in a way that is
>  revokable and which has an optional expiration.

It occurs to me that a mechanism like this could be useful for 
geopriv, where anonymous authorization is needed.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Implementation is the sincerest form of flattery.

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



From exim@www1.ietf.org  Sun Jun 22 02:00:36 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24516
	for <lemonade-archive@odin.ietf.org>; Sun, 22 Jun 2003 02:00:36 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5M607313521
	for lemonade-archive@odin.ietf.org; Sun, 22 Jun 2003 02:00:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19TxtX-0003W0-Gm
	for lemonade-web-archive@optimus.ietf.org; Sun, 22 Jun 2003 02:00:07 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24001
	for <lemonade-web-archive@ietf.org>; Sun, 22 Jun 2003 02:00:05 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19TxtU-0002pp-00
	for lemonade-web-archive@ietf.org; Sun, 22 Jun 2003 02:00:04 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19TxtO-0002pm-00
	for lemonade-web-archive@ietf.org; Sun, 22 Jun 2003 01:59:58 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19TxtQ-0003Ui-VK; Sun, 22 Jun 2003 02:00:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19TxtO-0003U8-80
	for lemonade@optimus.ietf.org; Sun, 22 Jun 2003 01:59:58 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23915
	for <lemonade@ietf.org>; Sun, 22 Jun 2003 01:59:56 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19TxtK-0002pi-00
	for lemonade@ietf.org; Sun, 22 Jun 2003 01:59:55 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx with esmtp (Exim 4.12)
	id 19TxtA-0002pf-00
	for lemonade@ietf.org; Sun, 22 Jun 2003 01:59:44 -0400
Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148])
	by numenor.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h5M5xaBd017577
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Sat, 21 Jun 2003 22:59:36 -0700 (PDT)
Received: from [192.168.1.13] (vpn-10-50-0-23.qualcomm.com [10.50.0.23])
	by magus.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h5M5xUsh023668;
	Sat, 21 Jun 2003 22:59:31 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <a06001704bb1af42c4f2d@[192.168.1.13]>
In-Reply-To: <p06001215bb19421dd4b0@[205.214.163.81]>
References: <200306201133.HAA25935@ietf.org>
 <Pine.NXT.4.56.0306200520380.477@Ikkoku-Kan.Panda.COM>
 <p06001210bb18f3f05c4c@[205.214.163.81]>
 <Pine.WNT.4.60.0306201440160.4048@Tomobiki-Cho.CAC.Washington.EDU>
 <p06001215bb19421dd4b0@[205.214.163.81]>
X-Mailer: Eudora for Mac OS X v6.0a
Date: Sat, 21 Jun 2003 22:53:56 -0700
To: hardie@qualcomm.com, Mark Crispin <MRC@CAC.Washington.EDU>
From: Randall Gellens <randy@qualcomm.com>
Subject: Re: [lemonade] I-D ACTION:draft-crispin-imap-urlauth-00.txt
Cc: lemonade@ietf.org, Chris.Newman@sun.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b25
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

At 4:43 PM -0700 6/20/03, hardie@qualcomm.com wrote:

>  there are some cases where the attacker  may be listening to
>  the traffic between the user and the submit server in order to get
>  access to the data accessed by the credential-bearing URI.

Presumably if an attacker is able to listen to the traffic between 
the user and the submit server, the attacker has access to all 
non-encrypted messages being submitted.  Since today most email is 
submitted in this way, that would be most email.  The URL-based 
authorization probably is no worse than what we have today (unless it 
allows denial-of-service).
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Whenever you find that you are on the side of the majority, it is
time to reform.                                      --Mark Twain

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



From exim@www1.ietf.org  Sun Jun 22 16:43:45 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18040
	for <lemonade-archive@odin.ietf.org>; Sun, 22 Jun 2003 16:43:45 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5MKh8F11128
	for lemonade-archive@odin.ietf.org; Sun, 22 Jun 2003 16:43:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19UBg4-0002tP-6r
	for lemonade-web-archive@optimus.ietf.org; Sun, 22 Jun 2003 16:43:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18027
	for <lemonade-web-archive@ietf.org>; Sun, 22 Jun 2003 16:43:05 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19UBg2-0005QB-00
	for lemonade-web-archive@ietf.org; Sun, 22 Jun 2003 16:43:06 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19UBfw-0005Q8-00
	for lemonade-web-archive@ietf.org; Sun, 22 Jun 2003 16:43:00 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19UBfx-0002sG-7C; Sun, 22 Jun 2003 16:43:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19UBe0-0002q4-Vr
	for lemonade@optimus.ietf.org; Sun, 22 Jun 2003 16:42:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18008
	for <lemonade@ietf.org>; Sun, 22 Jun 2003 16:40:43 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19UBdk-0005Pt-00
	for lemonade@ietf.org; Sun, 22 Jun 2003 16:40:44 -0400
Received: from oe-im2pub.managedmail.com ([206.46.164.53] helo=oe-im2.bizmailsrvcs.net)
	by ietf-mx with esmtp (Exim 4.12)
	id 19UBdZ-0005Pn-00
	for lemonade@ietf.org; Sun, 22 Jun 2003 16:40:33 -0400
Received: from oe-ismta2.bizmailsrvcs.net ([206.46.164.29])
          by oe-im2.bizmailsrvcs.net
          (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP
          id <20030622203942.OSCF7174.oe-im2.bizmailsrvcs.net@oe-ismta2.bizmailsrvcs.net>;
          Sun, 22 Jun 2003 15:39:42 -0500
Received: from RoselinskyM ([206.35.147.89]) by oe-ismta2.bizmailsrvcs.net
          (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with SMTP
          id <20030622203942.IXPA8315.oe-ismta2.bizmailsrvcs.net@RoselinskyM>;
          Sun, 22 Jun 2003 15:39:42 -0500
From: "Milt Roselinsky" <milt.roselinsky@openwave.com>
To: <ned.freed@mrochek.com>
Cc: "Randall Gellens" <randy@qualcomm.com>, <lemonade@ietf.org>
Subject: RE: [lemonade] New I-D: draft-gellens-lemonade-mms-mapping-00.txt
Date: Sun, 22 Jun 2003 13:39:41 -0700
Message-ID: <LKEFIMGGONBOPJOEOFLOGEJIFKAA.milt.roselinsky@openwave.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <01KXCK9EPG3W00D1EZ@mauve.mrochek.com>
Content-Transfer-Encoding: 7bit
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Randy,

I would suggest we use MMS-* headers and deprecate the X-MMS usage.  If this
is agreed upon, there's still time to get it into 3GPP Release 6 MMS
specifications.

Milt

> -----Original Message-----
> From: lemonade-admin@ietf.org [mailto:lemonade-admin@ietf.org]On Behalf
> Of ned.freed@mrochek.com
> Sent: Saturday, June 21, 2003 7:41 AM
> To: ned.freed@mrochek.com
> Cc: Randall Gellens; lemonade@ietf.org
> Subject: Re: [lemonade] New I-D:
> draft-gellens-lemonade-mms-mapping-00.txt
>
>
> > > I've sent in a draft on mapping between MMS and Internet
> mail.  You can see it before it gets processed by the I-D editor
> at: <ftp://ftp.pensive.org/Public/Randy/mms-mapping-00.txt>.
> (The draft name is draft-gellens-lemonade-mms-mapping-00.txt).
>
> > > Abstract:
> > >     The cellular telephone industry has defined a service known as the
> > >     Multimedia Messaging Service (MMS).  This service uses formats and
> > >     protocols which are similar to, but differ in key ways from those
> > >     used in Internet mail.
>
> > >     This document specifies how to exchange messages between these two
> > >     services, including mapping information elements as used in MMS
> > >     X-MMS-* headers to and from that used in ESMTP and
> Internet message
> > >     headers.
>
> > Randy, one point that jumps out immediately is that you should be using
> > MMS-* headers, not X-MMS-* headers.
>
> Never mind. It is MMS that uses X- fields for standard purposes. Forgot
> about that.
>
> 				Ned
>
> _______________________________________________
> 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 exim@www1.ietf.org  Wed Jun 25 11:07:05 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14203
	for <lemonade-archive@odin.ietf.org>; Wed, 25 Jun 2003 11:07:05 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5PF6dL27259
	for lemonade-archive@odin.ietf.org; Wed, 25 Jun 2003 11:06:39 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VBr5-00074V-J5
	for lemonade-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 11:06:39 -0400
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14156
	for <lemonade-web-archive@ietf.org>; Wed, 25 Jun 2003 11:06:34 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VBqT-0006sl-FY; Wed, 25 Jun 2003 11:06:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VBpC-0006YL-1J
	for lemonade@optimus.ietf.org; Wed, 25 Jun 2003 11:04:42 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12437;
	Wed, 25 Jun 2003 10:50:47 -0400 (EDT)
Message-Id: <200306251450.KAA12437@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: lemonade@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 25 Jun 2003 10:50:47 -0400
Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-imap-channel-00.txt
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

--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		: IMAP CHANNEL Protocol and Use Cases
	Author(s)	: E. Burger
	Filename	: draft-ietf-lemonade-imap-channel-00.txt
	Pages		: 14
	Date		: 2003-6-24
	
Environments that extend beyond traditional text-based e-mail use 
IMAP4 to serve rich media content.  One example is a cellular 
telephone that can retrieve and send MIME-encoded audio data through 
IMAP4.  While IMAP4 can exchange this type of content, some 
applications will work better if the message content can be 
manipulated using schemes external to the IMAP4 connection.  In our 
cellular telephone example, it might be preferable for the telephone 
client to retrieve the audio data using RTSP.  This specification 
defines a mechanism for an IMAP4 client to request message content 
from a server through an external scheme.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-imap-channel-00.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-imap-channel-00.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:	<2003-6-25102744.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-lemonade-imap-channel-00.txt

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

Content-Type: text/plain
Content-ID:	<2003-6-25102744.I-D@ietf.org>

--OtherAccess--

--NextPart--



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



From exim@www1.ietf.org  Wed Jun 25 11:35:53 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15997
	for <lemonade-archive@odin.ietf.org>; Wed, 25 Jun 2003 11:35:53 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5PFZP905737
	for lemonade-archive@odin.ietf.org; Wed, 25 Jun 2003 11:35:25 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VCIv-0001US-9y
	for lemonade-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 11:35:25 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15639
	for <lemonade-web-archive@ietf.org>; Wed, 25 Jun 2003 11:35:22 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19VCIu-0004eL-00
	for lemonade-web-archive@ietf.org; Wed, 25 Jun 2003 11:35:24 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19VCIn-0004dQ-00
	for lemonade-web-archive@ietf.org; Wed, 25 Jun 2003 11:35:17 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VCIi-00015m-06; Wed, 25 Jun 2003 11:35:12 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VBpC-0006YL-Es
	for lemonade@optimus.ietf.org; Wed, 25 Jun 2003 11:04:42 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12420;
	Wed, 25 Jun 2003 10:50:43 -0400 (EDT)
Message-Id: <200306251450.KAA12420@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: lemonade@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 25 Jun 2003 10:50:43 -0400
Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-goals-00.txt
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

--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		: Goals for Internet Messaging to Support Diverse 
                          Service Environments
	Author(s)	: J. Wong
	Filename	: draft-ietf-lemonade-goals-00.txt
	Pages		: 33
	Date		: 2003-6-24
	
The mission of LEMONADE -- Internet Messaging to support diverse service 
environments -- is to provide a set of enhancements and profiles to Internet email to facilitate operation on platforms with constrained resources, or communications links with high latency or limited bandwidth. The enhanced mail service must continue to support conventional environments seamlessly. 
The primary driver for this effort is, by making Internet mail protocols 
richer and more media and environment-savvy, to allow their use over the 
mobile Internet.   
Stressing the needs of wireless handheld devices, a discussion is given of what is required of Internet messaging protocols to enable the support of multimedia messaging on limited capability messaging clients in diverse service environments. Also included is a list of general principles to guide the design of the enhanced messaging protocols. Finally, some issues around providing seamless service between enhanced Internet email and the existing separate mobile messaging infrastructure are briefly listed. 
Discussion of this and related drafts are on the LEMONADE WG email list. To subscribe, send the message 'subscribe' to lemonade-request@ietf.org. The public archive is in the directory at: 
ftp://ftp.ietf.org/ietf-mailing-lists/lemonade/

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-goals-00.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-goals-00.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:	<2003-6-25102720.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-lemonade-goals-00.txt

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

Content-Type: text/plain
Content-ID:	<2003-6-25102720.I-D@ietf.org>

--OtherAccess--

--NextPart--



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



From exim@www1.ietf.org  Wed Jun 25 12:13:36 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19507
	for <lemonade-archive@odin.ietf.org>; Wed, 25 Jun 2003 12:13:36 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5PGD8g07683
	for lemonade-archive@odin.ietf.org; Wed, 25 Jun 2003 12:13:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VCIu-0001Tt-98
	for lemonade-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 11:35:39 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15627
	for <lemonade-web-archive@ietf.org>; Wed, 25 Jun 2003 11:35:20 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19VCIs-0004eA-00
	for lemonade-web-archive@ietf.org; Wed, 25 Jun 2003 11:35:22 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19VCIm-0004d9-00
	for lemonade-web-archive@ietf.org; Wed, 25 Jun 2003 11:35:16 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VCIe-00011r-Qw; Wed, 25 Jun 2003 11:35:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VBqX-0006YL-1M
	for lemonade@optimus.ietf.org; Wed, 25 Jun 2003 11:06:20 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08094
	for <lemonade@ietf.org>; Wed, 25 Jun 2003 08:48:20 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19V9hF-0003bv-00
	for lemonade@ietf.org; Wed, 25 Jun 2003 08:48:21 -0400
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx with esmtp (Exim 4.12)
	id 19V9h4-0003bX-00
	for lemonade@ietf.org; Wed, 25 Jun 2003 08:48:10 -0400
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5PClDt17048;
	Wed, 25 Jun 2003 08:47:13 -0400 (EDT)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <NLVYM2QF>; Wed, 25 Jun 2003 08:47:13 -0400
Message-ID: <D38D073716F2D411BEE400508BCF6296052AE53B@zcard04k.ca.nortel.com>
From: "Glenn Parsons" <gparsons@nortelnetworks.com>
To: "'lemonade@ietf.org'" <lemonade@ietf.org>
Cc: "'eburger@snowshore.com'" <eburger@snowshore.com>
Date: Wed, 25 Jun 2003 08:47:13 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C33B15.7BFF7B9E"
Subject: [lemonade] Agenda for Vienna
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C33B15.7BFF7B9E
Content-Type: text/plain;
	charset="iso-8859-1"

Folks,

If you would like some time on the agenda in Vienna, please let myself and
Eric know.

Remember that you will need to have an ID published in order to have
something to talk about :-)

We'll give you until June 30th (same as the final ID cutoff) to let us know
if you'd like to be on the LEMONADE agenda.

As a reminder our confirmed IETF 57 slot is:THURSDAY, July 17, 20031530-1730 Afternoon Sessions IIAPP 	lemonade License to Enhance Messaging Oriented Network Access for 	    	 Diverse Endpoints WG

And finally, our goal for this meeting will be to focus on working on our
initial set of WG documents.  So our preliminary agenda is focused only on
these documents.

Cheers,
Glenn.



------_=_NextPart_001_01C33B15.7BFF7B9E
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>Agenda for Vienna</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Folks,</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">If you would like =
some time on the agenda in Vienna, please let myself and Eric =
know.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Remember that you =
will need to have an ID published in order to have something to talk =
about :-)</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">We'll give you until =
June 30th (same as the final ID cutoff) to let us know if you'd like to =
be on the LEMONADE agenda.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">As a reminder our =
confirmed IETF 57 slot is:=0D=0D</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">THURSDAY, July 17, 2003=0D1530-1730 Afternoon Sessions =
II=0DAPP &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; lemonade License to Enhance =
Messaging Oriented Network Access for =0D&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; Diverse Endpoints =
WG</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">And finally, our =
goal for this meeting will be to focus on working on our initial set of =
WG documents.&nbsp; So our preliminary agenda is focused only on these =
documents.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Cheers,</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Glenn.</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C33B15.7BFF7B9E--

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



From exim@www1.ietf.org  Wed Jun 25 12:50:40 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20977
	for <lemonade-archive@odin.ietf.org>; Wed, 25 Jun 2003 12:50:40 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5PGoCO14116
	for lemonade-archive@odin.ietf.org; Wed, 25 Jun 2003 12:50:12 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VDTI-0003fb-I9
	for lemonade-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 12:50:12 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20965
	for <lemonade-web-archive@ietf.org>; Wed, 25 Jun 2003 12:50:09 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19VDTI-0005Lh-00
	for lemonade-web-archive@ietf.org; Wed, 25 Jun 2003 12:50:12 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19VDTC-0005Lb-00
	for lemonade-web-archive@ietf.org; Wed, 25 Jun 2003 12:50:06 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VDT7-0003cQ-Qg; Wed, 25 Jun 2003 12:50:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VDSd-0003bm-6V
	for lemonade@optimus.ietf.org; Wed, 25 Jun 2003 12:49:31 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20951
	for <lemonade@ietf.org>; Wed, 25 Jun 2003 12:49:28 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19VDSc-0005LK-00
	for lemonade@ietf.org; Wed, 25 Jun 2003 12:49:30 -0400
Received: from champdsl-25-66.mcleodusa.net ([216.43.25.66] helo=episteme-software.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19VDSR-0005Ke-00
	for lemonade@ietf.org; Wed, 25 Jun 2003 12:49:19 -0400
Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with
 ESMTP (Eudora Internet Mail Server X 3.2.2b1) for <lemonade@ietf.org>;
 Wed, 25 Jun 2003 11:46:41 -0500
Mime-Version: 1.0
X-Sender: resnick@resnick1.qualcomm.com
Message-Id: <p06001725bb1f81e4fca8@[216.43.25.67]>
In-Reply-To: <200306251450.KAA12437@ietf.org>
References: <200306251450.KAA12437@ietf.org>
X-Mailer: Eudora [Macintosh version 6.0a23]
Date: Wed, 25 Jun 2003 11:46:39 -0500
To: lemonade@ietf.org
From: Pete Resnick <presnick@qualcomm.com>
Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-imap-channel-00.txt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

Yick! I thought we had decided to remove the "mail sending" stuff. 
Even I agreed it was a weird side-effect hack and outside of what 
CHANNEL was intended to do.

I hope that people *don't* consider this is my proposal for IMAP mail 
sending; I disavow it.

pr
-- 
Pete Resnick <mailto:presnick@qualcomm.com>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

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



From exim@www1.ietf.org  Wed Jun 25 14:47:37 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25118
	for <lemonade-archive@odin.ietf.org>; Wed, 25 Jun 2003 14:47:37 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5PIl9b05611
	for lemonade-archive@odin.ietf.org; Wed, 25 Jun 2003 14:47:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VFIT-0001SQ-1r
	for lemonade-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 14:47:09 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25065
	for <lemonade-web-archive@ietf.org>; Wed, 25 Jun 2003 14:47:06 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19VFIR-000677-00
	for lemonade-web-archive@ietf.org; Wed, 25 Jun 2003 14:47:07 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19VFIM-000674-00
	for lemonade-web-archive@ietf.org; Wed, 25 Jun 2003 14:47:02 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VFIL-0001RH-6x; Wed, 25 Jun 2003 14:47:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VFHi-0001Qn-Ug
	for lemonade@optimus.ietf.org; Wed, 25 Jun 2003 14:46:22 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25037
	for <lemonade@ietf.org>; Wed, 25 Jun 2003 14:46:20 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19VFHh-00066g-00
	for lemonade@ietf.org; Wed, 25 Jun 2003 14:46:21 -0400
Received: from orthanc.ab.ca ([216.123.230.114])
	by ietf-mx with esmtp (Exim 4.12)
	id 19VFHV-00066a-00
	for lemonade@ietf.org; Wed, 25 Jun 2003 14:46:10 -0400
Received: from orthanc.ab.ca (peregrin.orthanc.ab.ca [192.168.42.6])
	by orthanc.ab.ca (8.12.6p2/8.12.6) with ESMTP id h5PIjlUW076826;
	Wed, 25 Jun 2003 12:45:47 -0600 (MDT)
	(envelope-from lyndon@orthanc.ab.ca)
Date: Wed, 25 Jun 2003 12:45:46 -0600
Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-imap-channel-00.txt
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: lemonade@ietf.org
To: Pete Resnick <presnick@qualcomm.com>
From: Lyndon Nerenberg <lyndon@orthanc.ab.ca>
In-Reply-To: <p06001725bb1f81e4fca8@[216.43.25.67]>
Message-Id: <3BCB2E12-A73D-11D7-8B4F-000393D34A62@orthanc.ab.ca>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
Content-Transfer-Encoding: 7bit
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


On Wednesday, June 25, 2003, at 10:46  AM, Pete Resnick wrote:

> Yick! I thought we had decided to remove the "mail sending" stuff. 
> Even I agreed it was a weird side-effect hack and outside of what 
> CHANNEL was intended to do.

What I want to know is how this specification got hijacked without the 
original document authors even being *asked* about it.

--lyndon


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



From exim@www1.ietf.org  Thu Jun 26 01:10:36 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26246
	for <lemonade-archive@odin.ietf.org>; Thu, 26 Jun 2003 01:10:36 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5Q5A8w25084
	for lemonade-archive@odin.ietf.org; Thu, 26 Jun 2003 01:10:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VP1M-0006WV-07
	for lemonade-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 01:10:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26242
	for <lemonade-web-archive@ietf.org>; Thu, 26 Jun 2003 01:10:06 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19VP1J-0005ak-00
	for lemonade-web-archive@ietf.org; Thu, 26 Jun 2003 01:10:05 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19VP1D-0005ah-00
	for lemonade-web-archive@ietf.org; Thu, 26 Jun 2003 01:09:59 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VP1E-0006U9-Mv; Thu, 26 Jun 2003 01:10:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VOzz-0006PQ-IN
	for lemonade@optimus.ietf.org; Thu, 26 Jun 2003 01:09:28 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26235
	for <lemonade@ietf.org>; Thu, 26 Jun 2003 01:08:41 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19VOzw-0005aU-00
	for lemonade@ietf.org; Thu, 26 Jun 2003 01:08:40 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx with esmtp (Exim 4.12)
	id 19VOzl-0005aQ-00
	for lemonade@ietf.org; Thu, 26 Jun 2003 01:08:29 -0400
Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151])
	by numenor.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h5Q587Bd011716
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Wed, 25 Jun 2003 22:08:07 -0700 (PDT)
Received: from [192.168.1.13] (vpn-10-50-16-7.qualcomm.com [10.50.16.7])
	by crowley.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h5Q582ix020741;
	Wed, 25 Jun 2003 22:08:04 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <a06001702bb202fb4ba41@[192.168.1.13]>
In-Reply-To: 
 <D38D073716F2D411BEE400508BCF6296052AE53B@zcard04k.ca.nortel.com>
References: 
 <D38D073716F2D411BEE400508BCF6296052AE53B@zcard04k.ca.nortel.com>
X-Mailer: Eudora for Mac OS X v6.0a
Date: Wed, 25 Jun 2003 22:07:57 -0700
To: "Glenn Parsons" <gparsons@nortelnetworks.com>,
        "'lemonade@ietf.org'" <lemonade@ietf.org>
From: Randall Gellens <randy@qualcomm.com>
Subject: Re: [lemonade] Agenda for Vienna
Cc: "'eburger@snowshore.com'" <eburger@snowshore.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b25
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

At 8:47 AM -0400 6/25/03, Glenn Parsons wrote:

>  If you would like some time on the agenda in Vienna, please let 
> myself and Eric know.

I'd like to discuss making the I-D I published on mapping between MMS 
and Internet mail a working group document.  It fits in the charter 
(under "gateways").  Draft is 
draft-gellens-lemonade-mms-mapping-00.txt.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Advertising is 85 percent confusion and 15 percent commission.
                                                 --Fred Allen

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



From exim@www1.ietf.org  Thu Jun 26 02:38:36 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10231
	for <lemonade-archive@odin.ietf.org>; Thu, 26 Jun 2003 02:38:36 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5Q6c9q26553
	for lemonade-archive@odin.ietf.org; Thu, 26 Jun 2003 02:38:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VQOW-0006uC-R8
	for lemonade-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 02:38:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10212
	for <lemonade-web-archive@ietf.org>; Thu, 26 Jun 2003 02:38:05 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19VQOT-00068T-00
	for lemonade-web-archive@ietf.org; Thu, 26 Jun 2003 02:38:05 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19VQON-00068Q-00
	for lemonade-web-archive@ietf.org; Thu, 26 Jun 2003 02:37:59 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VQOP-0006sK-K1; Thu, 26 Jun 2003 02:38:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VQNb-0006dD-IO
	for lemonade@optimus.ietf.org; Thu, 26 Jun 2003 02:37:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10197
	for <lemonade@ietf.org>; Thu, 26 Jun 2003 02:37:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19VQNX-000687-00
	for lemonade@ietf.org; Thu, 26 Jun 2003 02:37:07 -0400
Received: from orthanc.ab.ca ([216.123.230.114])
	by ietf-mx with esmtp (Exim 4.12)
	id 19VQNM-00067l-00
	for lemonade@ietf.org; Thu, 26 Jun 2003 02:36:56 -0400
Received: from orthanc.ab.ca (peregrin.orthanc.ab.ca [192.168.42.6])
	by orthanc.ab.ca (8.12.6p2/8.12.6) with ESMTP id h5Q6aBUW079409;
	Thu, 26 Jun 2003 00:36:11 -0600 (MDT)
	(envelope-from lyndon@orthanc.ab.ca)
Date: Thu, 26 Jun 2003 00:36:10 -0600
Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-imap-channel-00.txt
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: lemonade@ietf.org
To: Pete Resnick <presnick@qualcomm.com>
From: Lyndon Nerenberg <lyndon@orthanc.ab.ca>
In-Reply-To: <p06001725bb1f81e4fca8@[216.43.25.67]>
Message-Id: <79BFF1B5-A7A0-11D7-8B4F-000393D34A62@orthanc.ab.ca>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
Content-Transfer-Encoding: 7bit
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


On Wednesday, June 25, 2003, at 10:46  AM, Pete Resnick wrote:

> Yick! I thought we had decided to remove the "mail sending" stuff. 
> Even I agreed it was a weird side-effect hack and outside of what 
> CHANNEL was intended to do.

I agree. Section 5.4 presumes too much. I cannot now answer how I think 
that particular scheme should fit into the overall Channel 
infrastructure. That's one reason why we're thinking about this before 
cranking out another draft.

--lyndon


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



From exim@www1.ietf.org  Thu Jun 26 02:46:35 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10353
	for <lemonade-archive@odin.ietf.org>; Thu, 26 Jun 2003 02:46:35 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5Q6k8e28351
	for lemonade-archive@odin.ietf.org; Thu, 26 Jun 2003 02:46:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VQWF-0007NC-Tk
	for lemonade-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 02:46:07 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10349
	for <lemonade-web-archive@ietf.org>; Thu, 26 Jun 2003 02:46:04 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19VQWC-00069o-00
	for lemonade-web-archive@ietf.org; Thu, 26 Jun 2003 02:46:04 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19VQW6-00069l-00
	for lemonade-web-archive@ietf.org; Thu, 26 Jun 2003 02:45:58 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VQW9-0007M0-8Q; Thu, 26 Jun 2003 02:46:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VQW5-0007Lo-JX
	for lemonade@optimus.ietf.org; Thu, 26 Jun 2003 02:45:57 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10345
	for <lemonade@ietf.org>; Thu, 26 Jun 2003 02:45:54 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19VQW1-00069f-00
	for lemonade@ietf.org; Thu, 26 Jun 2003 02:45:53 -0400
Received: from orthanc.ab.ca ([216.123.230.114])
	by ietf-mx with esmtp (Exim 4.12)
	id 19VQVq-00069c-00
	for lemonade@ietf.org; Thu, 26 Jun 2003 02:45:43 -0400
Received: from orthanc.ab.ca (peregrin.orthanc.ab.ca [192.168.42.6])
	by orthanc.ab.ca (8.12.6p2/8.12.6) with ESMTP id h5Q6jcUW079439;
	Thu, 26 Jun 2003 00:45:38 -0600 (MDT)
	(envelope-from lyndon@orthanc.ab.ca)
Date: Thu, 26 Jun 2003 00:45:38 -0600
Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-imap-channel-00.txt
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: Pete Resnick <presnick@qualcomm.com>, lemonade@ietf.org
To: Lyndon Nerenberg <lyndon@orthanc.ab.ca>
From: Lyndon Nerenberg <lyndon@orthanc.ab.ca>
In-Reply-To: <79BFF1B5-A7A0-11D7-8B4F-000393D34A62@orthanc.ab.ca>
Message-Id: <CBF97CE2-A7A1-11D7-8B4F-000393D34A62@orthanc.ab.ca>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
Content-Transfer-Encoding: 7bit
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

>  That's one reason why we're thinking about this

Typing too fast. s/we're/we were/

--lyndon


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



From exim@www1.ietf.org  Thu Jun 26 04:24:55 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12108
	for <lemonade-archive@odin.ietf.org>; Thu, 26 Jun 2003 04:24:54 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5Q8OR922987
	for lemonade-archive@odin.ietf.org; Thu, 26 Jun 2003 04:24:27 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VS3P-0005yg-89
	for lemonade-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 04:24:27 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11920
	for <lemonade-web-archive@ietf.org>; Thu, 26 Jun 2003 04:24:24 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19VS3M-0006ab-00
	for lemonade-web-archive@ietf.org; Thu, 26 Jun 2003 04:24:24 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19VS3G-0006aY-00
	for lemonade-web-archive@ietf.org; Thu, 26 Jun 2003 04:24:18 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VS3E-0005s1-F2; Thu, 26 Jun 2003 04:24:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VRnu-0004x5-3O
	for lemonade@optimus.ietf.org; Thu, 26 Jun 2003 04:08:26 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11660
	for <lemonade@ietf.org>; Thu, 26 Jun 2003 04:08:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19VRnc-0006Vp-00
	for lemonade@ietf.org; Thu, 26 Jun 2003 04:08:08 -0400
Received: from comversegw.icomverse.com ([192.118.48.248] helo=il-tlv-smtpout2.icomverse.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19VRnR-0006Vg-00
	for lemonade@ietf.org; Thu, 26 Jun 2003 04:07:57 -0400
Received: from il-tlv-mbdg2.comverse.com (localhost.localdomain [127.0.0.1])
	by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id h5Q87I804365
	for <lemonade@ietf.org>; Thu, 26 Jun 2003 11:07:19 +0300
X-Authentication-Warning: il-tlv-smtpout2.icomverse.com: iscan owned process doing -bs
Received: by il-tlv-mbdg2.comverse.com with Internet Mail Service (5.5.2655.55)
	id <N15FGQWP>; Thu, 26 Jun 2003 11:07:23 +0300
Message-ID: <7D4344E32B34D511A6500002A560C60204D893EE@IL-TLV-MAIL4>
From: Erev Ari <Ari.Erev@comverse.com>
To: "'lemonade@ietf.org'" <lemonade@ietf.org>
Subject: Re: [lemonade] Agenda for Vienna - SMTP/LMTP MediaSize draft
Date: Thu, 26 Jun 2003 11:07:23 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C33BB9.F8CB9B2C"
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C33BB9.F8CB9B2C
Content-Type: text/plain;
	charset="windows-1255"


At 8:47 AM -0400 6/25/03, Glenn Parsons wrote:

>  If you would like some time on the agenda in Vienna, please let 
> myself and Eric know.

I have asked Glenn to discuss making the I-D I published on SMTP
per-media/context size a working group document.  
It relates to the "6.2.2. Quota by Context Enforcement" section in the
Lemonade Goals draft.  

The draft is: 
http://www.ietf.org/internet-drafts/draft-shveidel-mediasize-02.txt

Regards,
Ari Erev



------_=_NextPart_001_01C33BB9.F8CB9B2C
Content-Type: text/html;
	charset="windows-1255"
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=3Dwindows-1255">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>Re: [lemonade] Agenda for Vienna - SMTP/LMTP MediaSize =
draft</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">At 8:47 AM -0400 6/25/03, Glenn =
Parsons wrote:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp; If you would like some time =
on the agenda in Vienna, please let </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; myself and Eric know.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I have asked Glenn to discuss making =
the I-D I published on SMTP per-media/context size a working group =
document.&nbsp; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">It relates to the &quot;6.2.2. Quota =
by Context Enforcement&quot; section in the Lemonade Goals draft.&nbsp; =
</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The draft is: </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-shveidel-mediasize-02.=
txt" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-shveidel-med=
iasize-02.txt</A></FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Regards,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Ari Erev</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C33BB9.F8CB9B2C--

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



From exim@www1.ietf.org  Thu Jun 26 22:45:44 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01801
	for <lemonade-archive@odin.ietf.org>; Thu, 26 Jun 2003 22:45:43 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5R2jHp06303
	for lemonade-archive@odin.ietf.org; Thu, 26 Jun 2003 22:45:17 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VjEj-0001da-Iu
	for lemonade-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 22:45:17 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01796
	for <lemonade-web-archive@ietf.org>; Thu, 26 Jun 2003 22:45:13 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19VjEg-0000Q6-00
	for lemonade-web-archive@ietf.org; Thu, 26 Jun 2003 22:45:14 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19VjEa-0000Pv-00
	for lemonade-web-archive@ietf.org; Thu, 26 Jun 2003 22:45:08 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VjEU-0001YF-EP; Thu, 26 Jun 2003 22:45:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VjDs-0001Wx-1e
	for lemonade@optimus.ietf.org; Thu, 26 Jun 2003 22:44:39 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01762
	for <lemonade@ietf.org>; Thu, 26 Jun 2003 22:43:15 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19VjCm-0000PI-00
	for lemonade@ietf.org; Thu, 26 Jun 2003 22:43:16 -0400
Received: from mxout5.cac.washington.edu ([140.142.32.135])
	by ietf-mx with esmtp (Exim 4.12)
	id 19VjCb-0000P1-00
	for lemonade@ietf.org; Thu, 26 Jun 2003 22:43:05 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9])
	by mxout5.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h5R2gckI021514;
	Thu, 26 Jun 2003 19:42:38 -0700
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
	(authenticated bits=0)
	by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h5R2gcXa023877
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Thu, 26 Jun 2003 19:42:38 -0700
Date: Thu, 26 Jun 2003 19:42:39 -0700 (Pacific Daylight Time)
From: Mark Crispin <MRC@CAC.Washington.EDU>
To: hardie@qualcomm.com
cc: lemonade@ietf.org, Chris.Newman@sun.com
Subject: Re: [lemonade] I-D ACTION:draft-crispin-imap-urlauth-00.txt
In-Reply-To: <p06001215bb19421dd4b0@[205.214.163.81]>
Message-ID: <Pine.WNT.4.60.0306261925200.1896@Tomobiki-Cho.CAC.Washington.EDU>
References: <200306201133.HAA25935@ietf.org> <Pine.NXT.4.56.0306200520380.477@Ikkoku-Kan.Panda.COM>
 <p06001210bb18f3f05c4c@[205.214.163.81]> <Pine.WNT.4.60.0306201440160.4048@Tomobiki-Cho.CAC.Washington.EDU>
 <p06001215bb19421dd4b0@[205.214.163.81]>
Organization: Networks & Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: lemonade-admin@ietf.org
Errors-To: lemonade-admin@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
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>

On Fri, 20 Jun 2003 hardie@qualcomm.com wrote:
> If the language below ("I think you need either
> to demonstrate..." etc.) sounded directive, I apologize.  I did not
> mean to short circuit the working group's discussion of the topic.
> I meant to participate in it.

No need to apologize!  I know that I handwaved over certain security
points, and I very much appreciate your help.

> I guess I'm fuzzy on the use case for "anyone including anonymous can use it".
> The case I thought we were focused on is "forward without download",
> which seems to require that the access to the message being forwarded be
> restricted to the user (or her agent) in whose message store the message sits.
> (I suppose it might also be seen as access by the user to whom the
> message has been
> forwarded, but that's not the viewpoint I think we've started from.)  Can you
> elaborate on when the anonymous access would be used?

OK, there is one obvious limitation in IMAP, and that is that access
control is at the user (and with ACL the mailbox) level.  There is no way
to grant access to a particular message in a mailbox without granting
access to the entire mailbox.

Consider, for example, an archive in which the archive itself is not
public (because there may perhaps be some sensitive information in it) but
individual messages may be.

This has always been a "background" type of issue -- annoying but never
really important enough to come to the forefront.  The attraction is to
kill two birds with one stone -- both "forward without download" and the
"grant anonymous access at the message level".

> If I understand you, then, this authentication would not be the user's
> normal IMAP credentials (and I can certainly see why you would not want
> to share those with the submit server or embed them in a URI).  They
> would be user specific, however, and possibly restricted in some other
> way?

Well...yes and no.

It is a fairly straightforward extension to URLAUTH to modify it so that
it only gives authorization to a particular authenticated userid.  For
example, "Mark gives Risa a URL to access a message in one of Mark's
private (and protected mailboxes) that only userid Risa can use."

The submit server could have its own submit-server userid.

More complex schemes are possible, but I believe in the KISS principle.

> I assume from
> the text below that they would not be server-based (since you say
> server-based ACLs
> are not the focus of your effort.)  Could a user theoretically present them
> through any submit server, then?

I'm not sure that I understand what you're asking here.  The
authentication would be server based, or at least in the particular
strawman that I'm thinking about.

> >In the case of submit, there is a presumption (which perhaps should be
> >stated in security considerations) that SSL/TLS-protected channels should
> >be used to transmit the identifier, along with short-term expiration.
> I agree that it should be noted; using TLS does add overhead for both
> traffic and credentials that the group should consider.  As you note
> below, we also need to be sure in the risk assessment that it
> matches the risks in these environments.

OK, I'll keep this in mind.  Chris Newman has made a note of this in his
BURL document.

> >One-shot access limitations seem to me to be a
> >bad idea.
> In the http-based systems where I've seen it, it has been a bad idea.  There
> turn out to be a *lot* of corner cases (just the accept-ranges aspect of it
> make it hard to work through).  I've not thought through the IMAP-specific
> aspects in any detail, but I suspect there would be similar concerns.

Well, since we're loudly agreeing in our dislike of one-shot here, let's
say we won't do one-shot!  :-)

> I certainly agree that if an attacker has compromised the IMAP session,
> she may well have trapped the credentials which will allow full
> access to the IMAP
> store (or may be able to inject requests for access in other ways).

This is also a weakness of submit-via-IMAP.

> I would also note,
> though, that there are some cases where the attacker  may be listening to
> the traffic between the user and the submit server in order to get
> access to the data accessed by the credential-bearing URI.

Hence the implication that TLS protection will be used throughout; and
again, submit-through-IMAP has the same issues and probably the same ("use
TLS") solution.

> Sorry if my response seemed an over-reaction to a -00 draft.   The burn
> marks from previous attempts at embedding credentials in URIs still
> throb occasionally, though, and I wanted to respond quickly.
> If that came across as heavy-handed, I apologize.

Once again, no offense taken.  If I can leverage from your experience, and
avoid making the same mistakes, so much the better.

I'm getting some very clear ideas of what needs to be in the -01.  Thanks!

-- 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