From lemonade-bounces@ietf.org Tue May 02 15:50:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb0t0-0003qA-CE; Tue, 02 May 2006 15:50:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb0sl-0003mJ-AQ; Tue, 02 May 2006 15:50:03 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb0sj-0003mS-V4; Tue, 02 May 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k42Jo1vP007020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 May 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fb0sj-0005QR-FU; Tue, 02 May 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 02 May 2006 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-deployments-01.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. Title : Deployment Considerations for lemonade-compliant Mobile Email Author(s) : R. Gellens Filename : draft-ietf-lemonade-deployments-01.txt Pages : 10 Date : 2006-5-2 This document discusses deployment issues and describes requirements for successful deployment of mobile email which are implicit in the IETF lemonade documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-deployments-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-deployments-01.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-deployments-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-5-2134654.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-deployments-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-deployments-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-2134654.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --NextPart-- From lemonade-bounces@ietf.org Wed May 03 07:04:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbF98-0000ol-2v; Wed, 03 May 2006 07:03:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbF96-0000og-KU for lemonade@ietf.org; Wed, 03 May 2006 07:03:52 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbF96-0001ws-7x for lemonade@ietf.org; Wed, 03 May 2006 07:03:52 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k43B3o017434 for ; Wed, 3 May 2006 07:03:50 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 3 May 2006 07:03:46 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D09DFD5C0@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LEMONADE interim Thread-Index: AcZuoT+2FYOFjGv0TC+oA16g9Mp0kA== From: "Glenn Parsons" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Subject: [lemonade] LEMONADE interim X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0976561779==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============0976561779== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66EA1.4186CB44" This is a multi-part message in MIME format. ------_=_NextPart_001_01C66EA1.4186CB44 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Folks, As we threatened in Dallas ... :-) There will be a LEMONADE interim at the end of this month. The initial details are below -- additional details will be available on the supplemental website. Cheers, Glenn. The LEMONADE WG will hold an Interim Meeting. When: May 31 & June 1, 2006 Where: Marriott Hotel 100 Kent St, Ottawa, ON Canada http://marriott.com/property/propertypage/YOWMC There will be full Internet access available and an audio bridge will be available. We will be on jabber as well as iChat (or other video/desktop sharing as required) We will start at 9:00am on Wednesday, and will finish by 3pm on Thursday. The closest airport is YOW (about 10 km away) and there are numerous hotels nearby -- there is a Nortel rate (CDN $130) at the Marriott Note that the goal of this interim is to finalize the deliverables of the WG. Proposed Agenda items: - finalize profile-bis content and related drafts, specifically draft-ietf-lemonade-convert draft-ietf-lemonade-search-within draft-ietf-lemonade-notifications draft-ietf-lemonade-vfolder draft-ietf-lemonade-imap-sieve draft-ietf-lemonade-compress draft-ietf-lemonade-reconnect draft-ietf-lemonade-rfc2192bis draft-ietf-lemonade-profile-bis draft-ietf-lemonade-firewall-binding draft-ietf-lemonade-deployments draft-ietf-lemonade-futuredelivery draft-ietf-lemonade-streaming-convert - review OMA liaison Please let the chairs know if you intend on attending this meeting and if there is anything specific you would like added to the agenda. Glenn Parsons & Eric Burger LEMONADE WG co-chairs ------_=_NextPart_001_01C66EA1.4186CB44 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable LEMONADE interim

Folks,

As we threatened in Dallas … = :-)

There will be a LEMONADE interim at the = end of this month.  The initial details are below -- additional = details will be available on the supplemental website.

Cheers,
Glenn.



The LEMONADE WG will hold an Interim = Meeting.
When: May 31 & June 1, 2006
Where: Marriott Hotel
100 Kent St, Ottawa, ON Canada
http://marriott.com/property/propertypage/YOWMC
=
There will be full Internet access = available and an audio bridge will be available.
We will be on jabber as well as iChat (or other video/desktop sharing as = required)
We will start at 9:00am on Wednesday, and will finish by 3pm on = Thursday.
The closest airport is YOW (about 10 km away) and there are
numerous hotels nearby -- there is a Nortel rate (CDN $130) at the = Marriott

Note that the goal of this interim is to finalize the deliverables of = the WG.

Proposed Agenda items:
- finalize profile-bis content and related drafts, specifically

draft-ietf-lemonade-convert
draft-ietf-lemonade-search-within
draft-ietf-lemonade-notifications
draft-ietf-lemonade-vfolder
draft-ietf-lemonade-imap-sieve
draft-ietf-lemonade-compress
draft-ietf-lemonade-reconnect
draft-ietf-lemonade-rfc2192bis
draft-ietf-lemonade-profile-bis
draft-ietf-lemonade-firewall-binding
draft-ietf-lemonade-deployments
draft-ietf-lemonade-futuredelivery
draft-ietf-lemonade-streaming-convert

- review OMA liaison

Please let the chairs know if you intend on attending this meeting = and
if there is anything specific you would like added to the agenda.

Glenn Parsons & Eric Burger
LEMONADE WG co-chairs


------_=_NextPart_001_01C66EA1.4186CB44-- --===============0976561779== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --===============0976561779==-- From lemonade-bounces@ietf.org Wed May 03 07:08:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbFE1-0002l8-1C; Wed, 03 May 2006 07:08:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbFDz-0002iA-II for lemonade@ietf.org; Wed, 03 May 2006 07:08:55 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbFDz-00024H-78 for lemonade@ietf.org; Wed, 03 May 2006 07:08:55 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k43B3x114367 for ; Wed, 3 May 2006 07:03:59 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [lemonade] Document Status Date: Wed, 3 May 2006 07:08:47 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D09DFD5CC@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Document Status Thread-Index: AcZpqaYIhC5sHKocQTykOCgIf0Y+EQE9iKsQ From: "Glenn Parsons" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0783358957==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============0783358957== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66EA1.F407E5EC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C66EA1.F407E5EC Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Folks, =20 It's May 3rd and we have only one new draft... =20 The chairs would like the focus of the interim to be resolving issues (and not reading new drafts). So to make that effective we need drafts to review a few weeks before the meeting. =20 Cheers, Glenn. ________________________________ From: Parsons, Glenn [CAR:1A14:EXCH]=20 Sent: Thursday, April 27, 2006 12:20 AM To: lemonade@ietf.org Subject: [lemonade] Document Status Folks,=20 We need some revised documents. At the IETF 65 meeting we had set a date of April 3rd to get new drafts... so far we have none. We really need to have some documents by May 3rd to identify outstanding issues so that we can resolve them at the proposed May 31 interim meeting in Ottawa. As a reminder, we are expecting revised drafts on the following...=20 draft-ietf-lemonade-convert =20 draft-ietf-lemonade-search-within=20 draft-ietf-lemonade-notifications =20 draft-ietf-lemonade-vfolder =20 draft-ietf-lemonade-imap-sieve=20 draft-ietf-lemonade-compress =20 draft-ietf-lemonade-reconnect =20 draft-ietf-lemonade-rfc2192bis=20 draft-ietf-lemonade-profile-bis =20 draft-ietf-lemonade-firewall-binding =20 draft-ietf-lemonade-deployments =20 draft-ietf-lemonade-futuredelivery=20 And a new draft on...=20 Streaming conversion=20 Cheers,=20 Glenn.=20 ------_=_NextPart_001_01C66EA1.F407E5EC Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Document Status
Folks,
 
It's May 3rd and we have only one new=20 draft...
 
The chairs would like the focus of the = interim to be=20 resolving issues (and not reading new drafts).  So to make that = effective=20 we need drafts to review a few weeks before the = meeting.
 
Cheers,
Glenn.

From: Parsons, Glenn [CAR:1A14:EXCH] =
Sent: Thursday, April 27, 2006 12:20 AM
To:=20 lemonade@ietf.org
Subject: [lemonade] Document=20 Status

Folks,

We need some revised documents.  At = the IETF 65=20 meeting we had set a date of April 3rd to get new drafts… so far = we have=20 none.

We really need to have some documents by = May 3rd to=20 identify outstanding issues so that we can resolve them at the proposed = May 31=20 interim meeting in Ottawa.

As a reminder, we are expecting revised = drafts on the=20 following...

 draft-ietf-lemonade-convert =20
 draft-ietf-lemonade-search-within=20
 draft-ietf-lemonade-notifications =20
 draft-ietf-lemonade-vfolder  =20
 draft-ietf-lemonade-imap-sieve=20
 draft-ietf-lemonade-compress    =20
 draft-ietf-lemonade-reconnect =20
 draft-ietf-lemonade-rfc2192bis=20
 draft-ietf-lemonade-profile-bis =20
 draft-ietf-lemonade-firewall-binding  =
 draft-ietf-lemonade-deployments  =
 draft-ietf-lemonade-futuredelivery =

And a new draft on...

  Streaming conversion

Cheers,
Glenn.


------_=_NextPart_001_01C66EA1.F407E5EC-- --===============0783358957== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --===============0783358957==-- From lemonade-bounces@ietf.org Fri May 12 08:06:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeWOt-0000iO-26; Fri, 12 May 2006 08:05:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeWOr-0000iG-Eq for lemonade@ietf.org; Fri, 12 May 2006 08:05:41 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeWOo-0007DC-WD for lemonade@ietf.org; Fri, 12 May 2006 08:05:41 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4CC5Z0C009637 for ; Fri, 12 May 2006 15:05:38 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 May 2006 15:04:54 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 May 2006 15:04:54 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 12 May 2006 15:04:47 +0300 Message-ID: <0FA975F2D8295A448BE3ADC1612446570C5FAB@esebe199.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Client identification Thread-Index: AcZ1vEN9Ved9dqyKQiCsIR65+kUbnA== From: To: X-OriginalArrivalTime: 12 May 2006 12:04:54.0092 (UTC) FILETIME=[478640C0:01C675BC] X-Spam-Score: 0.2 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Subject: [lemonade] Client identification X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1247484504==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============1247484504== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C675BC.47A238F3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C675BC.47A238F3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I would need some help. How are the clients identified? I would need this information to figure out how to store client-specific = preferences - like outband notification address - to be able to tell the = server to notify my laptop client via WLAN (address UDP x.x.x.x:nn), and = my mobile phone via SMS (address +1234567890, port yy). Thank You. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan.ordogh@nokia.com Phone: +358 50 386 0566 ------_=_NextPart_001_01C675BC.47A238F3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Client identification

Hi all,
I would need some = help.
How are the clients = identified?

I would need this information = to figure out how to store client-specific preferences - like outband = notification address - to be able to tell the server to notify my laptop = client via WLAN (address UDP x.x.x.x:nn), and my mobile phone via SMS = (address +1234567890, port yy).

Thank You.



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


------_=_NextPart_001_01C675BC.47A238F3-- --===============1247484504== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --===============1247484504==-- From lemonade-bounces@ietf.org Fri May 12 15:50:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FedeP-0005Ud-TU; Fri, 12 May 2006 15:50:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FedeF-0005My-9i; Fri, 12 May 2006 15:50:03 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FedeD-0006TM-Sd; Fri, 12 May 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k4CJo1XO015970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 12 May 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FedeD-00015V-FC; Fri, 12 May 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 12 May 2006 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-deployments-02.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. Title : Deployment Considerations for lemonade-compliant Mobile Email Author(s) : R. Gellens Filename : draft-ietf-lemonade-deployments-02.txt Pages : 11 Date : 2006-5-12 This document discusses deployment issues and describes requirements for successful deployment of mobile email which are implicit in the IETF lemonade documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-deployments-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-deployments-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-deployments-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-5-12123248.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-deployments-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-deployments-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-12123248.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --NextPart-- From lemonade-bounces@ietf.org Mon May 15 05:35:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfZTc-0003vI-Dz; Mon, 15 May 2006 05:34:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfZTb-0003vD-UD for lemonade@ietf.org; Mon, 15 May 2006 05:34:55 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfZTb-00009n-CT for lemonade@ietf.org; Mon, 15 May 2006 05:34:55 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4F9Yptj003607 for ; Mon, 15 May 2006 12:34:54 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 May 2006 12:34:54 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 May 2006 12:34:53 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-deployments-02.txt Date: Mon, 15 May 2006 12:34:48 +0300 Message-ID: <0FA975F2D8295A448BE3ADC1612446570C60E0@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] I-D ACTION:draft-ietf-lemonade-deployments-02.txt Thread-Index: AcZ1/aNdRRQ2QvMITJCKxRey42blQgB/GCYg From: To: X-OriginalArrivalTime: 15 May 2006 09:34:53.0998 (UTC) FILETIME=[D24A24E0:01C67802] X-Spam-Score: 0.2 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi all, A few comments/questions: Section 4.2 "due to handoffs"-> is it referring to handovers? Section 6. "Firewalls exist to block traffic," can we rephrase this to = "Firewalls exist to block undesired traffic," (unidentified, unsafe, = restricted) or something like that? Section 6. "There is a body of best practices based on long experience = in this area." Should there be a reference here? (Section 8 does not = mention any.) Section 6. "One or more firewalls might exist..." Should this paragraph = mention something about outband notifications (that those should be = allowed too, otherwise it's useless)? Section 6. "Application proxies, which are a not uncommon mechanism, are = discussed in [PROXIES]." double negative, "are a not uncommon = mechanism"-> "are a common mechanism"? Section 7. " NAT boxes which are deployed between client and server = systems SHOULD be configured to have extremely long connection = lifetimes. Unlimited lifetimes are RECOMMENDED." I am no NAT expert, so = I do not know how NAT sessions are reserved or anything. Is it possible = to set the connection lifetime per session or only globally? I mean, if = there is email traffic, You want it high, otherwise You might want to = keep it low(er). If it can be set only globally and there are many email = sessions there will be several NAT sessions, each NAT session taking up = memory - and probably not all routers are equipped with a big memory so = I guess after a while they will run out. When they do, something will = happen - and this can be abuse as a DoS attack. So do we really want to = recommend long/permanent NAT sessions? (Or, should we mention the DoS = attack in Section 8?) Section 10. I want to be listed here ;-) Section 11. [PROFILE] Will draft-ietf-lemonade-deployments-xx.txt be = part of bis, or will it reference it? I mean - this reference is in the = normative section - if it's going to be part of the bis, then there is = no need to have the normative reference here, right? [SUBMISSION] is in = the informative section as well. Section 12. [FIREWALLS] Excuse my ignorance, but what is the concept for = "normative" and "informative" reference in IETF? Isn't is so that the = "normative" references contain all "MUST" documents? Section 6 mentiones = this reference as a MUST. Section 12. [HOST-REQUIREMENTS] Section 4 mentioned this as a "SHOULD" - = should it be in the normative section (same as the comment above). Generic questions: Will a new port number be standardized for email traffic/outband = notification? (Where the server can contact the client with = notification, or where the client can contact the server [to aid section = 6.1 of the draft]?) This draft is a very good read (both content and readability-wise). Thank You. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan.ordogh@nokia.com Phone: +358 50 386 0566 -----Original Message----- From: ext lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org]=20 Sent: 12 May, 2006 22:50 To: i-d-announce@ietf.org Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-deployments-02.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Enhancements to Internet email to = support diverse service environments Working Group of the IETF. Title : Deployment Considerations for lemonade-compliant Mobile Email Author(s) : R. Gellens Filename : draft-ietf-lemonade-deployments-02.txt Pages : 11 Date : 2006-5-12 =09 This document discusses deployment issues and describes requirements for = successful deployment of mobile email which are implicit in the IETF = lemonade documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-deployments-02.tx= t To remove yourself from the I-D Announcement list, send a message to = i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After = logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-deployments-02.txt". A list of Internet-Drafts directories can be found in = http://www.ietf.org/shadow.html or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-deployments-02.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon May 15 08:18:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffc1M-0003W7-Gp; Mon, 15 May 2006 08:17:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfbzL-000398-EU for lemonade@ietf.org; Mon, 15 May 2006 08:15:51 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffbpb-0006NX-T4 for lemonade@ietf.org; Mon, 15 May 2006 08:05:48 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.34) id 1FfbpQ-0004lK-Er; Mon, 15 May 2006 12:05:36 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id BC345498007; Mon, 15 May 2006 13:06:15 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15240-08; Mon, 15 May 2006 13:06:06 +0100 (BST) Received: from JOHN (unknown [IPv6:2001:4bd0:2029:0:5957:8449:97ee:3108]) by turner.dave.cridland.net (Postfix) with ESMTP id 2590E498006; Mon, 15 May 2006 13:06:04 +0100 (BST) Date: Mon, 15 May 2006 13:05:02 +0100 Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-deployments-02.txt References: <0FA975F2D8295A448BE3ADC1612446570C60E0@esebe199.NOE.Nokia.com> In-Reply-To: <0FA975F2D8295A448BE3ADC1612446570C60E0@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Message-Id: <2516.1147694703.200000@JOHN> From: Dave Cridland To: "Zoltan.Ordogh@nokia.com" Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Rutherford-IP: [217.155.137.60] X-Spam-Score: 0.5 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Some meta-comments, and comments of my own you've reminded me to bring up on the list: On Mon May 15 10:34:48 2006, Zoltan.Ordogh@nokia.com wrote: > Section 6. "Firewalls exist to block traffic," can we rephrase this > to "Firewalls exist to block undesired traffic," (unidentified, > unsafe, restricted) or something like that? > > I think the way it's phrased is fine - firewalls do exist to block traffic, they're deployed to block undesired traffic, but they quite often block desired traffic in practise, which is largely what this section is concerned with. > Section 6. "There is a body of best practices based on long > experience in this area." Should there be a reference here? > (Section 8 does not mention any.) > > Section 8 carries no references, but does discuss best practises. I can't immediately think of any RFCs that could be referenced here. > Section 6. "One or more firewalls might exist..." Should this > paragraph mention something about outband notifications (that those > should be allowed too, otherwise it's useless)? > > Well, this is problematic, because we have no outbound notification methods right now within Lemonade. > Section 6. "Application proxies, which are a not uncommon > mechanism, are discussed in [PROXIES]." double negative, "are a not > uncommon mechanism"-> "are a common mechanism"? > > It's a native speaker thing, I'm afraid - to my (en_GB) ears, "not uncommon" suggests less deployment than "common" (which could suggest almost ubiquitous deployment), as well as suggesting there's no desire on the part of the author for it to become common. (Also seen in phrases such as "I wouldn't disagree", which indicates a reluctance to actually agree.) The readable nature of the document does tend to increase the number of idiomatic phrases, perhaps you might want to go through and highlight any more you find? > Section 7. " NAT boxes which are deployed between client and server > systems SHOULD be configured to have extremely long connection > lifetimes. Unlimited lifetimes are RECOMMENDED." I am no NAT > expert, so I do not know how NAT sessions are reserved or anything. > Is it possible to set the connection lifetime per session or only > globally? I mean, if there is email traffic, You want it high, > otherwise You might want to keep it low(er). If it can be set only > globally and there are many email sessions there will be several > NAT sessions, each NAT session taking up memory - and probably not > all routers are equipped with a big memory so I guess after a while > they will run out. When they do, something will happen - and this > can be abuse as a DoS attack. So do we really want to recommend > long/permanent NAT sessions? (Or, should we mention the DoS attack > in Section 8?) > > Memory is not a serious issue for the kinds of NAT deployment we're looking at here. For mobile networks, a Linux box with a few G of RAM will have perfectly good performance, and quite enough memory. (Apparently each connection is 350 bytes of non-swappable kernel memory, so with 0.5G of RAM you can support over a million connections, so with a 64-bit memory address and a reasonable load of RAM, that should keep everyone happy). > Section 11. [PROFILE] Will draft-ietf-lemonade-deployments-xx.txt > be part of bis, or will it reference it? I mean - this reference is > in the normative section - if it's going to be part of the bis, > then there is no need to have the normative reference here, right? > [SUBMISSION] is in the informative section as well. > > I mentioned to Randy that I wasn't clear it should be referencing bis. Nothing in this document refers to anything beyond the original profile. Normally, I'd be keen to see the latest version of a document be referenced, but in this case, I personally see the different profile versions as different "levels of support", and I suspect that we'll see deployments of Lemonade services earlier than Lemonade Bis, and those early deployments will need this advice most - I'd be wary of making it appear that this advice applies to Lemonade Bis, not Lemonade. In addition, referencing Profile means the document should be available as an RFC much sooner. Profile Bis can quite easily reference this, of course, that's another matter entirely. > Generic questions: > Will a new port number be standardized for email traffic/outband > notification? (Where the server can contact the client with > notification, or where the client can contact the server [to aid > section 6.1 of the draft]?) > > If it needs a port number, it would be standardized, as a general rule. (Not everything does need a port number, for instance it could use SRV records, but that's probably not a good idea in this case). > This draft is a very good read (both content and readability-wise). I agree, it's enjoyable enough to read that it will get read. > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-lemonade-deployments-02.txt Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon May 15 15:50:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffj5D-0005bg-Nh; Mon, 15 May 2006 15:50:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffj4u-0005YM-He; Mon, 15 May 2006 15:50:04 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffj4u-00053c-FD; Mon, 15 May 2006 15:50:04 -0400 Received: from pine.neustar.com ([209.173.57.70]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ffj4s-00034j-W5; Mon, 15 May 2006 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k4FJo2XO002324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 May 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Ffj4s-0007Vn-J6; Mon, 15 May 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 15 May 2006 15:50:02 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-rfc2192bis-02.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. Title : IMAP URL Scheme Author(s) : A. Melnikov, et al. Filename : draft-ietf-lemonade-rfc2192bis-02.txt Pages : 27 Date : 2006-5-15 IMAP [IMAP4] is a rich protocol for accessing remote message stores. It provides an ideal mechanism for accessing public mail- ing list archives as well as private and shared message stores. This document defines a URL scheme for referencing objects on an IMAP server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-rfc2192bis-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-rfc2192bis-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-rfc2192bis-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-5-15112833.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-rfc2192bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-rfc2192bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-15112833.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --NextPart-- From lemonade-bounces@ietf.org Mon May 15 15:50:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffj5b-0006R4-Lm; Mon, 15 May 2006 15:50:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffj4z-0005Zj-Lh; Mon, 15 May 2006 15:50:09 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffj4z-00054x-Jb; Mon, 15 May 2006 15:50:09 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=willow.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ffj4t-00034m-5u; Mon, 15 May 2006 15:50:09 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k4FJo21I002872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 May 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Ffj4s-0007Vi-II; Mon, 15 May 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 15 May 2006 15:50:02 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-06.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. Title : IMAP4 Extensions for Quick Reconnect Author(s) : C. Wilson, A. Melnikov Filename : draft-ietf-lemonade-reconnect-06.txt Pages : 23 Date : 2006-5-15 This document defines a quick reconnect IMAP4 extension, which gives a mobile client the ability to resume a previously abandoned session, without the need to perform a full synchronization sequence. The goal is to minimize the amount of data transfered at login after a dropped connection. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-reconnect-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-reconnect-06.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-reconnect-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-5-15112709.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-reconnect-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-reconnect-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-15112709.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --NextPart-- From lemonade-bounces@ietf.org Tue May 16 04:01:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfuUH-0002tI-T6; Tue, 16 May 2006 04:01:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfuUG-0002tD-OY for lemonade@ietf.org; Tue, 16 May 2006 04:01:00 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfuUG-000739-4R for lemonade@ietf.org; Tue, 16 May 2006 04:01:00 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4G80s5P012277; Tue, 16 May 2006 11:00:58 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 11:00:36 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 11:00:36 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-deployments-02.txt Date: Tue, 16 May 2006 11:00:29 +0300 Message-ID: <0FA975F2D8295A448BE3ADC1612446570C6230@esebe199.NOE.Nokia.com> In-Reply-To: <2516.1147694703.200000@JOHN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] I-D ACTION:draft-ietf-lemonade-deployments-02.txt Thread-Index: AcZ4GClfvByZ3aajTR2+258II9gL4QApLYMA From: To: X-OriginalArrivalTime: 16 May 2006 08:00:36.0604 (UTC) FILETIME=[D0A213C0:01C678BE] X-Spam-Score: 0.2 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Dave, thank You. I addded a few comments below some of yours. (Marked with "[Z=D6r]"). Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan.ordogh@nokia.com Phone: +358 50 386 0566 -----Original Message----- From: ext Dave Cridland [mailto:dave@cridland.net]=20 Sent: 15 May, 2006 15:05 To: Ordogh Zoltan (Nokia-TP-MSW/Tampere) Cc: Enhancements to Internet email to support diverse service = enivronments Subject: RE: [lemonade] I-D = ACTION:draft-ietf-lemonade-deployments-02.txt=20 Some meta-comments, and comments of my own you've reminded me to bring = up on the list: On Mon May 15 10:34:48 2006, Zoltan.Ordogh@nokia.com wrote: > Section 6. "Firewalls exist to block traffic," can we rephrase this to = > "Firewalls exist to block undesired traffic," (unidentified, unsafe,=20 > restricted) or something like that? >=20 >=20 I think the way it's phrased is fine - firewalls do exist to block = traffic, they're deployed to block undesired traffic, but they quite = often block desired traffic in practise, which is largely what this = section is concerned with. > Section 6. "There is a body of best practices based on long experience = > in this area." Should there be a reference here? > (Section 8 does not mention any.) >=20 >=20 Section 8 carries no references, but does discuss best practises. I = can't immediately think of any RFCs that could be referenced here. > Section 6. "One or more firewalls might exist..." Should this=20 > paragraph mention something about outband notifications (that those=20 > should be allowed too, otherwise it's useless)? >=20 >=20 Well, this is problematic, because we have no outbound notification=20 methods right now within Lemonade. [Z=D6r] You surely have UDP. It's not the content LEMONADE needs to = worry about - it's the possibility to deliver it whatever it is. If = firewalls block them, it renders mobile email pretty much useless = (remember that there might be software firewalls on the clients, too = which are not necessarily in the control of the user). > Section 6. "Application proxies, which are a not uncommon=20 > mechanism, are discussed in [PROXIES]." double negative, "are a not=20 > uncommon mechanism"-> "are a common mechanism"? >=20 >=20 It's a native speaker thing, I'm afraid - to my (en_GB) ears, "not=20 uncommon" suggests less deployment than "common" (which could suggest=20 almost ubiquitous deployment), as well as suggesting there's no=20 desire on the part of the author for it to become common. (Also seen=20 in phrases such as "I wouldn't disagree", which indicates a=20 reluctance to actually agree.) The readable nature of the document=20 does tend to increase the number of idiomatic phrases, perhaps you=20 might want to go through and highlight any more you find? [Z=D6r] I read through it, but did not find any others. I am not a = native English, so if it sounds just fine for Your ears then let's = forget it. > Section 7. " NAT boxes which are deployed between client and server=20 > systems SHOULD be configured to have extremely long connection=20 > lifetimes. Unlimited lifetimes are RECOMMENDED." I am no NAT=20 > expert, so I do not know how NAT sessions are reserved or anything.=20 > Is it possible to set the connection lifetime per session or only=20 > globally? I mean, if there is email traffic, You want it high,=20 > otherwise You might want to keep it low(er). If it can be set only=20 > globally and there are many email sessions there will be several=20 > NAT sessions, each NAT session taking up memory - and probably not=20 > all routers are equipped with a big memory so I guess after a while=20 > they will run out. When they do, something will happen - and this=20 > can be abuse as a DoS attack. So do we really want to recommend=20 > long/permanent NAT sessions? (Or, should we mention the DoS attack=20 > in Section 8?) >=20 >=20 Memory is not a serious issue for the kinds of NAT deployment we're=20 looking at here. For mobile networks, a Linux box with a few G of RAM=20 will have perfectly good performance, and quite enough memory.=20 (Apparently each connection is 350 bytes of non-swappable kernel=20 memory, so with 0.5G of RAM you can support over a million=20 connections, so with a 64-bit memory address and a reasonable load of=20 RAM, that should keep everyone happy). [Z=D6r] :-) Oh, that's nice to hear. > Section 11. [PROFILE] Will draft-ietf-lemonade-deployments-xx.txt=20 > be part of bis, or will it reference it? I mean - this reference is=20 > in the normative section - if it's going to be part of the bis,=20 > then there is no need to have the normative reference here, right?=20 > [SUBMISSION] is in the informative section as well. >=20 >=20 I mentioned to Randy that I wasn't clear it should be referencing=20 bis. Nothing in this document refers to anything beyond the original=20 profile. Normally, I'd be keen to see the latest version of a document be=20 referenced, but in this case, I personally see the different profile=20 versions as different "levels of support", and I suspect that we'll=20 see deployments of Lemonade services earlier than Lemonade Bis, and=20 those early deployments will need this advice most - I'd be wary of=20 making it appear that this advice applies to Lemonade Bis, not=20 Lemonade. In addition, referencing Profile means the document should be=20 available as an RFC much sooner. Profile Bis can quite easily reference this, of course, that's=20 another matter entirely. > Generic questions: > Will a new port number be standardized for email traffic/outband=20 > notification? (Where the server can contact the client with=20 > notification, or where the client can contact the server [to aid=20 > section 6.1 of the draft]?) >=20 >=20 If it needs a port number, it would be standardized, as a general=20 rule. (Not everything does need a port number, for instance it could=20 use SRV records, but that's probably not a good idea in this case). [Z=D6r] If there was no standardized port number for email traffic = (especially outband notifications), then all these communications would = be blocked - another dead technology invented: not going to work outside = of the provider's domain (there goes roaming and mobile email). > This draft is a very good read (both content and readability-wise). I agree, it's enjoyable enough to read that it will get read. > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-lemonade-deployments-02.tx= t Dave. --=20 You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue May 16 04:36:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffv2K-00053R-Vb; Tue, 16 May 2006 04:36:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffv2J-00053M-E5 for lemonade@ietf.org; Tue, 16 May 2006 04:36:11 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffv2H-0000UV-TF for lemonade@ietf.org; Tue, 16 May 2006 04:36:11 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4G8a5DK003953 for ; Tue, 16 May 2006 11:36:09 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 11:36:03 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 11:36:04 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-06.txt / Questions Date: Tue, 16 May 2006 11:35:57 +0300 Message-ID: <0FA975F2D8295A448BE3ADC1612446570C6246@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-06.txt / Questions Thread-Index: AcZ4WQfy5tCo5hYOSsqL8ZS0vCwvUAAaIclA From: To: X-OriginalArrivalTime: 16 May 2006 08:36:04.0114 (UTC) FILETIME=[C4BA5720:01C678C3] X-Spam-Score: 0.2 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi all, I have a couple of questions on this draft. There is nothing about expiration timeout in the draft, so I assume each = client and server implementation is free to choose any setting. 1. Let's say the client setting is 5 minutes, the server setting is 3 = minutes. How will the client know what is the current setting on the = server (to be in sync)? Is there any way to query it? 2. This assumes that the client can query the server setting (1). So the = client noticed that the server setting is 3 minutes. The client wants to = make it longer because 5 minutes seems to be a better value. How can the = client change the setting on the server? 3. This assumes that the client can request changing the server setting = (2). The client requested changing the setting, but the server has a = good reason to force a shorter expiration timeout (perhaps to save some = resources). In any case, how can the server not to accept the new = setting? (To tell the client that: "fine, I got Your message, but let's = just keep my value for now"). 4. This assumes that the whole thing is supported and working (1,2,3). = Now, how would it work in a multi-client enviroment? We would like to to = make sure that each client has its own expiration timeout - and that one = client changing the setting does not have any impact on another client. = The expiration timeout might very well be different for a fixed terminal = and a mobile one. The mobile terminal evalutes its environment = continouosly and needs to make adjustsments according to its estimation = of network conditions. Any thoughts on this? Thank You. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan.ordogh@nokia.com Phone: +358 50 386 0566 -----Original Message----- From: ext lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org]=20 Sent: 15 May, 2006 22:50 To: i-d-announce@ietf.org Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-06.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Enhancements to Internet email to = support diverse service environments Working Group of the IETF. Title : IMAP4 Extensions for Quick Reconnect Author(s) : C. Wilson, A. Melnikov Filename : draft-ietf-lemonade-reconnect-06.txt Pages : 23 Date : 2006-5-15 =09 This document defines a quick reconnect IMAP4 extension, which gives a = mobile client the ability to resume a previously abandoned session, = without the need to perform a full synchronization sequence. The goal = is to minimize the amount of data transfered at login after a dropped = connection. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-reconnect-06.txt To remove yourself from the I-D Announcement list, send a message to = i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After = logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-reconnect-06.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-reconnect-06.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue May 16 05:25:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffvnz-0001b2-VI; Tue, 16 May 2006 05:25:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffvnx-0001ax-WB for lemonade@ietf.org; Tue, 16 May 2006 05:25:26 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffvnx-0002Z9-Ui for lemonade@ietf.org; Tue, 16 May 2006 05:25:25 -0400 Received: from hideout.bfs.openwave.com ([193.129.95.230] helo=bfs-isa-in.openwave.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ffvnw-000345-J0 for lemonade@ietf.org; Tue, 16 May 2006 05:25:25 -0400 Received: from bfs-exch-prd1.myopwv.com ([10.20.249.141]) by bfs-isa-in.openwave.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 10:24:53 +0100 Received: from bfs-fe-prd1.myopwv.com ([10.20.249.143]) by bfs-exch-prd1.myopwv.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 10:24:53 +0100 Received: from [127.0.0.1] ([10.16.81.129]) by bfs-fe-prd1.myopwv.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 10:24:52 +0100 Mime-Version: 1.0 (Apple Message framework v749.3) Content-Transfer-Encoding: 7bit Message-Id: <08291C23-36E0-4713-84E0-3E3A2FE18A51@openwave.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: lemonade@ietf.org From: Neil Cook Date: Tue, 16 May 2006 10:25:21 +0100 X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 16 May 2006 09:24:53.0070 (UTC) FILETIME=[96858EE0:01C678CA] X-Spam-Score: -2.6 (--) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [lemonade] IMAP URLFETCH and binary X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org All, I'm working on a draft for streaming multimedia to IMAP clients, which is simply a profile for using the existing IMAP URLAUTH draft and the Netann streaming media service (RFC4240). As part of this, the IMAP client will send URLAUTH URL to the media server, which the media server will then retrieve using the URLFETCH command. The problem is that the URLFETCH command doesn't seem to have a way to fetch content without a content-transfer-encoding, and RFC4240 doesn't have a mechanism for passing the c-t-e. So my question is, can you fetch binary content (c.f. BINARY command) using URLFETCH? If the answer is, "you can't", then what do people think about adding a URLBINARY command to the URLAUTH draft? -- Neil Cook Openwave neil.cook@openwave.com _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue May 16 09:38:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffzk9-0007Z3-CZ; Tue, 16 May 2006 09:37:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffzk8-0007Yy-S8 for lemonade@ietf.org; Tue, 16 May 2006 09:37:44 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffzk6-0006p8-Ez for lemonade@ietf.org; Tue, 16 May 2006 09:37:44 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 6AFBC4AC30; Tue, 16 May 2006 15:37:22 +0200 (CEST) Message-Id: Date: Tue, 16 May 2006 15:41:29 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] IMAP URLFETCH and binary References: <08291C23-36E0-4713-84E0-3E3A2FE18A51@openwave.com> In-Reply-To: <08291C23-36E0-4713-84E0-3E3A2FE18A51@openwave.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I always assumed that I'd get binary content. Don't I? After all, if a web browser issues a GET for the URL, It expects the result to be real HTML, not an encoded document containing mangled links like this: Openwave Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue May 16 09:43:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffzph-0001D4-Pp; Tue, 16 May 2006 09:43:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffzpg-0001Cu-Ca for lemonade@ietf.org; Tue, 16 May 2006 09:43:28 -0400 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffzpf-00079n-1t for lemonade@ietf.org; Tue, 16 May 2006 09:43:28 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.30) id 1FfzpT-0005x1-Jf; Tue, 16 May 2006 13:43:15 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id DE3D2498007; Tue, 16 May 2006 14:44:05 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25372-09; Tue, 16 May 2006 14:43:57 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 21A2A498006; Tue, 16 May 2006 14:43:57 +0100 (BST) Date: Tue, 16 May 2006 14:43:06 +0100 Subject: Re: [lemonade] IMAP URLFETCH and binary References: <08291C23-36E0-4713-84E0-3E3A2FE18A51@openwave.com> In-Reply-To: MIME-Version: 1.0 Message-Id: <31303.1147786986.679424@peirce.dave.cridland.net> From: Dave Cridland To: Arnt Gulbrandsen Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Pythagoras-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue May 16 14:41:29 2006, Arnt Gulbrandsen wrote: > I always assumed that I'd get binary content. Don't I? > > No, you get the encoded body section. > After all, if a web browser issues a GET for the URL, It expects > the result to be real HTML, not an encoded document containing > mangled links like this: > wave.com=22>Openwave > > Yes, but URLFETCH is really designed to be a hook for submission servers to aid in assembling the message, so it's really all part of the textual RFC2822 message, rather than content in and of itself. You'd have to do a different extension - a URLBINARY - to get decoded content. Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 17 15:52:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgS4H-0002qh-GM; Wed, 17 May 2006 15:52:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffzzd-0003n7-2j for lemonade@ietf.org; Tue, 16 May 2006 09:53:45 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffzzb-0007W9-L9 for lemonade@ietf.org; Tue, 16 May 2006 09:53:45 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Tue, 16 May 2006 14:53:34 +0100 Message-ID: <4469D959.5090504@isode.com> Date: Tue, 16 May 2006 14:53:29 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave Cridland Subject: Re: [lemonade] IMAP URLFETCH and binary References: <08291C23-36E0-4713-84E0-3E3A2FE18A51@openwave.com> <31303.1147786986.679424@peirce.dave.cridland.net> In-Reply-To: <31303.1147786986.679424@peirce.dave.cridland.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-Mailman-Approved-At: Wed, 17 May 2006 15:52:24 -0400 Cc: to support diverse service enivronments , Arnt Gulbrandsen , Enhancements X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dave Cridland wrote: > On Tue May 16 14:41:29 2006, Arnt Gulbrandsen wrote: > >> I always assumed that I'd get binary content. Don't I? > > No, you get the encoded body section. > >> After all, if a web browser issues a GET for the URL, It expects the >> result to be real HTML, not an encoded document containing mangled >> links like this: >> > wave.com=22>Openwave > > Yes, but URLFETCH is really designed to be a hook for submission > servers to aid in assembling the message, so it's really all part of > the textual RFC2822 message, rather than content in and of itself. > > You'd have to do a different extension - a URLBINARY - to get decoded > content. Or extend IMAP URLs to signal that the fetched content is to be returned as binary. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 17 18:43:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgUja-0000kw-F6; Wed, 17 May 2006 18:43:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgUjY-0000bH-TS for lemonade@ietf.org; Wed, 17 May 2006 18:43:12 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgUjY-000835-K4 for lemonade@ietf.org; Wed, 17 May 2006 18:43:12 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4HMhBJg028466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 17 May 2006 15:43:11 -0700 Received: from [129.46.172.15] (vpn-10-50-16-185.qualcomm.com [10.50.16.185]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4HMh9OX000050; Wed, 17 May 2006 15:43:10 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <0FA975F2D8295A448BE3ADC1612446570C5FAB@esebe199.NOE.Nokia.com> References: <0FA975F2D8295A448BE3ADC1612446570C5FAB@esebe199.NOE.Nokia.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Wed, 17 May 2006 15:39:19 -0700 To: , From: Randall Gellens Subject: Re: [lemonade] Client identification Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 3:04 PM +0300 5/12/06, wrote: > Content-class: urn:content-classes:message > Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C675BC.47A238F3" > > Hi all, > I would need some help. > How are the clients identified? > > I would need this information to figure out how to store > client-specific preferences - like outband notification address - > to be able to tell the server to notify my laptop client via WLAN > (address UDP x.x.x.x:nn), and my mobile phone via SMS (address > +1234567890, port yy). This could be a mail server per-user data item, as you suggest, but it could also be done with Sieve filters. That allows notification preferences to in effect be different for different devices. So a Sieve script could test messages and, depending on which criteria match, send notification to specific addresses. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- In the long-run every Government is the exact symbol of its People, with their wisdom and unwisdom. --Thomas Carlyle, _Past and Present_ _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 17 19:00:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgV09-0008H2-ER; Wed, 17 May 2006 19:00:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgV07-0008Gw-Rv for lemonade@ietf.org; Wed, 17 May 2006 19:00:19 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgV06-0000bC-3n for lemonade@ietf.org; Wed, 17 May 2006 19:00:19 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4HN0G6O019057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 17 May 2006 16:00:17 -0700 Received: from [129.46.172.15] (vpn-10-50-16-185.qualcomm.com [10.50.16.185]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4HN0AmM006035; Wed, 17 May 2006 16:00:15 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <0FA975F2D8295A448BE3ADC1612446570C60E0@esebe199.NOE.Nokia.com> References: <0FA975F2D8295A448BE3ADC1612446570C60E0@esebe199.NOE.Nokia.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Wed, 17 May 2006 15:59:20 -0700 To: , From: Randall Gellens Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-deployments-02.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 12:34 PM +0300 5/15/06, wrote: > Hi all, > A few comments/questions: > > Section 4.2 "due to handoffs"-> is it referring to handovers? The term "handover" is a new one to me. I am used to hearing "handoff" but since I am not familiar with "handover" I can't say if the terms are the same or not. > Section 6. "Firewalls exist to block traffic," can we rephrase this > to "Firewalls exist to block undesired traffic," (unidentified, > unsafe, restricted) or something like that? Firewalls do exist to block traffic. The desired versus undesired distinction gets into the main points of the document. > Section 6. "There is a body of best practices based on long > experience in this area." Should there be a reference here? > (Section 8 does not mention any.) I am not aware of a single, or even small set, of references that would do justice to the topic. The intent of the phrasing is to let readers know that a lot of work has gone on in this area over a long period of time, and that readers should not make simplistic assumptions. > Section 6. "One or more firewalls might exist..." Should this > paragraph mention something about outband notifications (that those > should be allowed too, otherwise it's useless)? I'd be very happy to mention server to client notifications outside of IMAP and submission, but my understanding is that this has not been agreed to yet as an IP-based mechanism. I suppose I could mention RFC 4146, but that seems silly. > > Section 6. "Application proxies, which are a not uncommon > mechanism, are discussed in [PROXIES]." double negative, "are a not > uncommon mechanism"-> "are a common mechanism"? The "not uncommon" expression is used to indicate a prevalence that is between "uncommon" and "common". I could perhaps say "unfortunately becoming more common" if that is more clear. > Section 7. " NAT boxes which are deployed between client and server > systems SHOULD be configured to have extremely long connection > lifetimes. Unlimited lifetimes are RECOMMENDED." I am no NAT > expert, so I do not know how NAT sessions are reserved or anything. > Is it possible to set the connection lifetime per session or only > globally? I mean, if there is email traffic, You want it high, > otherwise You might want to keep it low(er). If it can be set only > globally and there are many email sessions there will be several > NAT sessions, each NAT session taking up memory - and probably not > all routers are equipped with a big memory so I guess after a while > they will run out. When they do, something will happen - and this > can be abuse as a DoS attack. So do we really want to recommend > long/permanent NAT sessions? (Or, should we mention the DoS attack > in Section 8?) If the number of idle sessions becomes large enough to deplete memory, the NAT box will remove the least recently used ones, as the text says. I apologize, but I don't see the problem with the current wording, or the DoS attack (or at least any that the current wording makes more likely). Can you explain the problem as you see it? > Section 10. I want to be listed here ;-) > > Section 11. [PROFILE] Will draft-ietf-lemonade-deployments-xx.txt > be part of bis, or will it reference it? I mean - this reference is > in the normative section - if it's going to be part of the bis, > then there is no need to have the normative reference here, right? > [SUBMISSION] is in the informative section as well. > > Section 12. [FIREWALLS] Excuse my ignorance, but what is the > concept for "normative" and "informative" reference in IETF? Isn't > is so that the "normative" references contain all "MUST" documents? > Section 6 mentiones this reference as a MUST. > > Section 12. [HOST-REQUIREMENTS] Section 4 mentioned this as a > "SHOULD" - should it be in the normative section (same as the > comment above). I can move the references around if need be; thanks for pointing this out. The issue of referencing Profile versus Profile-bis is one that Dave mentioned to me; my response at the time was that I personally don't care at all either way, so if people feel strongly or have specific reasons to go with one or the other, please speak up. > Generic questions: > Will a new port number be standardized for email traffic/outband > notification? (Where the server can contact the client with > notification, or where the client can contact the server [to aid > section 6.1 of the draft]?) If we come up with an IP-based notification service, then a standardized port would make sense. > > This draft is a very good read (both content and readability-wise). Thank you. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- A fail-safe circuit will destroy others. A transistor protected by a fast-acting fuse will protect the fuse by blowing first. After the last of 16 mounting screws has been removed from an access cover, it will be discovered that the wrong access cover has been removed. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 17 19:08:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgV7g-0001K3-N0; Wed, 17 May 2006 19:08:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgV7f-0001Jx-J2 for lemonade@ietf.org; Wed, 17 May 2006 19:08:07 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgV7f-00017Q-8d for lemonade@ietf.org; Wed, 17 May 2006 19:08:07 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4HN83ic020461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 17 May 2006 16:08:04 -0700 Received: from [129.46.172.15] (vpn-10-50-16-185.qualcomm.com [10.50.16.185]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4HN815G008169; Wed, 17 May 2006 16:08:02 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <0FA975F2D8295A448BE3ADC1612446570C6230@esebe199.NOE.Nokia.com> References: <0FA975F2D8295A448BE3ADC1612446570C6230@esebe199.NOE.Nokia.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Wed, 17 May 2006 16:05:55 -0700 To: , From: Randall Gellens Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-deployments-02.txt Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 11:00 AM +0300 5/16/06, wrote: > > Section 6. "One or more firewalls might exist..." Should this >> paragraph mention something about outband notifications (that those >> should be allowed too, otherwise it's useless)? >> >> > Well, this is problematic, because we have no outbound notification > methods right now within Lemonade. > [Z=D6r] You surely have UDP. It's not the content=20 > LEMONADE needs to worry about - it's the=20 > possibility to deliver it whatever it is. If=20 > firewalls block them, it renders mobile email=20 > pretty much useless (remember that there might=20 > be software firewalls on the clients, too which=20 > are not necessarily in the control of the user). UDP is a transport (like TCP). Lemonade does not=20 currently have a specific notification protocol.=20 It could specify the content and format of=20 notifications, a protocol for them, and allowable=20 transports (such as UDP). When it does specify a=20 protocol, a port should be allocated, and this=20 port should be listed in the deployments draft=20 (or an update of it). > > Generic questions: >> Will a new port number be standardized for email traffic/outband >> notification? (Where the server can contact the client with >> notification, or where the client can contact the server [to aid >> section 6.1 of the draft]?) >> >> > If it needs a port number, it would be standardized, as a general > rule. (Not everything does need a port number, for instance it could > use SRV records, but that's probably not a good idea in this case). > [Z=D6r] If there was no standardized port number=20 > for email traffic (especially outband=20 > notifications), then all these communications=20 > would be blocked - another dead technology=20 > invented: not going to work outside of the=20 > provider's domain (there goes roaming and=20 > mobile email). Then let's specify a protocol (and of course=20 port) for server to client notifications outside=20 of IMAP, for example, to be invoked by Sieve=20 scripts. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Some days you feel like Schrodinger's cat. --M. S. Hutchenreuther _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu May 18 03:47:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgdEB-0002kM-Vm; Thu, 18 May 2006 03:47:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgdEA-0002kH-RC for lemonade@ietf.org; Thu, 18 May 2006 03:47:22 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgdE8-00063j-B6 for lemonade@ietf.org; Thu, 18 May 2006 03:47:22 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4I7lJjs020099; Thu, 18 May 2006 10:47:19 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 10:46:42 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 10:46:42 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Client identification Date: Thu, 18 May 2006 10:46:36 +0300 Message-ID: <0FA975F2D8295A448BE3ADC1612446570C6502@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Client identification Thread-Index: AcZ6A3jMS97Y0plqQSqDKyU+qc5rEQASoNQw From: To: , X-OriginalArrivalTime: 18 May 2006 07:46:42.0756 (UTC) FILETIME=[34727840:01C67A4F] X-Spam-Score: 0.2 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Thank You for Your respose Randall. So, what You are saying is that each client could modify the SIEVE = filter which would then instruct the server to notify all clients listed = in the SIEVE script. There is only two problems I see with this: 1. Concurrent updates (one of the updates is prone to be lost because = the latter one will obsolete the first update). 2. We still need to figure out how to identify the clients - a client = will want to update its own preference only, not other client's = preferences. Let me explain. You are using Your mobile phone via GRPS, = and Your notification address is UDP/10.1.1.1:34765 currently. You walk = on the airplane and switch off Your phone. You enjoy Your flight and = walk off the plane to switch the phone back. The question is now that = how can the client identify Your old preference that exists on the = server? The client will be required to track its own addresses? UDP = address depends on the network - far from unique so it's not going to = work even if the client remembers. Thank You. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan.ordogh@nokia.com Phone: +358 50 386 0566 -----Original Message----- From: ext Randall Gellens [mailto:randy@qualcomm.com]=20 Sent: 18 May, 2006 01:39 To: Ordogh Zoltan (Nokia-TP-MSW/Tampere); lemonade@ietf.org Subject: Re: [lemonade] Client identification At 3:04 PM +0300 5/12/06, wrote: > Content-class: urn:content-classes:message > Content-Type: multipart/alternative; > boundary=3D"----_=3D_NextPart_001_01C675BC.47A238F3" > > Hi all, > I would need some help. > How are the clients identified? > > I would need this information to figure out how to store=20 > client-specific preferences - like outband notification address - to=20 > be able to tell the server to notify my laptop client via WLAN=20 > (address UDP x.x.x.x:nn), and my mobile phone via SMS (address > +1234567890, port yy). This could be a mail server per-user data item, as you suggest, but=20 it could also be done with Sieve filters. That allows notification=20 preferences to in effect be different for different devices. So a=20 Sieve script could test messages and, depending on which criteria=20 match, send notification to specific addresses. --=20 Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- In the long-run every Government is the exact symbol of its People, with their wisdom and unwisdom. --Thomas Carlyle, _Past and Present_ _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu May 18 04:30:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgdtp-0002mq-Oo; Thu, 18 May 2006 04:30:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgdto-0002ml-9Z for lemonade@ietf.org; Thu, 18 May 2006 04:30:24 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgdtn-0000Ni-Je for lemonade@ietf.org; Thu, 18 May 2006 04:30:24 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4I8ULUX007613; Thu, 18 May 2006 11:30:22 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 11:30:21 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 11:30:20 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-deployments-02.txt Date: Thu, 18 May 2006 11:30:14 +0300 Message-ID: <0FA975F2D8295A448BE3ADC1612446570C651C@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] I-D ACTION:draft-ietf-lemonade-deployments-02.txt Thread-Index: AcZ6BbT8T8mgboxOQeySrUaCbguF2wASYLWA From: To: , X-OriginalArrivalTime: 18 May 2006 08:30:20.0325 (UTC) FILETIME=[4CA3CD50:01C67A55] X-Spam-Score: 0.2 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Thank You for Your response Randall, I added a few questions/comments to Yours - these are tagged with = [Z=D6r]. -----Original Message----- From: ext Randall Gellens [mailto:randy@qualcomm.com]=20 Sent: 18 May, 2006 01:59 To: Ordogh Zoltan (Nokia-TP-MSW/Tampere); lemonade@ietf.org Subject: RE: [lemonade] I-D = ACTION:draft-ietf-lemonade-deployments-02.txt At 12:34 PM +0300 5/15/06, wrote: > Hi all, > A few comments/questions: > > Section 4.2 "due to handoffs"-> is it referring to handovers? The term "handover" is a new one to me. I am used to hearing "handoff" = but since I am not familiar with "handover" I can't say if the terms are = the same or not. [Z=D6r] :-) Good GSM terminology :-) Handover is the procedure that = takes place when a mobile terminal moves from one BTS to another. I = would guess "handoff" could refer to a failed handover. Not sure though = - this is why I asked. > Section 6. "Firewalls exist to block traffic," can we rephrase this=20 > to "Firewalls exist to block undesired traffic," (unidentified,=20 > unsafe, restricted) or something like that? Firewalls do exist to block traffic. The desired versus undesired = distinction gets into the main points of the document. > Section 6. "There is a body of best practices based on long=20 > experience in this area." Should there be a reference here? > (Section 8 does not mention any.) I am not aware of a single, or even small set, of references that would = do justice to the topic. The intent of the phrasing is to let readers = know that a lot of work has gone on in this area over a long period of = time, and that readers should not make simplistic assumptions. [Z=D6r] I try to read all the specs as a dumb person would do who does = not know anything - the first thing that came to my mind here was. "oh, = good, where can I find those?" > Section 6. "One or more firewalls might exist..." Should this=20 > paragraph mention something about outband notifications (that those=20 > should be allowed too, otherwise it's useless)? I'd be very happy to mention server to client notifications outside of = IMAP and submission, but my understanding is that this has not been = agreed to yet as an IP-based mechanism. I suppose I could mention RFC = 4146, but that seems silly. [Z=D6r] so the first question here is: do we need an IP-based = notification mechanism? I would say yes. > > Section 6. "Application proxies, which are a not uncommon mechanism,=20 > are discussed in [PROXIES]." double negative, "are a not uncommon=20 > mechanism"-> "are a common mechanism"? The "not uncommon" expression is used to indicate a prevalence that is = between "uncommon" and "common". I could perhaps say "unfortunately = becoming more common" if that is more clear. [Z=D6r] Ah, now I got it. Dave explained somewhat differently. But in = the end I think that this latter one would be a better option. > Section 7. " NAT boxes which are deployed between client and server=20 > systems SHOULD be configured to have extremely long connection=20 > lifetimes. Unlimited lifetimes are RECOMMENDED." I am no NAT expert,=20 > so I do not know how NAT sessions are reserved or anything. > Is it possible to set the connection lifetime per session or only=20 > globally? I mean, if there is email traffic, You want it high,=20 > otherwise You might want to keep it low(er). If it can be set only=20 > globally and there are many email sessions there will be several NAT=20 > sessions, each NAT session taking up memory - and probably not all=20 > routers are equipped with a big memory so I guess after a while they=20 > will run out. When they do, something will happen - and this can be=20 > abuse as a DoS attack. So do we really want to recommend=20 > long/permanent NAT sessions? (Or, should we mention the DoS attack in=20 > Section 8?) If the number of idle sessions becomes large enough to deplete memory, = the NAT box will remove the least recently used ones, as the text says. = I apologize, but I don't see the problem with the current wording, or = the DoS attack (or at least any that the current wording makes more = likely). Can you explain the problem as you see it? [Z=D6r] Dave clarifired this to me - my worry was the "unlimited = lifetime" and the not-so-unlimited number of concurrent NAT sessions; = and that it can be exploited. According to Alexey's explanation it is = not an issue - but I wonder if anyone will come up with the same = questions later - the words "unlimited" and "infinite" are raising a lot = of questions ususally. > Section 11. [PROFILE] Will draft-ietf-lemonade-deployments-xx.txt > be part of bis, or will it reference it? I mean - this reference is in = > the normative section - if it's going to be part of the bis, then=20 > there is no need to have the normative reference here, right? > [SUBMISSION] is in the informative section as well. > > Section 12. [FIREWALLS] Excuse my ignorance, but what is the concept=20 > for "normative" and "informative" reference in IETF? Isn't is so that=20 > the "normative" references contain all "MUST" documents? > Section 6 mentiones this reference as a MUST. > > Section 12. [HOST-REQUIREMENTS] Section 4 mentioned this as a=20 > "SHOULD" - should it be in the normative section (same as the comment=20 > above). I can move the references around if need be; thanks for pointing this = out. [Z=D6r] Before You do first I would like to undestand what qualifies as = a normative and an informative reference. You have a reason why You = wrote it like this - I would like to understand why (so that I can avoid = dumb questions in the future). The issue of referencing Profile versus Profile-bis is one that Dave = mentioned to me; my response at the time was that I personally don't = care at all either way, so if people feel strongly or have specific = reasons to go with one or the other, please speak up. [Z=D6r] I think Profile does not mention this document, while = Profile-bis does. Since Profile-bis does reference this document, does = this document have to refer to Profile-bis as a normative reference? One = could argue (me, hehe) that this document is valid for the plain old = IMAP as well, so why reference Profile(-bis) normatively? Perhaps this = just comes from the fact that I do not yet understand the point behind = normative and informative references in IETF. > Generic questions: > Will a new port number be standardized for email traffic/outband=20 > notification? (Where the server can contact the client with=20 > notification, or where the client can contact the server [to aid=20 > section 6.1 of the draft]?) If we come up with an IP-based notification service, then a standardized = port would make sense. > > This draft is a very good read (both content and readability-wise). Thank you. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- A fail-safe = circuit will destroy others. A transistor protected by a fast-acting = fuse will protect the fuse by blowing first. After the last of 16 = mounting screws has been removed from an access cover, it will be = discovered that the wrong access cover has been removed. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu May 18 20:35:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgsxA-0002s3-Tx; Thu, 18 May 2006 20:34:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgsx9-0002ry-IC for lemonade@ietf.org; Thu, 18 May 2006 20:34:51 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgsx8-0002Yo-4f for lemonade@ietf.org; Thu, 18 May 2006 20:34:51 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4J0YirN024636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 18 May 2006 17:34:45 -0700 Received: from [192.168.1.13] (loud.qualcomm.com [129.46.172.15]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4J0Yggl029056; Thu, 18 May 2006 17:34:43 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <0FA975F2D8295A448BE3ADC1612446570C651C@esebe199.NOE.Nokia.com> References: <0FA975F2D8295A448BE3ADC1612446570C651C@esebe199.NOE.Nokia.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Thu, 18 May 2006 17:31:08 -0700 To: , From: Randall Gellens Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-deployments-02.txt Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 11:30 AM +0300 5/18/06, wrote: > I added a few questions/comments to Yours - these are tagged with [Z=D6r]= =2E Unfortunate that your client doesn't support RFC=20 3676 (format=3Dflowed) and hence doesn't do proper=20 quote identification. > [Z=D6r] :-) Good GSM terminology :-) Handover is=20 > the procedure that takes place when a mobile=20 > terminal moves from one BTS to another. I would=20 > guess "handoff" could refer to a failed=20 > handover. Not sure though - this is why I asked. Handoff, as I understand it, is the same as your=20 explanation of handover. No failure is implied.=20 (There are "hard" versus "soft" handoffs, but=20 that's besides the point.) Wikipidia confirms=20 this: . > > Section 6. "There is a body of best practices based on long >> experience in this area." Should there be a reference here? >> (Section 8 does not mention any.) > > I am not aware of a single, or even small set,=20 > of references that would do justice to the=20 > topic. The intent of the phrasing is to let=20 > readers know that a lot of work has gone on in=20 > this area over a long period of time, and that=20 > readers should not make simplistic assumptions. > [Z=D6r] I try to read all the specs as a dumb=20 > person would do who does not know anything -=20 > the first thing that came to my mind here was.=20 > "oh, good, where can I find those?" I agree it would be nice to have a reference (or=20 two or three). Suggestions welcome. > >> Section 6. "One or more firewalls might exist..." Should this >> paragraph mention something about outband notifications (that those >> should be allowed too, otherwise it's useless)? > > I'd be very happy to mention server to client=20 > notifications outside of IMAP and submission,=20 > but my understanding is that this has not been=20 > agreed to yet as an IP-based mechanism. I=20 > suppose I could mention RFC 4146, but that=20 > seems silly. > [Z=D6r] so the first question here is: do we need=20 > an IP-based notification mechanism? I would say=20 > yes. That's a discussion that is broader in scope than=20 this document. I believe the group is doing some=20 work on notifications. I like Dave's suggestion=20 that the deployments document should reference=20 profile, then it can be updated for profile-bis=20 to include notifications. > > Section 11. [PROFILE] Will draft-ietf-lemonade-deployments-xx.txt >> be part of bis, or will it reference it? I mean - this reference is in >> the normative section - if it's going to be part of the bis, then >> there is no need to have the normative reference here, right? >> [SUBMISSION] is in the informative section as well. >> >> Section 12. [FIREWALLS] Excuse my ignorance, but what is the concept >> for "normative" and "informative" reference in IETF? Isn't is so that >> the "normative" references contain all "MUST" documents? >> Section 6 mentiones this reference as a MUST. >> >> Section 12. [HOST-REQUIREMENTS] Section 4 mentioned this as a >> "SHOULD" - should it be in the normative section (same as the comment >> above). > > I can move the references around if need be; thanks for pointing this out= =2E > [Z=D6r] Before You do first I would like to=20 > undestand what qualifies as a normative and an=20 > informative reference. You have a reason why=20 > You wrote it like this - I would like to=20 > understand why (so that I can avoid dumb=20 > questions in the future). Normative references are required in order to=20 understand or implement a document. Informative=20 ones add information but are not essential to=20 understanding or implementation. > The issue of referencing Profile versus=20 > Profile-bis is one that Dave mentioned to me;=20 > my response at the time was that I personally=20 > don't care at all either way, so if people feel=20 > strongly or have specific reasons to go with=20 > one or the other, please speak up. > [Z=D6r] I think Profile does not mention this=20 > document, while Profile-bis does. Since=20 > Profile-bis does reference this document, does=20 > this document have to refer to Profile-bis as a=20 > normative reference? One could argue (me, hehe)=20 > that this document is valid for the plain old=20 > IMAP as well, so why reference Profile(-bis)=20 > normatively? Perhaps this just comes from the=20 > fact that I do not yet understand the point=20 > behind normative and informative references in=20 > IETF. Profile is only a normative reference because the=20 document is aimed at deployments of it. This is=20 an area where the normative or informative choice=20 is not black and white, I think. You make a good=20 point that the deployments document could apply=20 to non-lemonade IMAP and submission, although the=20 document does require that the submission server=20 be able to contact the IMAP server, which is not=20 the case in non-lemonade situations. It would be=20 possible to reword this to avoid making profile=20 normative, but I don't see any benefit to doing=20 that. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Why is it that we rejoice at a birth and grieve at a funeral? It is because we are not the person involved. --Mark Twain _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri May 19 11:26:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh6rm-0005eE-Eq; Fri, 19 May 2006 11:26:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh6rk-0005e8-Ve for lemonade@ietf.org; Fri, 19 May 2006 11:26:12 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh6rj-0007gp-MG for lemonade@ietf.org; Fri, 19 May 2006 11:26:12 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.34) id 1Fh6rY-0002ho-Be; Fri, 19 May 2006 15:26:00 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 99C77498007; Fri, 19 May 2006 16:27:21 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25964-01; Fri, 19 May 2006 16:27:11 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 48C4F498006; Fri, 19 May 2006 16:27:11 +0100 (BST) Date: Fri, 19 May 2006 16:25:48 +0100 Subject: Re: [lemonade] binary? References: In-Reply-To: MIME-Version: 1.0 Message-Id: <12468.1148052349.728857@peirce.dave.cridland.net> From: Dave Cridland To: Randall Gellens Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Rutherford-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Sat Apr 22 00:39:07 2006, Randall Gellens wrote: > What did we decide about BINARY? > > Sorry for the silence, I noticed this one when going through looking for any issues or resolutions for Profile bis. > I recall some discussions on issues/difficulties with the fetch > part (especially encrypted content), and some separate ones on the > append part that might require an annotatemore element to identify > mailboxes that can or cannot support it. But I'm not sure where we > left things. I do recall that binary fetch was shown to be a > bigger win than compression. There was also interaction with CATENATE and LITERAL+. I believe Lyndon Nerenberg has a complete list of issues, including those that I summarised for the list some time ago, but there's no new draft as yet. For now, I've essentially put IMAP BINARY as a MUST into my working copy of Profile Bis, and required that BINARY append "works" for any mailbox. Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri May 19 12:01:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh7Q3-0000he-Rd; Fri, 19 May 2006 12:01:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh7Q2-0000hZ-Jc for lemonade@ietf.org; Fri, 19 May 2006 12:01:38 -0400 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh7Q1-0000ok-AQ for lemonade@ietf.org; Fri, 19 May 2006 12:01:38 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1Fh7Pv-0005Q4-FJ for lemonade@ietf.org; Fri, 19 May 2006 16:01:31 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 990AC498007 for ; Fri, 19 May 2006 17:02:52 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26886-04 for ; Fri, 19 May 2006 17:02:44 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id F06E1498006 for ; Fri, 19 May 2006 17:02:43 +0100 (BST) Date: Fri, 19 May 2006 17:01:21 +0100 MIME-Version: 1.0 Message-Id: <12468.1148054482.209830@peirce.dave.cridland.net> From: Dave Cridland To: Enhancements to Internet email to support diverse service enivronments Content-Type: text/plain; charset="iso-8859-1"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net Content-Transfer-Encoding: quoted-printable X-Originating-Heisenberg-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [lemonade] Notifications X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I have to confess to a certain amount of bewilderment regarding=20 notifications, which I really ought to have caught earlier. As far as I can tell, we currently have two entirely distinct=20 mechanisms for out of band notifications. In no particular order, we have Barry's imap-seive, which leverages=20 Sieve to provide notifications via potentially any method that Sieve=20 can support, filtering based on any filter that Sieve can support. This is also referenced by St=E9phane's notifications draft, which is=20 essentially taking the provisioning subsystem from P-IMAP. It works=20 by restricting the messages to notify about to those in a predefined=20 view [VFOLDER], and notification methods are defined within it. Both drafts were presented as "agreed" to be mandated by Profile Bis=20 at IETF65, but I can't see how they fit together at all - both seem=20 to aim to cover both what and how to notify. Does anyone have an insight into how this is meant to work? Dave. --=20 You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri May 19 12:38:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh7ze-0004Wa-35; Fri, 19 May 2006 12:38:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh7zc-0004WL-AB for lemonade@ietf.org; Fri, 19 May 2006 12:38:24 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh7za-00036B-RQ for lemonade@ietf.org; Fri, 19 May 2006 12:38:24 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 19CA84AC3A for ; Fri, 19 May 2006 18:38:11 +0200 (CEST) Message-Id: <+wYm1xoKtjBCSuOvkv1OEA.md5@libertango.oryx.com> Date: Fri, 19 May 2006 18:42:33 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Notifications References: <12468.1148054482.209830@peirce.dave.cridland.net> In-Reply-To: <12468.1148054482.209830@peirce.dave.cridland.net> Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dave Cridland writes: > As far as I can tell, we currently have two entirely distinct > mechanisms for out of band notifications. > > In no particular order, we have Barry's imap-seive, which leverages > Sieve to provide notifications via potentially any method that Sieve > can support, filtering based on any filter that Sieve can support. > > This is also referenced by St=E9phane's notifications draft, which is > essentially taking the provisioning subsystem from P-IMAP. It works > by restricting the messages to notify about to those in a predefined > view [VFOLDER], and notification methods are defined within it. Eek. Don't like that. As some of you know, I've implemented something essentially like VFOLDER, except more capable. One of the keys to getting pleasant performance in practice was to avoid per-view work on message injection. Although I don't have concrete experience yet, I suspect that spam filtering also can benefit from doing view updates at SELECT time rather than at injection time. I like the sieve approach much better. Just as capable, and with no nasty O(n)-to-O(m) changes. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri May 19 12:41:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh82m-0005yS-Lg; Fri, 19 May 2006 12:41:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh82k-0005yN-KD for lemonade@ietf.org; Fri, 19 May 2006 12:41:38 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh82j-0003P0-84 for lemonade@ietf.org; Fri, 19 May 2006 12:41:38 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id DE5CE4AC32 for ; Fri, 19 May 2006 18:41:35 +0200 (CEST) Message-Id: Date: Fri, 19 May 2006 18:45:58 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Notifications References: <12468.1148054482.209830@peirce.dave.cridland.net> <+wYm1xoKtjBCSuOvkv1OEA.md5@libertango.oryx.com> In-Reply-To: <+wYm1xoKtjBCSuOvkv1OEA.md5@libertango.oryx.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Arnt Gulbrandsen writes: > I like the sieve approach much better. Just as capable, and with no > nasty O(n)-to-O(m) changes. There is a difference, though. Sieve won't notify as a result of APPEND or COPY. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri May 19 12:42:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh83T-00076a-7Y; Fri, 19 May 2006 12:42:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh83S-00076V-LT for lemonade@ietf.org; Fri, 19 May 2006 12:42:22 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh83S-0003Qh-8L for lemonade@ietf.org; Fri, 19 May 2006 12:42:22 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.34) id 1Fh83R-0000YW-Co for lemonade@ietf.org; Fri, 19 May 2006 16:42:21 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 078BF498007 for ; Fri, 19 May 2006 17:43:43 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27167-04 for ; Fri, 19 May 2006 17:43:38 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 910CF498006 for ; Fri, 19 May 2006 17:43:38 +0100 (BST) Date: Fri, 19 May 2006 17:42:15 +0100 MIME-Version: 1.0 Message-Id: <12468.1148056936.530375@peirce.dave.cridland.net> From: Dave Cridland To: Enhancements to Internet email to support diverse service enivronments Content-Type: text/plain; charset="iso-8859-1"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net Content-Transfer-Encoding: quoted-printable X-Originating-Rutherford-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: [lemonade] Profile extensions "under discussion" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I'm going to unilaterally make some reversible decisions on the list=20 of "Under discussion" extensions presented in IETF65 (St=E9phane's=20 slides, page 5). 1) CLEARIDLE Dropped. I'm addressing the comment that "RFC2177 is vague on the=20 exact semantics [etc]" by including some language that mandates=20 unsolicited FETCH, RECENT, and EXISTS responses are sent to idling=20 clients in a "timely fashion" when changes occur to the mailbox. This=20 is vague, but hopefully encourages implementors to consider internal=20 signalling, or relatively frequent polling. 2) CLEARIDLE+QUICKRECONNECT Dropped. If I recall, this was a resynchronization protocol based=20 around the concept of serial numbered synchronization points. I=20 believe resynchronization of this nature is adequately covered by=20 CONDSTORE and RECONNECT. 3) Sieve notify Suspended: This is notification-related, and I'm ignoring=20 notifications for the purposes of Profile Bis until I actually=20 understand the consensus of the group. 4) "SMTP extensions by Tony Finch" Suspended: I think there was a general consensus that some of these=20 proposals were wanted, but lacked polish. Until they're at least=20 submitted as drafts, I'll leave them out. 5) "Dave's 'headers from envelope' SMTP extension" Dropped: Actually this was Chris's suggestion in response to Tony's=20 envelope-from-headers suggestion, and I merely wrote it up. I believe=20 this would be counter-productive to advance, since there are similar=20 proposals in EAI, I believe. Unfortunately, those are experimental,=20 so we can't mandate them. (Otherwise I probably would). 6) TLS compression / Deflate etc. Included Everything: I don't feel there is any clear consensus on=20 compression. My working copy currently has a section on compression=20 in IMAP which includes two alternate paragraphs for LZIP and=20 COMPRESS=3DDEFLATE. 7) XENCRYPTED Dropped: The uncomfortable shifting in chairs came across even over=20 Jabber, but I generally got the feeling that XENCRYPTED was=20 considered by a substantial majority to be outright dangerous, and/or=20 self-defeating. At least until our security advisor finishes the=20 review of the mechanism, I'll leave it out. 8) Proxy / firewalls Informative: I'll include the document as an informative reference. If people disagree with these decisions, I shall be delighted to=20 await the forming of consensus and document it accordingly. :-) Dave. --=20 You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri May 19 12:46:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh87P-0000LV-RS; Fri, 19 May 2006 12:46:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh87P-0000LG-4Q for lemonade@ietf.org; Fri, 19 May 2006 12:46:27 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh87M-0003gh-RG for lemonade@ietf.org; Fri, 19 May 2006 12:46:27 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.34) id 1Fh87M-0003S9-2Y; Fri, 19 May 2006 16:46:24 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id F304D498007; Fri, 19 May 2006 17:47:45 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27144-09; Fri, 19 May 2006 17:47:42 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id F13E2498006; Fri, 19 May 2006 17:47:41 +0100 (BST) Date: Fri, 19 May 2006 17:46:19 +0100 Subject: Re: [lemonade] Notifications References: <12468.1148054482.209830@peirce.dave.cridland.net> <+wYm1xoKtjBCSuOvkv1OEA.md5@libertango.oryx.com> In-Reply-To: MIME-Version: 1.0 Message-Id: <12468.1148057179.901666@peirce.dave.cridland.net> From: Dave Cridland To: Arnt Gulbrandsen Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Rutherford-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Fri May 19 17:45:58 2006, Arnt Gulbrandsen wrote: > Arnt Gulbrandsen writes: >> I like the sieve approach much better. Just as capable, and with >> no nasty O(n)-to-O(m) changes. > > There is a difference, though. Sieve won't notify as a result of > APPEND or COPY. That's what imap-sieve provides, basically - extending Sieve's coverage across the full spectrum of message store events. My fault, I should have included actual filenames to the drafts. Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon May 22 05:11:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fi6RL-0003gT-At; Mon, 22 May 2006 05:11:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fi6RK-0003gO-CZ for lemonade@ietf.org; Mon, 22 May 2006 05:11:02 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fi6RH-0006Dg-SD for lemonade@ietf.org; Mon, 22 May 2006 05:11:02 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4M9AtxU008490; Mon, 22 May 2006 12:10:58 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 May 2006 12:09:52 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 May 2006 12:09:48 +0300 Content-class: urn:content-classes:message Subject: RE: [lemonade] Notifications MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 May 2006 12:09:39 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <0FA975F2D8295A448BE3ADC1612446570C68BB@esebe199.NOE.Nokia.com> In-Reply-To: <12468.1148054482.209830@peirce.dave.cridland.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Notifications Thread-Index: AcZ7XcQKOjc753zzSUGceq5qnGwclgCIHHKQ From: To: , X-OriginalArrivalTime: 22 May 2006 09:09:48.0344 (UTC) FILETIME=[79BDD380:01C67D7F] X-Spam-Score: 0.2 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hello all, My understanding is that SIEVE or VFOLDER are simply filters - they do = not provide notifications, they simply filter which emails need to be = notified to the client (either online or offline) and it something has = passed the filter, the server will send the notification about those = emails that passed the filters. While the client is offline, VFOLDER is not applicable, so only SIEVE = can be used. The client can additionally configure some setting in the server how it = wants to be notified. (Related to this I had a question on how the = clients can be identified to make sure that they update/configure their = own filters/notification methods only - both of these are per-client = settings). So, in the end, when an email has passed the notification filters, the = server will check whether the client is online or offline. If online: no = problem with inband notification; if offline: the server will look up = the client's offline notification settings, and send the notification = accordingly. Is this correct? Now, I have one additional question - about outband notifications. The definition of outband notification is that there is no IMAP session. Now, if someone uses quick reconnect (IMAP session exists, but = connection does not), which notification takes place? Outband or inband? How about VFOLDER? Will the VFOLDER filter be executed when the client = is in "quick disconnected" mode? Thank You. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan.ordogh@nokia.com Phone: +358 50 386 0566 -----Original Message----- From: ext Dave Cridland [mailto:dave@cridland.net]=20 Sent: 19 May, 2006 19:01 To: Enhancements to Internet email to support diverse service = enivronments Subject: [lemonade] Notifications I have to confess to a certain amount of bewilderment regarding = notifications, which I really ought to have caught earlier. As far as I can tell, we currently have two entirely distinct mechanisms = for out of band notifications. In no particular order, we have Barry's imap-seive, which leverages = Sieve to provide notifications via potentially any method that Sieve can = support, filtering based on any filter that Sieve can support. This is also referenced by St=E9phane's notifications draft, which is = essentially taking the provisioning subsystem from P-IMAP. It works by = restricting the messages to notify about to those in a predefined view = [VFOLDER], and notification methods are defined within it. Both drafts were presented as "agreed" to be mandated by Profile Bis at = IETF65, but I can't see how they fit together at all - both seem to aim = to cover both what and how to notify. Does anyone have an insight into how this is meant to work? Dave. --=20 You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon May 22 20:51:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiL7K-0004ru-Ue; Mon, 22 May 2006 20:51:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiL7J-0004nu-Ty for lemonade@ietf.org; Mon, 22 May 2006 20:51:21 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiL7H-00086V-Uy for lemonade@ietf.org; Mon, 22 May 2006 20:51:21 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4N0p7sl025217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 22 May 2006 17:51:08 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4N0p3R1007293; Mon, 22 May 2006 17:51:05 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Mon, 22 May 2006 17:49:03 -0700 To: corby@computer.org, Alexey Melnikov From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: lemonade@ietf.org Subject: [lemonade] Re: draft-ietf-lemonade-reconnect-06.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Excellent work on this draft. I do have a number of comments, but all of them are minor: Section 2.1: The above protocol sequence simply logged the user into the account, selected the INBOX mailbox and downloaded the updated flags for a subset of messages. It is proper to say "subset" since the command used "1:*"? Since it is only one mailbox, I guess it is technically correct, but it seems perhaps misleading. Section 3.1: If the optional session identifier (SID) parameter is not defined, the server will generate a new session as described in Section 3.2. For readability, it might be better to say "used" (or maybe "sent") rather than "defined", since this draft defines the parameter. Section 3.1: Note, that this document doesn't define a minimal required expiration timeout, as members of the Lemonade WG have decided that any such limit would not be adequate for all deployments. Since the document is nearing completion and has been around for a while, it might be good to replace this text with something along the lines of While there is no required minimum expiration timeout, server implementations are encouraged to support as long a time as possible, subject to denial-of-service and related concerns. Section 3.2: This forces the server to create a new session regardless if a previous, valid session is available. If a valid session is already available and a new one can be create, the existing session becomes inactive and can be resumed at a later time. For readability, I'd suggest replacing "forces" with "instructs" (or "requests"). Note there is a typo: "create" instead of "created". It might be good to explain or reword the last sentence above ("If a valid...") to make it more clear what it is saying. Does "valid session" include active sessions for this user as well as inactive ones? It sounds like it is saying that if the client has an active resumable session on the current connection (that is, within the current IMAP session), that it becomes inactive and a new one is created, but this should be made explicit. Section 3.1: In order to limit Deny of Service attacks a server implementation SHOULD have a per-user limit on maximum number of resumable sessions. When this limit is reached the server SHOULD "expire" the oldest inactive(*) session associated with the same user. If no inactive session associated with the same user is available, the server MUST return the tagged NO response to the SID command. Note there is a typo: "Deny of Service" instead of "Denial of Service". I'd suggest removing the quotes around 'expire'. I'd suggest moving the asterisked text to be inside a parenthetical aside: "inactive(*) session" becomes "inactive (not associated with an active TCP connection) session". Section 3.2: If the SID is not recognized (for example, this is the first time the client tries to connect, or the the SID is invalid because it is either not known to the server or has expired) By "first time" you mean the first connection by this client to this server? If so, why would the client use a SID? Perhaps it is trying to use one from an older server, or is just confused? Either way, I'd think it would fall into the "not known" category. So, I'd suggest deleting the "first time" wording. Note there is a typo later in this section: "user has no longer permissions" instead of "user no longer has permissions". Section 3.2: If the provided UIDVALIDITY doesn't match the UIDVALIDITY for the currently selected mailbox, the server MUST send the NEWSID response containing the SID of the resumed session. Maybe add clarifying text to say that the NEWSID response contains the same SID, that is, that the server doesn't abandon the resumed SID and generate a new one? Section 3.2: If the provided UIDVALIDITY matches the one provided by the currently selected mailbox Wording suggestion: change "the one provided by the currently selected" to "that of the selected" Section 3.2: If the list of known UIDs was also provided, the server should only report flag changes and expunges for the provided messages. If the client haven't provided the list of UIDs, the server acts as if the client has specified "1:*". Thus, the client can just service these pending events and need not perform a full resynchronization. Typo: "client haven't provided" instead of "client doesn't provide". Suggest rewording "client can just service these", perhaps to "client can process just these". Section 3.2: If these events could not be cached for some reason, the server MUST return the NEWSID response to signal that the client should perform a state-comparison based synchronization. Maybe change "If these events could not be cached for some reason" to "if the server was unable to cache all events since the MODSEQ and hence is unable to send them to the client"? Section 3.2: Note, that if, while the client was offline, the mailbox was deleted and another mailbox was renamed on top of the selected, the server may do one of the two things: Typos: suggest changing to: If, while the client was offline, the selected mailbox was deleted and another mailbox was renamed to the same name, the server MAY do either: Section 3.2: Example: Resuming an old session in selected state with the INBOX selected, but where the server could not cache all the events since the specified modification sequence. The server sends the NEWSID response, which means that the client should perform full resynchronization. Might be good to note that in this example the server elected to generate a new SID (since as I understand the text the server can also keep the same SID). Section 3.2: Example: Resuming an old session in selected state with the mailbox Drafts selected, but the mailbox was deleted and another one was renamed to become Drafts, while the client was offline. The server chooses to keep the Drafts mailbox open, however it sends the NEWSID response, which means that the client should perform full resynchronization. C: A02 SID Frt-egf-779 6896834 11 20:35 S: * NEWSID Frt-egf-779 S: * FOLDER Drafts S: * OK [UIDVALIDITY 1098183472] Current UIDValidity S: * OK [UIDNEXT 12] Next available UID S: * OK [HIGHESTMODSEQ 54] S: * 7 EXISTS S: * 0 RECENT S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen \*)] Permanent flags S: A02 OK [READ-WRITE] session created Nit: Since the server elected to reuse the same SID, maybe the server should say "session resumed" instead of "session created"? Section 3.2: the current session on logout it SHOULD use "LOGOUT (PRESERVE)" instead of just dropping TCP connection. The former helps to avoid unnecessary resource consumption on the server caused by a TCP disconnect. Typo: add "the" between "dropping" and "TCP". Maybe change "the former" to "this". -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- He who laughs last is probably your boss. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon May 22 20:57:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiLD6-0006jL-6v; Mon, 22 May 2006 20:57:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiLD4-0006jG-MP for lemonade@ietf.org; Mon, 22 May 2006 20:57:18 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiLD1-0008Mo-Qi for lemonade@ietf.org; Mon, 22 May 2006 20:57:18 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4N0vANX025775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 22 May 2006 17:57:11 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4N0v9dl006852; Mon, 22 May 2006 17:57:09 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <0FA975F2D8295A448BE3ADC1612446570C6246@esebe199.NOE.Nokia.com> References: <0FA975F2D8295A448BE3ADC1612446570C6246@esebe199.NOE.Nokia.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Mon, 22 May 2006 17:56:57 -0700 To: , From: Randall Gellens Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-06.txt / Questions Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.6 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 11:35 AM +0300 5/16/06, wrote: > Hi all, > I have a couple of questions on this draft. > > There is nothing about expiration timeout in the draft, so I assume > each client and server implementation is free to choose any setting. Each server implementation is free to choose any value it likes. Clients have no choice in the matter, aside from perhaps having a value beyond which not to even try and resume a session. > > 1. Let's say the client setting is 5 minutes, the server setting is > 3 minutes. How will the client know what is the current setting on > the server (to be in sync)? Is there any way to query it? > 2. This assumes that the client can query the server setting (1). > So the client noticed that the server setting is 3 minutes. The > client wants to make it longer because 5 minutes seems to be a > better value. How can the client change the setting on the server? > 3. This assumes that the client can request changing the server > setting (2). The client requested changing the setting, but the > server has a good reason to force a shorter expiration timeout > (perhaps to save some resources). In any case, how can the server > not to accept the new setting? (To tell the client that: "fine, I > got Your message, but let's just keep my value for now"). > 4. This assumes that the whole thing is supported and working > (1,2,3). Now, how would it work in a multi-client enviroment? We > would like to to make sure that each client has its own expiration > timeout - and that one client changing the setting does not have > any impact on another client. The expiration timeout might very > well be different for a fixed terminal and a mobile one. The mobile > terminal evalutes its environment continouosly and needs to make > adjustsments according to its estimation of network conditions. Most often we pick minimum values for such things, and include a CAPABILITY so the server can announce the value it supports. (For example, see the POP "EXPIRE" capability in RFC 2449.) However, doing so only makes sense if the client should change its behavior based on what the server supports. In the case of session expiration, it probably makes the most sense for clients to always try and resume sessions, and for servers to retain sessions for as long as possible, subject to resource constraints. Likely the session retention period will be a configurable value that an administrator can adjust to constrain the use of resources. Since clients can reasonably always try and resume a session, why have a way to announce values? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- A logician saves the life of a space alien and is rewarded with an offer to answer any question. After a thought he asks: What is the best question to ask and the correct answer to it? After a brief panic the alien consults her computer and says: The best question to ask is the one you just did and the correct answer to it is the one I gave. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue May 23 04:34:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiSLY-00067u-95; Tue, 23 May 2006 04:34:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiSLW-00062M-S3 for lemonade@ietf.org; Tue, 23 May 2006 04:34:30 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiSLU-0002as-B0 for lemonade@ietf.org; Tue, 23 May 2006 04:34:30 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id C5FD94AC30; Tue, 23 May 2006 10:34:18 +0200 (CEST) Message-Id: Date: Tue, 23 May 2006 10:38:58 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Re: draft-ietf-lemonade-reconnect-06.txt References: In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Randall Gellens , Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I noticed one thing. When resuming a session, the server has to tell the mailbox then name of the selected mailbox (which RFC 3501 calls mailbox and this draft sometimes mailbox, sometimes folder). Fine. But some mailboxes have multiple names, or are case insensitive. INBOX is a case in point. So some decisions must be made. Three possibilities: 1. The server MUST report the name the client used in SELECT verbatim. (Example: If the client used "select inbox", the the server MUST report "* FOLDER inbox", not *FOLDER INBOX".) 2. The server sends a FOLDER response to SELECT if the name used in the FOLDER response differs (in case or otherwise) from the name used by the client. (Example: If the client used "select users.alexey" and the server would say "* FOLDER INBOX" during SID processing, then it must send such a response during SELECT processing too.) 3. Add 3-4 pages of mailbox name comparison instructions, so the client can compare the name it used in SELECT and the name the server used in FOLDER. I prefer 2, would live happily with 1, and mention 3 only because that would add yet another dependency on draft-newman-i18n-comparator ;) Hm. Now I noticed one more thing. The draft says mailbox most of the time, but sometimes it says folder. Maybe best to stick to mailbox, as the base IMAP RFC does. And another! There's an underscore in the formal grammar, I'd change that to a hyphen. And a third! No, fourth! The format of international phone numbers are mentioned, but not defined. What's the prefix to use? 00? 8? I suggest adding a few words, such as "e.g. P0044... for a number in the UK". Or better yet, dropping the P thing. Two independent clients running on a dualboot GPRS-connected laptop shouldn't use conflicting P* SIDs. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue May 23 05:12:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiSvT-0008GC-Ex; Tue, 23 May 2006 05:11:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiSvS-0008G7-RS for lemonade@ietf.org; Tue, 23 May 2006 05:11:38 -0400 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiSvO-0004NW-AF for lemonade@ietf.org; Tue, 23 May 2006 05:11:38 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1FiSvN-0003ze-JH; Tue, 23 May 2006 09:11:33 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 8E0AA498007; Tue, 23 May 2006 10:13:31 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32638-06; Tue, 23 May 2006 10:13:21 +0100 (BST) Received: from JOHN (unknown [IPv6:2001:4bd0:2029:0:64c8:7455:c843:eceb]) by turner.dave.cridland.net (Postfix) with ESMTP id BD82E498006; Tue, 23 May 2006 10:13:19 +0100 (BST) Date: Tue, 23 May 2006 10:10:53 +0100 MIME-Version: 1.0 Message-Id: <1632.1148375454.675000@JOHN> From: Dave Cridland To: Alexey Melnikov , Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Heisenberg-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Enhancements to Internet email to support diverse service enivronments Subject: [lemonade] RECONNECT comments: Typos, nits, minor issues. X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Section 2: "The client optionally opens a mailbox and does other things." This is a little vague. Perhaps "The client performs operations as normal, typically selecting a mailbox and accessing messages." or something. Section 2.1: Title "with out" should be "without". "usig Ethereal" => "using Ethereal". Does Ethereal need an informative reference here? The last paragraph appears to be marketing, not technical, information - there's no reason at all the user cannot use the client program while it's resynchronizing. Section 2.2: "Now lets" => "Now let's" "user had dropped connection" => "user had dropped the connection" - although I feel this is blaming the user, when generally it's the network's fault. I'm sure that users don't go around deliberately seeking IMAP connections to drop. EXPUNGED response appears to bear no relation to the UIDs the client provided. Section 3.1: "At minimum the state includes" - I think this list hasnt shrunk as the protocol has changed. The server currently needs to store the selected mailbox, read-only/read-write, RECENT state, and non-persistent IMAP flags. The rest can be ditched, I think, being stored anyway. Section 5.1: Why is there a special sequence for no folder? Why not just send an empty "* FOLDER" response? All clients have to deal with empty responses, for instance for SEARCH responses. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue May 23 09:52:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiXJ9-0001ju-RI; Tue, 23 May 2006 09:52:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiXJ8-0001jp-OX for lemonade@ietf.org; Tue, 23 May 2006 09:52:22 -0400 Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiXJ4-0000JV-EK for lemonade@ietf.org; Tue, 23 May 2006 09:52:22 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout2.cac.washington.edu (8.13.6+UW06.03/8.13.6+UW06.03) with ESMTP id k4NDpxr6032159; Tue, 23 May 2006 06:51:59 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.6+UW06.03/8.13.6+UW06.03) with ESMTP id k4NDppCD015789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 May 2006 06:51:59 -0700 Date: Tue, 23 May 2006 06:51:45 -0700 (PDT) From: Mark Crispin To: Arnt Gulbrandsen Subject: Re: [lemonade] Re: draft-ietf-lemonade-reconnect-06.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: lemonade@ietf.org, Randall Gellens , Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue, 23 May 2006, Arnt Gulbrandsen wrote: > 1. The server MUST report the name the client used in SELECT verbatim. > (Example: If the client used "select inbox", the the server MUST report "* > FOLDER inbox", not *FOLDER INBOX".) What? This specification uses "FOLDER" as a token?!? I strongly object to this. "Folder" is not a word in the IMAP vocabulary, for a reason. Please change this. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 24 06:19:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiqSX-0007M7-3x; Wed, 24 May 2006 06:19:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiqSV-0007Lz-BP for lemonade@ietf.org; Wed, 24 May 2006 06:19:19 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiqST-0006HQ-Pm for lemonade@ietf.org; Wed, 24 May 2006 06:19:19 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Wed, 24 May 2006 11:19:02 +0100 Message-ID: <447432F3.2010407@isode.com> Date: Wed, 24 May 2006 11:18:27 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Mark Crispin Subject: Re: [lemonade] Re: draft-ietf-lemonade-reconnect-06.txt References: In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Mark Crispin wrote: > On Tue, 23 May 2006, Arnt Gulbrandsen wrote: > >> 1. The server MUST report the name the client used in SELECT >> verbatim. (Example: If the client used "select inbox", the the server >> MUST report "* FOLDER inbox", not *FOLDER INBOX".) > > > What? This specification uses "FOLDER" as a token?!? > > I strongly object to this. "Folder" is not a word in the IMAP > vocabulary, for a reason. I am fine with replacing FOLDER with something else. > Please change this. If I remember MAILBOX was used in IMAPv2 or similar. Suggestions? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 24 09:10:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fit8E-0001PN-KZ; Wed, 24 May 2006 09:10:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fit8E-0001PI-7V for lemonade@ietf.org; Wed, 24 May 2006 09:10:34 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fit8C-0006AJ-RE for lemonade@ietf.org; Wed, 24 May 2006 09:10:34 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id C6F904AC1C; Wed, 24 May 2006 15:10:18 +0200 (CEST) Message-Id: Date: Wed, 24 May 2006 15:15:03 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Re: draft-ietf-lemonade-reconnect-06.txt References: <447432F3.2010407@isode.com> In-Reply-To: <447432F3.2010407@isode.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Alexey Melnikov , Mark Crispin X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Alexey Melnikov writes: > If I remember MAILBOX was used in IMAPv2 or similar. Suggestions? Could use "* OK [MAILBOX nstring]". But the conflict with IMAPv2 is not serious - it just means that IMAPv2 servers cannot implement this extension. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 24 09:57:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FitrC-00020r-RP; Wed, 24 May 2006 09:57:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FitrB-00020m-QE for lemonade@ietf.org; Wed, 24 May 2006 09:57:01 -0400 Received: from mxout7.cac.washington.edu ([140.142.32.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fitr7-0008Py-Fh for lemonade@ietf.org; Wed, 24 May 2006 09:57:01 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout7.cac.washington.edu (8.13.6+UW06.03/8.13.6+UW06.03) with ESMTP id k4ODuqGf015648; Wed, 24 May 2006 06:56:52 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.6+UW06.03/8.13.6+UW06.03) with ESMTP id k4ODuj5V029848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 May 2006 06:56:52 -0700 Date: Wed, 24 May 2006 06:56:44 -0700 (PDT) From: Mark Crispin To: Arnt Gulbrandsen Subject: Re: [lemonade] Re: draft-ietf-lemonade-reconnect-06.txt In-Reply-To: Message-ID: References: <447432F3.2010407@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: lemonade@ietf.org, Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed, 24 May 2006, Arnt Gulbrandsen wrote: > Alexey Melnikov writes: >> If I remember MAILBOX was used in IMAPv2 or similar. Suggestions? > Could use "* OK [MAILBOX nstring]". Works for me. > But the conflict with IMAPv2 is not > serious - it just means that IMAPv2 servers cannot implement this extension. IMAP2 uses untagged MAILBOX and not MAILBOX inside an untagged OK. So there is no conflict with IMAP2. I doubt that any IMAP2 server will implement this. The issue is if a client which implements IMAP2 can implement this; and as noted above there is no conflict. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 24 21:45:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj4uR-0004JL-JJ; Wed, 24 May 2006 21:45:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj4uQ-0004J5-5Z for lemonade@ietf.org; Wed, 24 May 2006 21:45:06 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fj4uO-0001X9-QD for lemonade@ietf.org; Wed, 24 May 2006 21:45:06 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4P1j1RA000397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 May 2006 18:45:02 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4P1iwd8001663; Wed, 24 May 2006 18:44:59 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <0FA975F2D8295A448BE3ADC1612446570C68BB@esebe199.NOE.Nokia.com> References: <0FA975F2D8295A448BE3ADC1612446570C68BB@esebe199.NOE.Nokia.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Wed, 24 May 2006 18:44:55 -0700 To: , , From: Randall Gellens Subject: RE: [lemonade] Notifications Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 12:09 PM +0300 5/22/06, wrote: > My understanding is that SIEVE or VFOLDER are simply filters - they > do not provide notifications, they simply filter which emails need > to be notified to the client (either online or offline) and it > something has passed the filter, the server will send the > notification about those emails that passed the filters. Not exactly. Sieve has rules that trigger actions. One of the actions can be to send a notification. > So, in the end, when an email has passed the notification filters, > the server will check whether the client is online or offline. If > online: no problem with inband notification; if offline: the server > will look up the client's offline notification settings, and send > the notification accordingly. I'm not aware that Sieve has any knowledge of the connected state of any client. My understanding is that Sieve rules might say "send notification to address foo", regardless if a client at address foo happens to be connected to the IMAP server at that moment. > INow, if someone uses quick reconnect (IMAP session exists, but > connection does not), which notification takes place? Outband or > inband? > How about VFOLDER? Will the VFOLDER filter be executed when the > client is in "quick disconnected" mode? As I understand it, updates to a virtual folder will be sent to a client with a non-active session (saved using reconnect) when it reconnects and the session becomes active. Sieve may trigger notifications at any time, while the client is connected or not. Is this correct? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- I think we'd get fewer weird bug reports if we stopped selling our software From lemonade-bounces@ietf.org Wed May 24 21:45:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj4uR-0004JL-JJ; Wed, 24 May 2006 21:45:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj4uQ-0004J5-5Z for lemonade@ietf.org; Wed, 24 May 2006 21:45:06 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fj4uO-0001X9-QD for lemonade@ietf.org; Wed, 24 May 2006 21:45:06 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4P1j1RA000397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 May 2006 18:45:02 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4P1iwd8001663; Wed, 24 May 2006 18:44:59 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <0FA975F2D8295A448BE3ADC1612446570C68BB@esebe199.NOE.Nokia.com> References: <0FA975F2D8295A448BE3ADC1612446570C68BB@esebe199.NOE.Nokia.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Wed, 24 May 2006 18:44:55 -0700 To: , , From: Randall Gellens Subject: RE: [lemonade] Notifications Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 12:09 PM +0300 5/22/06, wrote: > My understanding is that SIEVE or VFOLDER are simply filters - they > do not provide notifications, they simply filter which emails need > to be notified to the client (either online or offline) and it > something has passed the filter, the server will send the > notification about those emails that passed the filters. Not exactly. Sieve has rules that trigger actions. One of the actions can be to send a notification. > So, in the end, when an email has passed the notification filters, > the server will check whether the client is online or offline. If > online: no problem with inband notification; if offline: the server > will look up the client's offline notification settings, and send > the notification accordingly. I'm not aware that Sieve has any knowledge of the connected state of any client. My understanding is that Sieve rules might say "send notification to address foo", regardless if a client at address foo happens to be connected to the IMAP server at that moment. > INow, if someone uses quick reconnect (IMAP session exists, but > connection does not), which notification takes place? Outband or > inband? > How about VFOLDER? Will the VFOLDER filter be executed when the > client is in "quick disconnected" mode? As I understand it, updates to a virtual folder will be sent to a client with a non-active session (saved using reconnect) when it reconnects and the session becomes active. Sieve may trigger notifications at any time, while the client is connected or not. Is this correct? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- I think we'd get fewer weird bug reports if we stopped selling our software off planet. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 24 21:45:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj4uN-000492-DK; Wed, 24 May 2006 21:45:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj4uL-00046n-PF for lemonade@ietf.org; Wed, 24 May 2006 21:45:01 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fj4uK-0001Ww-Cg for lemonade@ietf.org; Wed, 24 May 2006 21:45:01 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4P1ivxc013765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 May 2006 18:44:57 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4P1ipmA004377; Wed, 24 May 2006 18:44:56 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <12468.1148056936.530375@peirce.dave.cridland.net> References: <12468.1148056936.530375@peirce.dave.cridland.net> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Wed, 24 May 2006 18:44:49 -0700 To: Dave Cridland , Enhancements to Internet email to support diverse service enivronments From: Randall Gellens Subject: Re: [lemonade] Profile extensions "under discussion" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 5:42 PM +0100 5/19/06, Dave Cridland wrote: > 6) TLS compression / Deflate etc. > > Included Everything: I don't feel there is any clear consensus on > compression. My working copy currently has a section on compression > in IMAP which includes two alternate paragraphs for LZIP and > COMPRESS=DEFLATE. My sense was that Ned and several others made compelling arguments that we should go with something like DEFLATE, and that there was no benefit to per-object client control, since there were no cases where a client capable of decompression would not want it when the server thought an object would benefit from it. Therefore DEFLATE controlled by a single command from the client that says "compress at will". > 8) Proxy / firewalls > > Informative: I'll include the document as an informative reference. Which document? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Police Begin Campaign to Run Down Jaywalkers --Newspaper headline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade off planet. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 24 21:45:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj4uN-000492-DK; Wed, 24 May 2006 21:45:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj4uL-00046n-PF for lemonade@ietf.org; Wed, 24 May 2006 21:45:01 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fj4uK-0001Ww-Cg for lemonade@ietf.org; Wed, 24 May 2006 21:45:01 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4P1ivxc013765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 May 2006 18:44:57 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4P1ipmA004377; Wed, 24 May 2006 18:44:56 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <12468.1148056936.530375@peirce.dave.cridland.net> References: <12468.1148056936.530375@peirce.dave.cridland.net> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Wed, 24 May 2006 18:44:49 -0700 To: Dave Cridland , Enhancements to Internet email to support diverse service enivronments From: Randall Gellens Subject: Re: [lemonade] Profile extensions "under discussion" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 5:42 PM +0100 5/19/06, Dave Cridland wrote: > 6) TLS compression / Deflate etc. > > Included Everything: I don't feel there is any clear consensus on > compression. My working copy currently has a section on compression > in IMAP which includes two alternate paragraphs for LZIP and > COMPRESS=DEFLATE. My sense was that Ned and several others made compelling arguments that we should go with something like DEFLATE, and that there was no benefit to per-object client control, since there were no cases where a client capable of decompression would not want it when the server thought an object would benefit from it. Therefore DEFLATE controlled by a single command from the client that says "compress at will". > 8) Proxy / firewalls > > Informative: I'll include the document as an informative reference. Which document? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Police Begin Campaign to Run Down Jaywalkers --Newspaper headline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 24 21:51:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj515-0000h7-Ap; Wed, 24 May 2006 21:51:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj513-0000gs-V9 for lemonade@ietf.org; Wed, 24 May 2006 21:51:57 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fj512-0001rF-KT for lemonade@ietf.org; Wed, 24 May 2006 21:51:57 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4P1pnqQ000843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 May 2006 18:51:50 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4P1pm47005705; Wed, 24 May 2006 18:51:48 -0700 (PDT) Mime-Version: 1.0 Message-Id: X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Wed, 24 May 2006 18:49:04 -0700 To: corby@computer.org, Alexey Melnikov From: Randall Gellens Subject: [lemonade] Re: draft-ietf-lemonade-reconnect-06.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > I do have a number of comments, but all of them are minor: I also have one higher-level concern: there are a number of places in the document where implementations may do things one way or another (for example, when deciding that a session can't be recovered or that the selected folder has been reincarnated). The server might send this response or that response. I don't feel qualified to say whether this is a problem or not, but I'd like it to be considered. If the group is comfortable with it, I will be happy. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- The brain is a wonderful organ; it starts working the moment you get up in the morning, and does not stop until you get to work. --Robert Frost _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 24 21:54:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj53v-0002JS-2n; Wed, 24 May 2006 21:54:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj53t-0002JN-Hn for lemonade@ietf.org; Wed, 24 May 2006 21:54:53 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fj53s-000211-5J for lemonade@ietf.org; Wed, 24 May 2006 21:54:53 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4P1sljM000982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 May 2006 18:54:48 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4P1skSw007322; Wed, 24 May 2006 18:54:47 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Wed, 24 May 2006 18:53:39 -0700 To: Arnt Gulbrandsen , lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] Re: draft-ietf-lemonade-reconnect-06.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Randall Gellens , Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 10:38 AM +0200 5/23/06, Arnt Gulbrandsen wrote: > And a third! No, fourth! The format of international phone numbers > are mentioned, but not defined. What's the prefix to use? 00? 8? I > suggest adding a few words, such as "e.g. P0044... for a number in > the UK". Or better yet, dropping the P thing. Two independent > clients running on a dualboot GPRS-connected laptop shouldn't use > conflicting P* SIDs. I missed this, but now that I see it, I wonder if perhaps this is left over from an early draft where the client chose the session ID (or did I just imagine that)? The draft says: session-id = string ;; a unique session identifier, ;; implementation specific. If starts from "P" ;; it must be followed by an international ;; phone number. What is the purpose of this text? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- "SF Public Defender: Reasonable Doubt at a Reasonable Price" --Seen on back of jacket worn by P-D staffer, as reported by Herb Cain in Chronicle _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu May 25 03:58:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjAjg-0005sP-EF; Thu, 25 May 2006 03:58:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjAjf-0005sE-3Z for lemonade@ietf.org; Thu, 25 May 2006 03:58:23 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjAjd-0000Au-MY for lemonade@ietf.org; Thu, 25 May 2006 03:58:23 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.34) id 1FjAjc-0007B6-Dl; Thu, 25 May 2006 07:58:20 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 1AE44498007; Thu, 25 May 2006 09:00:39 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19177-05; Thu, 25 May 2006 09:00:33 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id C85E9498006; Thu, 25 May 2006 09:00:33 +0100 (BST) Date: Thu, 25 May 2006 08:58:13 +0100 Subject: Re: [lemonade] Profile extensions "under discussion" References: <12468.1148056936.530375@peirce.dave.cridland.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <8556.1148543894.731843@peirce.dave.cridland.net> From: Dave Cridland To: Randall Gellens Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Rutherford-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu May 25 02:44:49 2006, Randall Gellens wrote: > At 5:42 PM +0100 5/19/06, Dave Cridland wrote: > >> 6) TLS compression / Deflate etc. >> >> Included Everything: I don't feel there is any clear consensus on >> compression. My working copy currently has a section on >> compression in IMAP which includes two alternate paragraphs for >> LZIP and COMPRESS=DEFLATE. > > My sense was that Ned and several others made compelling arguments > that we should go with something like DEFLATE, and that there was > no benefit to per-object client control, since there were no cases > where a client capable of decompression would not want it when the > server thought an object would benefit from it. Therefore DEFLATE > controlled by a single command from the client that says "compress > at will". > > That was my thought too, but the minutes (which include an Action for Pete to summarize the positions to "sharpen consensus"), and the slides from Lemonade Day 2 of IETF65, don't seem to quite indicate that. >> 8) Proxy / firewalls >> >> Informative: I'll include the document as an informative >> reference. > > Which document? Firewall traversal using HTTP. Deployments is currently referenced, too. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu May 25 07:29:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjE1W-000644-Fx; Thu, 25 May 2006 07:29:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjE1V-00063z-RY for lemonade@ietf.org; Thu, 25 May 2006 07:29:01 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjE1U-0007oz-Ew for lemonade@ietf.org; Thu, 25 May 2006 07:29:01 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 516B54AC1B for ; Thu, 25 May 2006 13:28:45 +0200 (CEST) Message-Id: Date: Thu, 25 May 2006 13:28:48 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Re: draft-ietf-lemonade-reconnect-06.txt References: In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Randall Gellens writes: > I don't feel qualified to say whether this is a problem or not, but > I'd like it to be considered. This is similar to RFC 2180. My experience with 2180 says: It's okay to offer two choices, at least if zero won't do. Offering more than two is begging for i14y trouble, particularly when it's difficult for a client author to ascertain whether all the possibilities have been tested. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu May 25 08:29:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjEwv-0003Dp-Nv; Thu, 25 May 2006 08:28:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjEwu-0003Cg-96 for lemonade@ietf.org; Thu, 25 May 2006 08:28:20 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjEhb-0003ib-GN for lemonade@ietf.org; Thu, 25 May 2006 08:12:31 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FjERx-0007G3-Er for lemonade@ietf.org; Thu, 25 May 2006 07:56:22 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 5DE5A4AC1B for ; Thu, 25 May 2006 13:56:19 +0200 (CEST) Message-Id: <12lN1RpSHhMga1lW0Mg0Ow.md5@libertango.oryx.com> Date: Thu, 25 May 2006 13:56:23 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Re: draft-ietf-lemonade-reconnect-06.txt References: In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: -1.3 (-) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Arnt Gulbrandsen writes: > This is similar to RFC 2180. > > My experience with 2180 says: It's okay to offer two choices, at least > if zero won't do. Offering more than two is begging for i14y trouble, > particularly when it's difficult for a client author to ascertain > whether all the possibilities have been tested. (And based on that, I conclude that the reconnect draft is mostly okay, but I'd love to get rid of the P* rule, so there's only one kind of session ID, namely opaque token.) Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu May 25 09:35:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjFz9-0008D1-3B; Thu, 25 May 2006 09:34:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjFz7-0008Cw-OZ for lemonade@ietf.org; Thu, 25 May 2006 09:34:41 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjFio-0008MJ-Cp for lemonade@ietf.org; Thu, 25 May 2006 09:17:50 -0400 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FjFZG-0008CH-2Q for lemonade@ietf.org; Thu, 25 May 2006 09:07:59 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Thu, 25 May 2006 14:07:32 +0100 Message-ID: <4475ABF0.9020205@isode.com> Date: Thu, 25 May 2006 14:06:56 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Randall Gellens Subject: Re: [lemonade] Re: draft-ietf-lemonade-reconnect-06.txt References: In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: -1.7 (-) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Randall Gellens wrote: > At 10:38 AM +0200 5/23/06, Arnt Gulbrandsen wrote: > >> And a third! No, fourth! The format of international phone numbers >> are mentioned, but not defined. What's the prefix to use? 00? 8? I >> suggest adding a few words, such as "e.g. P0044... for a number in >> the UK". Or better yet, dropping the P thing. Two independent clients >> running on a dualboot GPRS-connected laptop shouldn't use conflicting >> P* SIDs. > > I missed this, but now that I see it, I wonder if perhaps this is left > over from an early draft where the client chose the session ID (or did > I just imagine that)? > > The draft says: > > session-id = string ;; a unique session identifier, > ;; implementation specific. If starts from "P" > ;; it must be followed by an international > ;; phone number. > > What is the purpose of this text? I think SIDs were client generated some time ago (I frankly don't remember now). As SIDs are now server generated this is irrelevant. Any objections to removing the comment? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu May 25 09:50:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjGDg-0007rg-MK; Thu, 25 May 2006 09:49:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjGDf-0007rZ-2L for lemonade@ietf.org; Thu, 25 May 2006 09:49:43 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjGDd-0002w8-KX for lemonade@ietf.org; Thu, 25 May 2006 09:49:43 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Thu, 25 May 2006 14:49:22 +0100 Message-ID: <4475B5BE.1010001@isode.com> Date: Thu, 25 May 2006 14:48:46 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Dave Cridland Subject: Re: [lemonade] Profile extensions "under discussion" References: <12468.1148056936.530375@peirce.dave.cridland.net> <8556.1148543894.731843@peirce.dave.cridland.net> In-Reply-To: <8556.1148543894.731843@peirce.dave.cridland.net> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Randall Gellens , support diverse service enivronments , Enhancements X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dave Cridland wrote: > On Thu May 25 02:44:49 2006, Randall Gellens wrote: > >> At 5:42 PM +0100 5/19/06, Dave Cridland wrote: >> >>> 6) TLS compression / Deflate etc. >>> >>> Included Everything: I don't feel there is any clear consensus on >>> compression. My working copy currently has a section on compression >>> in IMAP which includes two alternate paragraphs for LZIP and >>> COMPRESS=DEFLATE. >> >> My sense was that Ned and several others made compelling arguments >> that we should go with something like DEFLATE, and that there was no >> benefit to per-object client control, since there were no cases where >> a client capable of decompression would not want it when the server >> thought an object would benefit from it. Therefore DEFLATE >> controlled by a single command from the client that says "compress at >> will". > > That was my thought too, but the minutes (which include an Action for > Pete to summarize the positions to "sharpen consensus"), and the > slides from Lemonade Day 2 of IETF65, don't seem to quite indicate that. I was sitting in the room in Dallas when the discussion took place and I don't remember any clear consensus on the issue. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu May 25 13:28:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjJcE-0003uK-Qi; Thu, 25 May 2006 13:27:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjJcC-0003mn-VZ for lemonade@ietf.org; Thu, 25 May 2006 13:27:16 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjJcB-0004XF-Kp for lemonade@ietf.org; Thu, 25 May 2006 13:27:16 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4PHRCZO015575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 25 May 2006 10:27:13 -0700 Received: from [129.46.172.15] (vpn-10-50-0-220.qualcomm.com [10.50.0.220]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4PHQx3T002184; Thu, 25 May 2006 10:27:09 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <8556.1148543894.731843@peirce.dave.cridland.net> References: <12468.1148056936.530375@peirce.dave.cridland.net> <8556.1148543894.731843@peirce.dave.cridland.net> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Thu, 25 May 2006 10:26:15 -0700 To: Dave Cridland From: Randall Gellens Subject: Re: [lemonade] Profile extensions "under discussion" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 8:58 AM +0100 5/25/06, Dave Cridland wrote: > >>> 8) Proxy / firewalls >>> >>> Informative: I'll include the document as an informative reference. >> >> Which document? > > Firewall traversal using HTTP. > > Deployments is currently referenced, too. Are we doing both? What is the status of the HTTP one? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Chance that an American cannot name a single right protected by the First Amendment: 1 in 3. (Harper's Index) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu May 25 13:36:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjJkr-0000D1-9D; Thu, 25 May 2006 13:36:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjJkp-0000Bz-DD for lemonade@ietf.org; Thu, 25 May 2006 13:36:11 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjJko-0005d3-1O for lemonade@ietf.org; Thu, 25 May 2006 13:36:11 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4PHa16R003024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 25 May 2006 10:36:02 -0700 Received: from [129.46.172.15] (vpn-10-50-0-220.qualcomm.com [10.50.0.220]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4PHZvhJ005724; Thu, 25 May 2006 10:36:00 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Thu, 25 May 2006 10:34:05 -0700 To: Arnt Gulbrandsen , lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] Re: draft-ietf-lemonade-reconnect-06.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 1:28 PM +0200 5/25/06, Arnt Gulbrandsen wrote: > Randall Gellens writes: >> I don't feel qualified to say whether this is a problem or not, >> but I'd like it to be considered. > > This is similar to RFC 2180. > > My experience with 2180 says: It's okay to offer two choices, at > least if zero won't do. Offering more than two is begging for i14y > trouble, particularly when it's difficult for a client author to > ascertain whether all the possibilities have been tested. Sorry for not being more clear. There are places in the reconnect draft where servers may send one of two or more different sequences to the client. There isn't any guidance as to what considerations there are, if any, for a server choosing which sequence to send. I think clients are expected to respond in the same way regardless of which sequence was sent, but I'm not sure. One of the goals of lemonade is client simplification when this can be reasonably done. So I'm asking if the reconnect draft would be easier on clients if there was less server optionality. It may not make any difference, in which case this is a total non-issue. But I'd like someone to explicitly say so. Also, I think it would be good for the draft to mention some considerations as to which sequence a server generates, just to help readers understand what is going on, if not to offer advice to server implementers. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- The Good Humor man can only be pushed so far --Written on the chalkboard by Bart in the opening of _The_Simpsons_ (TV show) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu May 25 13:36:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjJkr-0000Cw-4v; Thu, 25 May 2006 13:36:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjJkp-0000Bx-CX for lemonade@ietf.org; Thu, 25 May 2006 13:36:11 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjJko-0005d2-1O for lemonade@ietf.org; Thu, 25 May 2006 13:36:11 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4PHa4bW003042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 25 May 2006 10:36:04 -0700 Received: from [129.46.172.15] (vpn-10-50-0-220.qualcomm.com [10.50.0.220]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4PHZvhL005724; Thu, 25 May 2006 10:36:02 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <4475ABF0.9020205@isode.com> References: <4475ABF0.9020205@isode.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Thu, 25 May 2006 10:35:25 -0700 To: Alexey Melnikov From: Randall Gellens Subject: Re: [lemonade] Re: draft-ietf-lemonade-reconnect-06.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 2:06 PM +0100 5/25/06, Alexey Melnikov wrote: >> I missed this, but now that I see it, I wonder if perhaps this is >> left over from an early draft where the client chose the session >> ID (or did I just imagine that)? >> >> The draft says: >> >> session-id = string ;; a unique session identifier, >> ;; implementation specific. If starts from "P" >> ;; it must be followed by an international >> ;; phone number. >> >> What is the purpose of this text? > > I think SIDs were client generated some time ago (I frankly don't > remember now). That's what I thought as well, so I think this was just left over from those days. > As SIDs are now server generated this is irrelevant. Any objections > to removing the comment? Please do. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Good night to spend with family, but avoid arguments with your mate's new lover. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu May 25 13:36:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjJkr-0000D1-9D; Thu, 25 May 2006 13:36:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjJkp-0000Bz-DD for lemonade@ietf.org; Thu, 25 May 2006 13:36:11 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjJko-0005d3-1O for lemonade@ietf.org; Thu, 25 May 2006 13:36:11 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4PHa16R003024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 25 May 2006 10:36:02 -0700 Received: from [129.46.172.15] (vpn-10-50-0-220.qualcomm.com [10.50.0.220]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4PHZvhJ005724; Thu, 25 May 2006 10:36:00 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Thu, 25 May 2006 10:34:05 -0700 To: Arnt Gulbrandsen , lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] Re: draft-ietf-lemonade-reconnect-06.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 1:28 PM +0200 5/25/06, Arnt Gulbrandsen wrote: > Randall Gellens writes: >> I don't feel qualified to say whether this is a problem or not, >> but I'd like it to be considered. > > This is similar to RFC 2180. > > My experience with 2180 says: It's okay to offer two choices, at > least if zero won't do. Offering more than two is begging for i14y > trouble, particularly when it's difficult for a client author to > ascertain whether all the possibilities have been tested. Sorry for not being more clear. There are places in the reconnect draft where servers may send one of two or more different sequences to the client. There isn't any guidance as to what considerations there are, if any, for a server choosing which sequence to send. I think clients are expected to respond in the same way regardless of which sequence was sent, but I'm not sure. One of the goals of lemonade is client simplification when this can be reasonably done. So I'm asking if the reconnect draft would be easier on clients if there was less server optionality. It may not make any difference, in which case this is a total non-issue. But I'd like someone to explicitly say so. Also, I think it would be good for the draft to mention some considerations as to which sequence a server generates, just to help readers understand what is going on, if not to offer advice to server implementers. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- The Good Humor man can only be pushed so far --Written on the chalkboard by Bart in the opening of _The_Simpsons_ (TV show) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu May 25 13:36:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjJkr-0000Cw-4v; Thu, 25 May 2006 13:36:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjJkp-0000Bx-CX for lemonade@ietf.org; Thu, 25 May 2006 13:36:11 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjJko-0005d2-1O for lemonade@ietf.org; Thu, 25 May 2006 13:36:11 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4PHa4bW003042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 25 May 2006 10:36:04 -0700 Received: from [129.46.172.15] (vpn-10-50-0-220.qualcomm.com [10.50.0.220]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4PHZvhL005724; Thu, 25 May 2006 10:36:02 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <4475ABF0.9020205@isode.com> References: <4475ABF0.9020205@isode.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Thu, 25 May 2006 10:35:25 -0700 To: Alexey Melnikov From: Randall Gellens Subject: Re: [lemonade] Re: draft-ietf-lemonade-reconnect-06.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 2:06 PM +0100 5/25/06, Alexey Melnikov wrote: >> I missed this, but now that I see it, I wonder if perhaps this is >> left over from an early draft where the client chose the session >> ID (or did I just imagine that)? >> >> The draft says: >> >> session-id = string ;; a unique session identifier, >> ;; implementation specific. If starts from "P" >> ;; it must be followed by an international >> ;; phone number. >> >> What is the purpose of this text? > > I think SIDs were client generated some time ago (I frankly don't > remember now). That's what I thought as well, so I think this was just left over from those days. > As SIDs are now server generated this is irrelevant. Any objections > to removing the comment? Please do. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Good night to spend with family, but avoid arguments with your mate's new lover. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri May 26 04:26:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjXdW-0003B0-D7; Fri, 26 May 2006 04:25:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjXdU-0003Av-AK for lemonade@ietf.org; Fri, 26 May 2006 04:25:32 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjXdS-0002vK-RP for lemonade@ietf.org; Fri, 26 May 2006 04:25:32 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4Q8PPw5024349; Fri, 26 May 2006 11:25:29 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 May 2006 11:25:26 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 May 2006 11:25:25 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Notifications Date: Fri, 26 May 2006 11:25:16 +0300 Message-ID: <0FA975F2D8295A448BE3ADC1612446570C6DD4@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Notifications Thread-Index: AcZ/nRnAFQgo6HoIRhGosRecYWOUywA/6zMg From: To: , , X-OriginalArrivalTime: 26 May 2006 08:25:25.0946 (UTC) FILETIME=[F07B21A0:01C6809D] X-Spam-Score: 0.2 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org -----Original Message----- From: ext Randall Gellens [mailto:randy@qualcomm.com]=20 Sent: 25 May, 2006 04:45 To: Ordogh Zoltan (Nokia-TP-MSW/Tampere); dave@cridland.net; = lemonade@ietf.org Subject: RE: [lemonade] Notifications At 12:09 PM +0300 5/22/06, wrote: > My understanding is that SIEVE or VFOLDER are simply filters - they=20 > do not provide notifications, they simply filter which emails need to=20 > be notified to the client (either online or offline) and if something=20 > has passed the filter, the server will send the notification about=20 > those emails that passed the filters. Not exactly. Sieve has rules that trigger actions. One of the actions = can be to send a notification. [Z=D6r] SIEVE is responsible for triggering the notification only - not = for sending it, right? > So, in the end, when an email has passed the notification filters,=20 > the server will check whether the client is online or offline. If > online: no problem with inband notification; if offline: the server=20 > will look up the client's offline notification settings, and send the=20 > notification accordingly. I'm not aware that Sieve has any knowledge of the connected state of any = client. My understanding is that Sieve rules might say "send = notification to address foo", regardless if a client at address foo = happens to be connected to the IMAP server at that moment. [Z=D6r] SIEVE triggers the notification only, isn't it? When the server = is told that some mail needs to be notified, the server will check the = online/offline state (not the SIEVE script). However, the SIEVE script = could be also enhanced with built-in variables (like HAS_SESSION, = IS_CONNECTED, etc whatever the syntax of SIEVE is) and then the SIEVE = script could make the decisions as well. Server implementation people = have more experience about which one would be better and why. > Now, if someone uses quick reconnect (IMAP session exists, but=20 > connection does not), which notification takes place? Outband or=20 > inband? > How about VFOLDER? Will the VFOLDER filter be executed when the=20 > client is in "quick disconnected" mode? As I understand it, updates to a virtual folder will be sent to a client = with a non-active session (saved using reconnect) when it reconnects and = the session becomes active. Sieve may trigger notifications at any = time, while the client is connected or not. Is this correct? [Z=D6r] I would say that this depends how we interpret the outband = notification. In any case, it should be described in the draft to make = sure that there are no misinderstandings. Thank You Randall. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan.ordogh@nokia.com Phone: +358 50 386 0566 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri May 26 04:33:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjXks-0006Be-6L; Fri, 26 May 2006 04:33:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjXkr-0006BU-06 for lemonade@ietf.org; Fri, 26 May 2006 04:33:09 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjXkp-0004NO-HP for lemonade@ietf.org; Fri, 26 May 2006 04:33:08 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4Q8X6t8001780; Fri, 26 May 2006 11:33:06 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 May 2006 11:33:05 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 May 2006 11:33:05 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Re: draft-ietf-lemonade-reconnect-06.txt Date: Fri, 26 May 2006 11:32:56 +0300 Message-ID: <0FA975F2D8295A448BE3ADC1612446570C6DD6@esebe199.NOE.Nokia.com> In-Reply-To: <4475ABF0.9020205@isode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Re: draft-ietf-lemonade-reconnect-06.txt Thread-Index: AcaAAFtWa/2RkqcaSwqRowFpf8wiHAAndSPg From: To: , X-OriginalArrivalTime: 26 May 2006 08:33:05.0189 (UTC) FILETIME=[02360D50:01C6809F] X-Spam-Score: 0.2 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org The client is not necessariliy aware of its own MSISDN/MDN (there are = proprietary means to find it out but in common practice it is = intentionally not available for the client for security reasons), so = including it as a MUST would be a bad decision anyway because it = requires the client to have direct access to the mobile network plus = some proprietary implementation (per each operator) to retreive the = MSISDN/MDN. Desktops/laptops will not able to do this - what would those = put there? A random phone number? What if that random phone number = actually exists? So, I support removing the phone number. Thank You. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan.ordogh@nokia.com Phone: +358 50 386 0566 -----Original Message----- From: ext Alexey Melnikov [mailto:alexey.melnikov@isode.com]=20 Sent: 25 May, 2006 16:07 To: Randall Gellens Cc: lemonade@ietf.org Subject: Re: [lemonade] Re: draft-ietf-lemonade-reconnect-06.txt Randall Gellens wrote: > At 10:38 AM +0200 5/23/06, Arnt Gulbrandsen wrote: > >> And a third! No, fourth! The format of international phone numbers=20 >> are mentioned, but not defined. What's the prefix to use? 00? 8? I=20 >> suggest adding a few words, such as "e.g. P0044... for a number in=20 >> the UK". Or better yet, dropping the P thing. Two independent clients = >> running on a dualboot GPRS-connected laptop shouldn't use conflicting >> P* SIDs. > > I missed this, but now that I see it, I wonder if perhaps this is left = > over from an early draft where the client chose the session ID (or did = > I just imagine that)? > > The draft says: > > session-id =3D string ;; a unique session identifier, > ;; implementation specific. If starts from "P" > ;; it must be followed by an international > ;; phone number. > > What is the purpose of this text? I think SIDs were client generated some time ago (I frankly don't = remember now). As SIDs are now server generated this is irrelevant. Any objections to = removing the comment? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri May 26 13:19:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjfy1-00050y-Db; Fri, 26 May 2006 13:19:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjfy0-00050t-K5 for lemonade@ietf.org; Fri, 26 May 2006 13:19:16 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjfxy-00036l-65 for lemonade@ietf.org; Fri, 26 May 2006 13:19:16 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Fri, 26 May 2006 18:18:59 +0100 Message-ID: <4477384A.2090609@isode.com> Date: Fri, 26 May 2006 18:18:02 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave Cridland References: <1632.1148375454.675000@JOHN> In-Reply-To: <1632.1148375454.675000@JOHN> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: service enivronments , Enhancements Subject: [lemonade] Re: RECONNECT comments: Typos, nits, minor issues. X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org [Answering to purely editorial comments.] Dave Cridland wrote: > Section 2: > > "The client optionally opens a mailbox and does other things." This is > a little vague. Perhaps "The client performs operations as normal, > typically selecting a mailbox and accessing messages." or something. Done. > Section 2.1: > > Title "with out" should be "without". Done. > "usig Ethereal" => "using Ethereal". Does Ethereal need an informative > reference here? > > The last paragraph appears to be marketing, not technical, information > - there's no reason at all the user cannot use the client program > while it's resynchronizing. Corby added it, he needs to comment ;-). > * * > Section 2.2: > > "Now lets" => "Now let's" Fixed. > "user had dropped connection" => "user had dropped the connection" - > although I feel this is blaming the user, when generally it's the > network's fault. I'm sure that users don't go around deliberately > seeking IMAP connections to drop. Fixed and I changed "user" to "client". Or do you want a more substantial change? > EXPUNGED response appears to bear no relation to the UIDs the client > provided. Yes. (Cut & paste error) Fixed. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri May 26 13:44:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjgMU-00086z-4R; Fri, 26 May 2006 13:44:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjgMT-00086u-7c for lemonade@ietf.org; Fri, 26 May 2006 13:44:33 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjgMR-00070h-OF for lemonade@ietf.org; Fri, 26 May 2006 13:44:33 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Fri, 26 May 2006 18:44:27 +0100 Message-ID: <44773E40.70304@isode.com> Date: Fri, 26 May 2006 18:43:28 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Arnt Gulbrandsen Subject: Re: [lemonade] Re: draft-ietf-lemonade-reconnect-06.txt References: In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Arnt Gulbrandsen wrote: > I noticed one thing. > > When resuming a session, the server has to tell the mailbox then name > of the selected mailbox (which RFC 3501 calls mailbox and this draft > sometimes mailbox, sometimes folder Changed to "mailbox" everywhere. > ). Fine. > > But some mailboxes have multiple names, or are case insensitive. INBOX > is a case in point. So some decisions must be made. I see your point, we don't want to make clients confused. > Three possibilities: * > * > 1. The server MUST report the name the client used in SELECT verbatim. > (Example: If the client used "select inbox", the the server MUST > report "* FOLDER inbox", not *FOLDER INBOX".) > > 2. The server sends a FOLDER response to SELECT if the name used in > the FOLDER response differs (in case or otherwise) from the name used > by the client. (Example: If the client used "select users.alexey" and > the server would say "* FOLDER INBOX" during SID processing, then it > must send such a response during SELECT processing too.) > > 3. Add 3-4 pages of mailbox name comparison instructions, so the > client can compare the name it used in SELECT and the name the server > used in FOLDER. > > I prefer 2, would live happily with 1, I would prefer 1 and can live with 2, there are similar requirements for IMAP ACL already. For now I've added the following text which reflects # 1: Note that the mailbox name MUST be reported verbatim as originally specified by the client in SELECT/EXAMINE. I.e. before server applies any mailbox name canonicalization (like converting "Inbox" or "users.andrew" to "INBOX"). > and mention 3 only because that would add yet another dependency on > draft-newman-i18n-comparator ;) :-) > Hm. Now I noticed one more thing. The draft says mailbox most of the > time, but sometimes it says folder. Maybe best to stick to mailbox, as > the base IMAP RFC does. > > And another! There's an underscore in the formal grammar, I'd change > that to a hyphen. * > * Fixed. Thanks. > And a third! No, fourth! The format of international phone numbers are > mentioned, but not defined. What's the prefix to use? 00? 8? I suggest > adding a few words, such as "e.g. P0044... for a number in the UK". > Or better yet, dropping the P thing. Two independent clients running > on a dualboot GPRS-connected laptop shouldn't use conflicting P* SIDs. Removed. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri May 26 14:05:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjghA-00035U-Nd; Fri, 26 May 2006 14:05:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjgh9-00035K-LM for lemonade@ietf.org; Fri, 26 May 2006 14:05:55 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjgh7-0001Nx-BM for lemonade@ietf.org; Fri, 26 May 2006 14:05:55 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k4QI5px15649 for ; Fri, 26 May 2006 14:05:51 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 26 May 2006 14:05:48 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D0A4ACDC0@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ottawa interim connectivity Thread-Index: AcaA7wRvtLWAEwgYSomu6TfiMlZ0Ag== From: "Glenn Parsons" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Subject: [lemonade] Ottawa interim connectivity X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1319035786==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============1319035786== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C680EF.04846761" This is a multi-part message in MIME format. ------_=_NextPart_001_01C680EF.04846761 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, Some additional logistical information for the interim meeting next week: The meeting will be in the Albion Salon of the Ottawa Marriott. We'll start at 9am on Wednesday, May 30th. Breakfast pastries, coffee break items and a buffet lunch will be provided. There will be wireless access to the Internet through the hotel. Please let me know if anyone requires a hardwire connection. For those who would like to participate remotely, we will have a conference bridge with the following coordinates: Audio Bridge Password: 3937582# Access numbers Location Number=09 Canada +1 613-765-0170=09 San Jose +1 408-495-5113=09 Boston +1 978-288-4793=09 United Kingdom +44 162-843-1170=09 France +33 1-6955-2170=09 Hong Kong +852 2100-2300=09 The World sip:carmeetme@nortel.com=09 As well, we will be using jabber (at the usual coordinates) and iChat. For iChat, please let me know if you are interested so I can determine if I need to bring extra horsepower :-) Cheers, Glenn. ------_=_NextPart_001_01C680EF.04846761 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ottawa interim connectivity

Folks,

Some additional logistical information = for the interim meeting next week:

The meeting will be in the Albion Salon = of the Ottawa Marriott.  We'll start at 9am on Wednesday, May = 30th.  Breakfast pastries, coffee break items and a buffet lunch = will be provided.

There will be wireless access to the = Internet through the hotel.  Please let me know if anyone requires = a hardwire connection.

For those who would like to participate = remotely, we will have a conference bridge with the following = coordinates:

Audio Bridge Password: 3937582#
Access numbers

Location        = Number 
Canada  +1 = 613-765-0170
San Jose        +1 408-495-5113
Boston  +1 978-288-4793
United Kingdom  +44 = 162-843-1170       
France  +33 1-6955-2170
Hong Kong       +852 2100-2300 
The World       = sip:carmeetme@nortel.com       

As well, we will be using jabber (at = the usual coordinates) and iChat.  For iChat, please let me know if = you are interested so I can determine if I need to bring extra = horsepower :-)

Cheers,
Glenn.

------_=_NextPart_001_01C680EF.04846761-- --===============1319035786== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --===============1319035786==-- From lemonade-bounces@ietf.org Fri May 26 14:09:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjgkh-00007d-PE; Fri, 26 May 2006 14:09:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjgkg-0008Kk-2N for lemonade@ietf.org; Fri, 26 May 2006 14:09:34 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjgke-0001Wh-E3 for lemonade@ietf.org; Fri, 26 May 2006 14:09:34 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Fri, 26 May 2006 19:09:10 +0100 Message-ID: <44774409.9010704@isode.com> Date: Fri, 26 May 2006 19:08:09 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Randall Gellens References: In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: lemonade@ietf.org Subject: [lemonade] Re: draft-ietf-lemonade-reconnect-06.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org [I've applied most of the changes, leaving some till later, as I need to think about them.] Randall Gellens wrote: > Excellent work on this draft. > > I do have a number of comments, but all of them are minor: > > > Section 2.1: > The above protocol sequence simply logged the user into the account, > selected the INBOX mailbox and downloaded the updated flags for a > subset of messages. > > It is proper to say "subset" since the command used "1:*"? I've changed the UID FETCH to use 1:500, as it better reflects how disconnected clients resynchronize. > Since it is only one mailbox, I guess it is technically correct, but > it seems perhaps misleading. > > > Section 3.1: > If the optional session identifier (SID) parameter is not defined, > the server will generate a new session as described in Section 3.2. > > For readability, it might be better to say "used" (or maybe "sent") > rather than "defined", since this draft defines the parameter. I've changed that to "is not provided". > Section 3.1: > Note, that this document doesn't define a minimal > required expiration timeout, as members of the Lemonade WG have > decided that any such limit would not be adequate for all > deployments. > > Since the document is nearing completion and has been around for a > while, it might be good to replace this text with something along the > lines of > > While there is no required minimum expiration timeout, server > implementations are encouraged to support as long a time as possible, > subject to denial-of-service and related concerns. Sounds good, changed. > Section 3.2: > This > forces the server to create a new session regardless if a previous, > valid session is available. If a valid session is already available > and a new one can be create, the existing session becomes inactive > and can be resumed at a later time. > > For readability, I'd suggest replacing "forces" with "instructs" (or > "requests"). Done. > Note there is a typo: "create" instead of "created". Fixed. [...] > Section 3.1: > In > order to limit Deny of Service attacks a server implementation SHOULD > have a per-user limit on maximum number of resumable sessions. When > this limit is reached the server SHOULD "expire" the oldest > inactive(*) session associated with the same user. If no inactive > session associated with the same user is available, the server MUST > return the tagged NO response to the SID command. > > Note there is a typo: "Deny of Service" instead of "Denial of Service". Fixed. > I'd suggest removing the quotes around 'expire'. Done. > I'd suggest moving the asterisked text to be inside a parenthetical > aside: "inactive(*) session" becomes "inactive (not associated with an > active TCP connection) session". Changed. > Section 3.2: > If the > SID is not recognized (for example, this is the first time the client > tries to connect, or the the SID is invalid because it is either not > known to the server or has expired) > > By "first time" you mean the first connection by this client to this > server? If so, why would the client use a SID? Perhaps it is trying > to use one from an older server, or is just confused? Either way, I'd > think it would fall into the "not known" category. So, I'd suggest > deleting the "first time" wording. Deleted. > Note there is a typo later in this section: "user has no longer > permissions" instead of "user no longer has permissions". Fixed. [...] > Section 3.2: > If the provided UIDVALIDITY matches the one provided by the currently > selected mailbox > > Wording suggestion: change "the one provided by the currently > selected" to "that of the selected" Changed. > Section 3.2: > If the list of known UIDs was also provided, the server should only > report flag changes and expunges for the provided messages. If the > client haven't provided the list of UIDs, the server acts as if the > client has specified "1:*". Thus, the client can just service these > pending events and need not perform a full resynchronization. > > Typo: "client haven't provided" instead of "client doesn't provide". Fixed. Thanks. > Suggest rewording "client can just service these", perhaps to "client > can process just these". Changed. [...] > Section 3.2: > Note, that if, while the client was offline, the mailbox was deleted > and another mailbox was renamed on top of the selected, the server > may do one of the two things: > > Typos: suggest changing to: > > * *If, while the client was offline, the selected mailbox was deleted > and another mailbox was renamed to the same name, the server > MAY do either: Changed.** [...] > Section 3.2: > the current session on logout it SHOULD use "LOGOUT (PRESERVE)" > instead of just dropping TCP connection. The former helps to avoid > unnecessary resource consumption on the server caused by a TCP > disconnect. > > Typo: add "the" between "dropping" and "TCP". Fixed. > Maybe change "the former" to "this". Done. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri May 26 15:46:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjiFz-0005Yg-Ei; Fri, 26 May 2006 15:45:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjiFx-0005Yb-Qx for lemonade@ietf.org; Fri, 26 May 2006 15:45:57 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjiFw-0004W6-ID for lemonade@ietf.org; Fri, 26 May 2006 15:45:57 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k4QJeef14647 for ; Fri, 26 May 2006 15:40:40 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 26 May 2006 15:45:44 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D0A4ACFDB@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ottawa interim dates Thread-Index: AcaA/PoZZpOSdcOQSgGXlMlvAmFmvg== From: "Glenn Parsons" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Subject: [lemonade] Ottawa interim dates X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1792751403==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============1792751403== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C680FC.FA25F911" This is a multi-part message in MIME format. ------_=_NextPart_001_01C680FC.FA25F911 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, Just to confirm (since I had a typo in my last email), the LEMONADE interim will be as originally advertised: http://ietf.org/meetings/Interim-MTGs/lemonade-06-interim.txt And starts at 9am on Wed, May 31st. Cheers, Glenn. ------_=_NextPart_001_01C680FC.FA25F911 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ottawa interim dates

Folks,

Just to confirm (since I had a typo in = my last email), the LEMONADE interim will be as originally = advertised:
http://ietf.org/meetings/Interim-MTGs/lemonade-06-interim.= txt

And starts at 9am on Wed, May = 31st.

Cheers,
Glenn.

------_=_NextPart_001_01C680FC.FA25F911-- --===============1792751403== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --===============1792751403==-- From lemonade-bounces@ietf.org Fri May 26 18:26:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjkks-0001La-Tq; Fri, 26 May 2006 18:26:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjkkq-0001LF-45; Fri, 26 May 2006 18:26:00 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjkko-0005ko-Og; Fri, 26 May 2006 18:26:00 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k4QMPw2e007492; Fri, 26 May 2006 15:25:58 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k4QMPwE4007491; Fri, 26 May 2006 15:25:58 -0700 Date: Fri, 26 May 2006 15:25:58 -0700 Message-Id: <200605262225.k4QMPwE4007491@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: lemonade@ietf.org, rfc-editor@rfc-editor.org Subject: [lemonade] RFC 4467 on Internet Message Access Protocol (IMAP) - URLAUTH Extension X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4467 Title: Internet Message Access Protocol (IMAP) - URLAUTH Extension Author: M. Crispin Status: Standards Track Date: May 2006 Mailbox: MRC@CAC.Washington.EDU Pages: 18 Characters: 36714 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-lemonade-urlauth-08.txt URL: http://www.rfc-editor.org/rfc/rfc4467.txt 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 use URLs carrying authorization to access limited message data on the IMAP server. An IMAP server that supports this extension indicates this with a capability name of "URLAUTH". [STANDARDS TRACK] This document is a product of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri May 26 18:26:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjklK-0001Ty-0X; Fri, 26 May 2006 18:26:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjklH-0001PN-31; Fri, 26 May 2006 18:26:27 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjklF-0005lc-Nk; Fri, 26 May 2006 18:26:27 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k4QMQPFM007502; Fri, 26 May 2006 15:26:25 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k4QMQP58007501; Fri, 26 May 2006 15:26:25 -0700 Date: Fri, 26 May 2006 15:26:25 -0700 Message-Id: <200605262226.k4QMQP58007501@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: lemonade@ietf.org, rfc-editor@rfc-editor.org Subject: [lemonade] RFC 4468 on Message Submission BURL Extension X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4468 Title: Message Submission BURL Extension Author: C. Newman Status: Standards Track Date: May 2006 Mailbox: chris.newman@sun.com Pages: 14 Characters: 28614 Updates: RFC3463 See-Also: I-D Tag: draft-ietf-lemonade-burl-04.txt URL: http://www.rfc-editor.org/rfc/rfc4468.txt The submission profile of Simple Mail Transfer Protocol (SMTP) provides a standard way for an email client to submit a complete message for delivery. This specification extends the submission profile by adding a new BURL command that can be used to fetch submission data from an Internet Message Access Protocol (IMAP) server. This permits a mail client to inject content from an IMAP server into the SMTP infrastructure without downloading it to the client and uploading it back to the server. [STANDARDS TRACK] This document is a product of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon May 29 22:13:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fktiz-0001jx-6i; Mon, 29 May 2006 22:12:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fktix-0001jo-Vo for lemonade@ietf.org; Mon, 29 May 2006 22:12:47 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fktix-0006l7-UC for lemonade@ietf.org; Mon, 29 May 2006 22:12:47 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FktUx-0007Zf-5i for lemonade@ietf.org; Mon, 29 May 2006 21:58:20 -0400 X-IronPort-AV: i="4.05,186,1146456000"; d="scan'208"; a="33410470:sNHT26576760" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 May 2006 21:58:16 -0400 Message-ID: <330A23D8336C0346B5C1A5BB1966664702F19E96@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated Supplemental Web Site Thread-Index: AcaDjIQ++iKv65NbTi2/4/X68b6HJQ== From: "Burger, Eric" To: "Enhancements to Internet email to support diverse serviceenivronments" X-Spam-Score: -2.6 (--) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [lemonade] Updated Supplemental Web Site X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org After months away, I'm back. The web site is updated with the interim meeting information. Also, the vendor implementation site is up. Please send me your adverts, um, implementation plans if you want them posted. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue May 30 05:45:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl0my-0008FZ-Vq; Tue, 30 May 2006 05:45:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl0mw-00088v-BB for lemonade@ietf.org; Tue, 30 May 2006 05:45:22 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fl0mq-0006ab-U9 for lemonade@ietf.org; Tue, 30 May 2006 05:45:22 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Tue, 30 May 2006 10:44:44 +0100 Message-ID: <4479E7B8.9050701@isode.com> Date: Sun, 28 May 2006 19:11:04 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Dave Cridland Subject: Re: [lemonade] Profile extensions "under discussion" References: <12468.1148056936.530375@peirce.dave.cridland.net> In-Reply-To: <12468.1148056936.530375@peirce.dave.cridland.net> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Transfer-Encoding: quoted-printable X-Encoded: Changed encoding from 8bit for 7bit transmission X-Spam-Score: 0.3 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dave Cridland wrote: > I'm going to unilaterally make some reversible decisions on the list = > of "Under discussion" extensions presented in IETF65 (St=E9phane's = > slides, page 5). > > 1) CLEARIDLE > > Dropped. I'm addressing the comment that "RFC2177 is vague on the = > exact semantics [etc]" by including some language that mandates = > unsolicited FETCH, RECENT, and EXISTS responses are sent to idling = > clients in a "timely fashion" when changes occur to the mailbox. This = > is vague, but hopefully encourages implementors to consider internal = > signalling, or relatively frequent polling. Barry is doing update to RFC 2177 (draft-leiba-imap-2177bis-xx.txt) = which should reinforce that any untagged response is allowed at any = time. Let him know if any other clarifications are needed. CLEARIDLE included a section listing event types and how they should be = reported to the client (e.g. mailbox deletion, renaming, new or expunged = messages in a non-selected mailbox). I think some sort of standard in = this area would be valuable. I also think that for multimailbox notifications it is important for the = client to have some kind of control over events which get send, = otherwise poor client can get flooded with notifications it doesn't care = about. Alexey _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue May 30 18:50:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlD2M-0001Uw-Hw; Tue, 30 May 2006 18:50:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlD2I-0001TQ-P7; Tue, 30 May 2006 18:50:02 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlD2I-0006Ed-FC; Tue, 30 May 2006 18:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k4UMo1WR031995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 May 2006 22:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FlD2H-0000nk-I0; Tue, 30 May 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 30 May 2006 18:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. Title : Persistent Virtual Folder extension to the IMAP Protocol Author(s) : S. Maes, et al. Filename : draft-ietf-lemonade-vfolder-01.txt Pages : 12 Date : 2006-5-30 Persistent Extensions to the IMAP Protocol (LPSEARCH) defines extension parameters to the [RFC3501] CREATE command to allow virtual mailboxes to be created which are views of other mailboxes narrowed by search criteria. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-vfolder-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-vfolder-01.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-vfolder-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-5-30164947.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-vfolder-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-vfolder-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-30164947.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --NextPart-- From lemonade-bounces@ietf.org Tue May 30 18:50:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlD2X-0001ZA-Tp; Tue, 30 May 2006 18:50:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlD2J-0001Tm-OX; Tue, 30 May 2006 18:50:03 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlD2I-0006EX-9h; Tue, 30 May 2006 18:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k4UMo1Hp015879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 30 May 2006 22:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FlD2H-0000np-Ij; Tue, 30 May 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 30 May 2006 18:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-03.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. Title : CONVERT Author(s) : S. Maes, R. Cromwell Filename : draft-ietf-lemonade-convert-03.txt Pages : 18 Date : 2006-5-30 CONVERT defines extensions to the IMAPv4 Rev1 protocol [RFC3501] for optimization in a mobile setting, aimed at allowing adaptation and transcoding of attachments as needed by the client. Conversion (adaptation, transcoding) may be requested by the client and performed by the server on a best effort basis or decided by the server based on its knowledge of the client capabilities, user or administrator preferences or its settings. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-convert-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-convert-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-convert-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-5-30165129.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-convert-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-convert-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-30165129.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --NextPart-- From lemonade-bounces@ietf.org Tue May 30 18:50:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlD2c-0001aV-1V; Tue, 30 May 2006 18:50:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlD2L-0001UT-26; Tue, 30 May 2006 18:50:05 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlD2K-0006Ey-UF; Tue, 30 May 2006 18:50:05 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=oak.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FlD2I-0003MW-OZ; Tue, 30 May 2006 18:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k4UMo1WR031994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 May 2006 22:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FlD2H-0000nf-HO; Tue, 30 May 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 30 May 2006 18:50:01 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-search-within-01.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. Title : WITHIN Search extension to the IMAP Protocol Author(s) : S. Maes, R. Cromwell Filename : draft-ietf-lemonade-search-within-01.txt Pages : 5 Date : 2006-5-30 WITHIN is an extension to [RFC3501] SEARCH which returns messages whose internal date is within or outside a specified interval and differs from SINCE in that an interval in days is specified instead of a date. WITHIN is expected to be most useful for persistent searches in combination with mobile devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-search-within-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-search-within-01.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-search-within-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-5-30164822.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-search-within-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-search-within-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-30164822.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --NextPart-- From lemonade-bounces@ietf.org Tue May 30 18:50:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlD2f-0001jJ-7N; Tue, 30 May 2006 18:50:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlD2M-0001Uv-Ew; Tue, 30 May 2006 18:50:06 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlD2M-0006FH-AG; Tue, 30 May 2006 18:50:06 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=willow.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FlD2I-0003MX-Rz; Tue, 30 May 2006 18:50:06 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k4UMo1Rx014508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 30 May 2006 22:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FlD2H-0000nu-JJ; Tue, 30 May 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 30 May 2006 18:50:01 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-03.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. Title : CONVERT Author(s) : S. Maes, R. Cromwell Filename : draft-ietf-lemonade-convert-03.txt Pages : 18 Date : 2006-5-30 CONVERT defines extensions to the IMAPv4 Rev1 protocol [RFC3501] for optimization in a mobile setting, aimed at allowing adaptation and transcoding of attachments as needed by the client. Conversion (adaptation, transcoding) may be requested by the client and performed by the server on a best effort basis or decided by the server based on its knowledge of the client capabilities, user or administrator preferences or its settings. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-convert-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-convert-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-convert-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-5-30165151.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-convert-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-convert-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-30165151.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --NextPart-- From lemonade-bounces@ietf.org Tue May 30 18:51:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlD3T-00039i-Lp; Tue, 30 May 2006 18:51:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlD3H-0002ta-MI; Tue, 30 May 2006 18:51:03 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlD3H-0006Lz-ID; Tue, 30 May 2006 18:51:03 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FlD3G-0003Qv-3L; Tue, 30 May 2006 18:51:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k4UMo1mU007760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 30 May 2006 22:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FlD2H-0000nz-Jw; Tue, 30 May 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 30 May 2006 18:50:01 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-notifications-02.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. Title : Lemonade notifications and filters Author(s) : R. Cromwell, S. Maes Filename : draft-ietf-lemonade-notifications-02.txt Pages : 25 Date : 2006-5-30 This document discusses how to provide notification and filtering mechanisms to IMAP [RFC3501] as part the Lemonade profile [LEMONADEPROFILEBIS]. This document also discusses the use of Lemonade notifications to implement server to server notifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-notifications-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-notifications-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-notifications-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-5-30165741.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-notifications-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-notifications-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-30165741.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --NextPart-- From lemonade-bounces@ietf.org Tue May 30 18:51:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlD3W-0003FP-5t; Tue, 30 May 2006 18:51:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlD3I-0002tp-OV; Tue, 30 May 2006 18:51:04 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlD3I-0006M7-KH; Tue, 30 May 2006 18:51:04 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FlD3G-0003Qw-4K; Tue, 30 May 2006 18:51:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k4UMo1mU007761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 30 May 2006 22:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FlD2H-0000o4-KX; Tue, 30 May 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 30 May 2006 18:50:01 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-02.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. Title : LEMONADE profile bis Author(s) : S. Maes, et al. Filename : draft-ietf-lemonade-profile-bis-02.txt Pages : 55 Date : 2006-5-30 This document describes LEMONADE profile bis. It contains pointers or mention to all the features that are normatively part of LEMONADE profile bis. This document describes a profile (a set of required extensions, restrictions and usage modes) of the IMAP and mail submission protocols. This profile allows clients (especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP and Submission to access and submit mail. This includes the ability to forward received mail without needing to download and upload the mail, to optimize submission and to efficiently resynchronize in case of loss of connectivity with the server. The Lemonade profile relies upon extensions to IMAP and Mail Submission protocols; specifically URLAUTH and CATENATE IMAP protocol ([RFC3501]) extensions and BURL extension to the SUBMIT protocol (SUBMIT). It provides also extensions to provide support for realizations of OMA mobile email enabler (MEM) ([MEM-req] and [MEM-arch]) using Internet Mail protocols defined by the IETF. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-profile-bis-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-profile-bis-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-profile-bis-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-5-30165938.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-profile-bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-profile-bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-30165938.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --NextPart-- From lemonade-bounces@ietf.org Tue May 30 20:48:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlEsZ-0003iY-7Z; Tue, 30 May 2006 20:48:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlEsX-0003i0-Hh for lemonade@ietf.org; Tue, 30 May 2006 20:48:05 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlEsW-0002ws-JF for lemonade@ietf.org; Tue, 30 May 2006 20:48:05 -0400 X-IronPort-AV: i="4.05,191,1146456000"; d="txt'?scan'208"; a="33456590:sNHT118988292" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C6844B.F9D38F6B" Date: Tue, 30 May 2006 20:47:52 -0400 Message-ID: <330A23D8336C0346B5C1A5BB1966664702F1A73C@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: draft-cook-lemonade-streaming-00.txt Thread-Index: AcZ7KvWhMH5SLE5+SIyxoTbAWZTn9gIUu9UAADN23uA= From: "Burger, Eric" To: "Enhancements to Internet email to support diverse serviceenivronments" X-Spam-Score: 0.0 (/) X-Scan-Signature: 680445c3afe8c9e96925f2dfef141924 Subject: [lemonade] draft-cook-lemonade-streaming-00.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C6844B.F9D38F6B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Until it hits the archives, here is a copy of the outline for the streaming services draft. ------_=_NextPart_001_01C6844B.F9D38F6B Content-Type: text/plain; name="draft-cook-lemonade-streaming-00.txt" Content-Transfer-Encoding: base64 Content-Description: draft-cook-lemonade-streaming-00.txt Content-Disposition: attachment; filename="draft-cook-lemonade-streaming-00.txt" DQoNCg0KDQpMZW1vbmFkZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIE4uIENvb2sNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBPcGVud2F2ZQ0KRXhwaXJlczogTm92ZW1i ZXIgMjAsIDIwMDYgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTWF5IDE5LCAyMDA2 DQoNCg0KICAgICAgICAgICAgICAgU3RyZWFtaW5nIE11bHRpbWVkaWEgTWVzc2FnaW5nIEF0dGFj aG1lbnRzDQogICAgICAgICAgICAgICAgICAgIGRyYWZ0LWNvb2stbGVtb25hZGUtc3RyZWFtaW5n LTAwDQoNClN0YXR1cyBvZiB0aGlzIE1lbW8NCg0KICAgQnkgc3VibWl0dGluZyB0aGlzIEludGVy bmV0LURyYWZ0LCBlYWNoIGF1dGhvciByZXByZXNlbnRzIHRoYXQgYW55DQogICBhcHBsaWNhYmxl IHBhdGVudCBvciBvdGhlciBJUFIgY2xhaW1zIG9mIHdoaWNoIGhlIG9yIHNoZSBpcyBhd2FyZQ0K ICAgaGF2ZSBiZWVuIG9yIHdpbGwgYmUgZGlzY2xvc2VkLCBhbmQgYW55IG9mIHdoaWNoIGhlIG9y IHNoZSBiZWNvbWVzDQogICBhd2FyZSB3aWxsIGJlIGRpc2Nsb3NlZCwgaW4gYWNjb3JkYW5jZSB3 aXRoIFNlY3Rpb24gNiBvZiBCQ1AgNzkuDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2lu ZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nDQogICBUYXNrIEZvcmNlIChJ RVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0DQogICBv dGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRl cm5ldC0NCiAgIERyYWZ0cy4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVu dHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzDQogICBhbmQgbWF5IGJlIHVwZGF0 ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQ0KICAg dGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZl cmVuY2UNCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGlu IHByb2dyZXNzLiINCg0KICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2Fu IGJlIGFjY2Vzc2VkIGF0DQogICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0 cy50eHQuDQoNCiAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3Rvcmll cyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwu DQoNCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gTm92ZW1iZXIgMjAsIDIw MDYuDQoNCkNvcHlyaWdodCBOb3RpY2UNCg0KICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQg U29jaWV0eSAoMjAwNikuDQoNCkFic3RyYWN0DQoNCiAgIFRoaXMgZG9jdW1lbnQsIHBhcnQgb2Yg dGhlIExlbW9uYWRlIFdvcmtpbmcgR3JvdXAsIGRlc2NyaWJlcyB0aGUgQmVzdA0KICAgQ3VycmVu dCBQcmFjdGljZSBmb3Igc3RyZWFtaW5nIG11bHRpbWVkaWEgYXR0YWNobWVudHMgcmVjZWl2ZWQg YnkgYQ0KICAgcmVzb3VyY2UgY29uc3RyYWluZWQgYW5kL29yIG1vYmlsZSBkZXZpY2UgZnJvbSBh IElNQVAgc2VydmVyLiAgSXQNCiAgIGFsbG93cyBzdWNoIGNsaWVudHMsIHdoaWNoIGFyZSBsaW1p dGVkIGluIHN0b3JhZ2Ugc3BhY2UgYW5kDQogICBiYW5kd2lkdGgsIHRvIHBsYXkgdmlkZW8gYW5k IGF1ZGlvIGNvbnRlbnQgd2hpY2ggaXMgYXR0YWNoZWQgdG8gZW1haWwNCiAgIG1lc3NhZ2VzLiAg VGhlIGRvY3VtZW50IGRlc2NyaWJlcyBhIHByb2ZpbGUgZm9yIG1ha2luZyB1c2Ugb2YgdGhlDQog ICBleGlzdGluZyBJTUFQIFVSTEFVVEggZXh0ZW5zaW9uIFsyXSBhbmQgdGhlICJOZXRhbm4iIFNJ UCBNZWRpYQ0KICAgU2VydmljZSBhcyBkZXNjcmliZWQgaW4gUkZDIDQyNDAgWzFdLg0KDQoNCg0K DQpDb29rICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDIwLCAyMDA2ICAgICAg ICAgICAgICAgW1BhZ2UgMV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICBMZW1vbmFkZSBNdWx0 aW1lZGlhIFN0cmVhbWluZyAgICAgICAgICAgICBNYXkgMjAwNg0KDQoNCkNvbnZlbnRpb25zIFVz ZWQgaW4gdGhpcyBEb2N1bWVudA0KDQogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9U IiwgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgYW5kICJNQVkiDQogICBpbiB0aGlzIGRvY3VtZW50 IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZWZpbmVkIGluIFJGQyAyMTE5IFs3XS4NCg0KICAg SW4gZXhhbXBsZXMsICJDOiIgYW5kICJTOiIgaW5kaWNhdGUgbGluZXMgc2VudCBieSB0aGUgY2xp ZW50IGFuZA0KICAgc2VydmVyIHJlc3BlY3RpdmVseS4gIElmIGEgc2luZ2xlICJDOiIgb3IgIlM6 IiBsYWJlbCBhcHBsaWVzIHRvDQogICBtdWx0aXBsZSBsaW5lcywgdGhlbiB0aGUgbGluZSBicmVh a3MgYmV0d2VlbiB0aG9zZSBsaW5lcyBhcmUgZm9yDQogICBlZGl0b3JpYWwgY2xhcml0eSBvbmx5 IGFuZCBhcmUgbm90IHBhcnQgb2YgdGhlIGFjdHVhbCBwcm90b2NvbA0KICAgZXhjaGFuZ2UuDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KQ29vayAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBO b3ZlbWJlciAyMCwgMjAwNiAgICAgICAgICAgICAgIFtQYWdlIDJdDQoMDQpJbnRlcm5ldC1EcmFm dCAgICAgICAgTGVtb25hZGUgTXVsdGltZWRpYSBTdHJlYW1pbmcgICAgICAgICAgICAgTWF5IDIw MDYNCg0KDQoxLiAgSW50cm9kdWN0aW9uDQoNCiAgIEVtYWlsIGNsaWVudHMgb24gcmVzb3VyY2Ug YW5kL29yIG5ldHdvcmsgY29uc3RyYWluZWQgZGV2aWNlcywgc3VjaCBhDQogICBtb2JpbGUgcGhv bmVzLCBtYXkgaGF2ZSBkaWZmaWN1bHRpZXMgaW4gcmV0cmlldmluZyBhbmQvb3Igc3RvcmluZw0K ICAgbGFyZ2UgYXR0YWNobWVudHMgcmVjZWl2ZWQgaW4gYSBtZXNzYWdlLiAgRm9yIGV4YW1wbGUs IG9uIGEgcG9vcg0KICAgbmV0d29yayBsaW5rLCB0aGUgbGF0ZW5jeSByZXF1aXJlZCB0byBkb3du bG9hZCB0aGUgZW50aXJlIGF0dGFjaG1lbnQNCiAgIG1heSBub3QgYmUgYWNjZXB0YWJsZSB0byB0 aGUgdXNlci4gIENvbnZlcnNlbHksIGV2ZW4gb24gYSBoaWdoLXNwZWVkDQogICBuZXR3b3JrLCB0 aGUgZGV2aWNlIG1heSBub3QgaGF2ZSBlbm91Z2ggc3RvcmFnZSBzcGFjZSB0byBzZWN1cmUgdGhl DQogICBhdHRhY2htZW50IG9uY2UgcmV0cmlldmVkLg0KDQogICBGb3IgY2VydGFpbiBtZWRpYSwg c3VjaCBhcyBhdWRpbyBhbmQgdmlkZW8sIHRoZXJlIGlzIGEgc29sdXRpb246IHRoZQ0KICAgbWVk aWEgY2FuIGJlIHN0cmVhbWVkIHRvIHRoZSBkZXZpY2UsIHVzaW5nIHByb3RvY29scyBzdWNoIGFz IFNJUCBbNV0NCiAgIGFuZCBwYXJ0aWN1bGFybHkgdGhlIG1lZGlhIHNlcnZlciBwcm9maWxlIGFz IHNwZWNpZmllZCBpbiBSRkMgNDI0MA0KICAgWzFdLiAgU3RyZWFtaW5nIHRoZSBtZWRpYSB0byB0 aGUgZGV2aWNlIGFkZHJlc3NlcyBib3RoIHRoZSBsYXRlbmN5DQogICBpc3N1ZSwgc2luY2UgdGhl IGNsaWVudCBjYW4gc3RhcnQgcGxheWluZyB0aGUgbWVkaWEgaW1tZWRpYXRlbHksIGFuZA0KICAg dGhlIHN0b3JhZ2UgaXNzdWUsIHNpbmNlIHRoZSBjbGllbnQgZG9lcyBub3QgbmVlZCB0byBzdG9y ZSB0aGUgbWVkaWENCiAgIGxvY2FsbHkuICBBIHRyYWRlb2ZmIGlzIHRoYXQgdGhlIG1lZGlhIGNh bm5vdCBiZSB2aWV3ZWQvcGxheWVkIHdoZW4NCiAgIHRoZSBkZXZpY2UgaXMgb2ZmbGluZS4NCg0K ICAgRXhhbXBsZXMgb2YgdGhlIHR5cGVzIG9mIG1lZGlhIHRoYXQgd291bGQgYmVuZWZpdCBmcm9t IHRoZSBhYmlsaXR5IHRvDQogICBzdHJlYW0gc3VjaCBtZWRpYSB0byB0aGUgZGV2aWNlIGluY2x1 ZGU6DQoNCiAgICAgICsgVm9pY2Ugb3IgVmlkZW8gbWFpbCBtZXNzYWdlcyByZWNlaXZlZCBhcyBh biBhdHRhY2htZW50DQoNCiAgICAgICsgQXVkaW8gY2xpcHMgc3VjaCBhcyByaW5ndG9uZXMgcmVj ZWl2ZWQgYXMgYW4gYXR0YWNobWVudA0KDQogICAgICArIFZpZGVvIGNsaXBzIHN1Y2ggYXMgbW92 aWUgdHJhaWxlcnMgcmVjZWl2ZWQgYXMgYW4gYXR0YWNobWVudA0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KQ29vayAgICAgICAgICAgICAgICAgICAgRXhw aXJlcyBOb3ZlbWJlciAyMCwgMjAwNiAgICAgICAgICAgICAgIFtQYWdlIDNdDQoMDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgTGVtb25hZGUgTXVsdGltZWRpYSBTdHJlYW1pbmcgICAgICAgICAgICAg TWF5IDIwMDYNCg0KDQoyLiAgTWVjaGFuaXNtDQoNCjIuMS4gIE92ZXJ2aWV3IG9mIE1lY2hhbmlz bQ0KDQogICBUaGUgcHJvcG9zZWQgbWVjaGFuaXNtIGZvciBzdHJlYW1pbmcgbWVkaWEgdG8gbWVz c2FnaW5nIGNsaWVudHMgaXMgYQ0KICAgcHJvZmlsZSBmb3IgbWFraW5nIHVzZSBvZiB0d28gZXhp c3RpbmcgbWVjaGFuaXNtcywgbmFtZWx5Og0KDQogICAxLiAgSU1BUCBVUkxBVVRIIEV4dGVuc2lv biBbMl0gLSBQcm92aWRpbmcgdGhlIGFiaWxpdHkgdG8gZ2VuZXJhdGUgYW4NCiAgICAgICBJTUFQ IFVSTCBbNF0gd2hpY2ggYWxsb3dzIGFub255bW91cyBhY2Nlc3MgZnJvbSBleHRlcm5hbCBzeXN0 ZW1zDQogICAgICAgdG8gc3BlY2lmaWMgbWVzc2FnZSBwYXJ0czsgZm9yIGV4YW1wbGUsIGFuIGF1 ZGlvIGNsaXAuDQoNCiAgIDIuICBNZWRpYSBTZXJ2ZXIgQW5ub3VuY2VtZW50IFNlcnZpY2UgUkZD IDQyNDAgWzFdIC0gUHJvdmlkaW5nIHRoZQ0KICAgICAgIGFiaWxpdHkgZm9yIGEgbWVkaWEgc2Vy dmVyIHRvIHN0cmVhbSBtZWRpYSB1c2luZyBhIHJlZmVyZW5jZQ0KICAgICAgIHByb3ZpZGVkIGJ5 IHRoZSBtZWRpYSBzZXJ2ZXIgY2xpZW50IGluIGEgVVJMLg0KDQogICBIb3dldmVyLCBpdCBzaG91 bGQgYmUgbm90ZWQgdGhhdCB0aGlzIGRvY3VtZW50IHByb3Bvc2VzIGEgZXh0ZW5zaW9uDQogICB0 byB0aGUgU0lQIFBhcmFtZXRlciBSZWdpc3RyeSBbOF0sIGluIG9yZGVyIHRvIGFjY29tb2RhdGUg dGhlIHBhc3NpbmcNCiAgIG9mIGEgY29udGVudCB0cmFuc2ZlciBlbmNvZGluZyBwYXJhbWV0ZXIu DQoNCiAgIFRoZSBhcHByb2FjaCBpcyBzaG93biBpbiB0aGUgZm9sbG93aW5nIGZpZ3VyZToNCg0K DQogICArLS0tLS0tLS0tLS0tLS0rDQogICB8ICAgICAgICAgICAgICB8DQogICB8IEVtYWlsIENs aWVudCB8Xg0KICAgfCAgICAgICAgICAgICAgfCBcDQogICArLS0tLS0tLS0tLS0tLS0rICBcDQog ICAgICAgfCAgICAgICAgICAgXCAgXA0KICAgICAgIHwgICAgICAgICAgICBcICBcICg1KQ0KICAg ICAgIHwgKDEpLCAgICAgICAgXCAgXA0KICAgICAgIHwgKDIpICAgICAgICAgIFwgIFwNCiAgICAg ICB8ICAgICAgICAgICAoMyksXCAgXA0KICAgICAgIHwgICAgICAgICAgICg2KSAgXCAgXA0KICAg ICAgIHwgICAgICAgICAgICAgICAgIFwgIFwNCiAgICAgICB2ICAgICAgICAgICAgICAgICAgdiAg XA0KICAgKy0tLS0tLS0tLS0tLS0tKyAgICAgICArLS0tLS0tLS0tLS0tLS0tLSsNCiAgIHwgICAg ICAgICAgICAgIHwgICg0KSAgfCAgICAgICAgICAgICAgICB8DQogICB8IElNQVAgU2VydmVyICB8 PC0tLS0tLXwgIE1lZGlhIFNlcnZlciAgfA0KICAgfCAgICAgICAgICAgICAgfCAgICAgICB8ICAg ICAgICAgICAgICAgIHwNCiAgICstLS0tLS0tLS0tLS0tLSsgICAgICAgKy0tLS0tLS0tLS0tLS0t LS0rDQoNCg0KICAgRmlndXJlIDENCg0KICAgVGhlIHByb3Bvc2VkIG1lY2hhbmlzbSBoYXMgdGhl IGZvbGxvd2luZyBzdGVwczoNCg0KICAgMS4gIENsaWVudCBkZXRlcm1pbmVzIGZyb20gaGVhZGVy cyBvZiBhIHBhcnRpY3VsYXIgbWVzc2FnZSB0aGF0IGENCiAgICAgICBwYXJ0aWN1bGFyIG1lc3Nh Z2UgcGFydCAoYXR0YWNobWVudCkgc2hvdWxkIGJlIHN0cmVhbWVkIHRvIHRoZQ0KDQoNCg0KQ29v ayAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMCwgMjAwNiAgICAgICAgICAg ICAgIFtQYWdlIDRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgTGVtb25hZGUgTXVsdGltZWRp YSBTdHJlYW1pbmcgICAgICAgICAgICAgTWF5IDIwMDYNCg0KDQogICAgICAgdXNlci4gIE5vdGUg dGhhdCBubyBhc3N1bXB0aW9ucyBhcmUgbWFkZSBhYm91dCBob3cvd2hlbi9pZiB0aGUNCiAgICAg ICBjbGllbnQgY29udGFjdHMgdGhlIHVzZXIgb2YgdGhlIGNsaWVudCBhYm91dCB0aGlzIGRlY2lz aW9uLiAgVXNlcg0KICAgICAgIGlucHV0IE1BWSBiZSByZXF1aXJlZCBpbiBvcmRlciB0byBpbml0 aWF0ZSB0aGUgcHJvcG9zZWQNCiAgICAgICBtZWNoYW5pc20uDQoNCiAgIDIuICBDbGllbnQgY29u c3RydWN0cyBhbiBJTUFQIFVSTCByZWZlcmVuY2luZyB0aGUgbWVzc2FnZSBwYXJ0LCBhbmQNCiAg ICAgICB1c2VzIHRoZSBHRU5VUkxBVVRIIFsyXSBjb21tYW5kIHRvIGdlbmVyYXRlIGEgVVJMQVVU SCBhdXRob3JpemVkDQogICAgICAgSU1BUCBVUkwuDQoNCiAgIDMuICBDbGllbnQgY29ubmVjdHMg dG8gYSBTSVAgTWVkaWEgU2VydmVyIHVzaW5nIHRoZSBBbm5vdW5jZW1lbnQNCiAgICAgICBTZXJ2 aWNlIGFzIHNwZWNpZmllZCBpbiBSRkMgNDI0MCBbMV0sIGFuZCBwYXNzZXMgdGhlIFVSTEFVVEgN CiAgICAgICBhdXRob3JpemVkIFVSTCB0byB0aGUgbWVkaWEgc2VydmVyLg0KDQogICA0LiAgTWVk aWEgU2VydmVyIGNvbm5lY3RzIHRvIHRoZSBJTUFQIFNlcnZlciBzcGVjaWZpZWQgaW4gdGhlDQog ICAgICAgcmVmZXJlbmNlZCBVUkwsIGFuZCB1c2VzIHRoZSBJTUFQIFVSTEZFVENIIFsyXSBjb21t YW5kIHRvDQogICAgICAgcmV0cmlldmUgdGhlIG1lc3NhZ2UgcGFydC4NCg0KICAgNS4gIE1lZGlh IHNlcnZlciBzdHJlYW1zIHRoZSByZXRyaWV2ZWQgbWVzc2FnZSBwYXJ0IHRvIHRoZSBjbGllbnQN CiAgICAgICB1c2luZyBSVFAgWzZdLg0KDQogICA2LiAgTWVkaWEgc2VydmVyIHRlcm1pbmF0ZXMg dGhlIFNJUCBzZXNzaW9uLg0KDQogICBJdCBzaG91bGQgYmUgbm90ZWQgdGhhdCB0aGUgcHJvcG9z ZWQgbWVjaGFuaXNtIG1ha2VzIHNldmVyYWwNCiAgIGFzc3VtcHRpb25zIGFib3V0IHRoZSBtb2Jp bGUgZGV2aWNlLCBhcyB3ZWxsIGFzIHRoZSBuZXR3b3JrIHNlcnZpY2VzLA0KICAgbmFtZWx5Og0K DQogICAgICArIE1vYmlsZSBkZXZpY2UgaXMgcHJvdmlzaW9uZWQgd2l0aCBhZGRyZXNzIG9yIGFk ZHJlc3NlcyBvZiBhDQogICAgICBtZWRpYSBzZXJ2ZXIgd2hpY2ggc3VwcG9ydHMgdGhlIGFubm91 bmNlbWVudCBzZXJ2aWNlIGRlZmluZWQgaW4NCiAgICAgIFJGQyA0MjQwIFsxXQ0KDQogICAgICAr IE1lZGlhIFNlcnZlcihzKSB1c2VkIGJ5IHRoZSBtb2JpbGUgZGV2aWNlIHN1cHBvcnQgdGhlIElN QVAgVVJMDQogICAgICBbNF0gc2NoZW1lIGZvciB0aGUgYW5ub3VuY2VtZW50IHNlcnZpY2UNCg0K ICAgICAgKyBJTUFQIFNlcnZlciB1c2VkIGJ5IHRoZSBtb2JpbGUgZGV2aWNlIHN1cHBvcnRzIGdl bmVyYXRpbmcNCiAgICAgIGFub255bW91cyBJTUFQIFVSTHMgdXNpbmcgdGhlIFVSTEFVVEggbWVj aGFuaXNtDQoNCiAgIFRoaXMgZG9jdW1lbnQgYXNzdW1lcyB0aGF0IHRoZXJlIGFyZSBubyBuZXR3 b3JrIHJlc3RyaWN0aW9ucyBiZXR3ZWVuDQogICB0aGUgZGlmZmVyZW50IGNvbXBvbmVudHMuICBT cGVjaWZpY2FsbHkgaXQgZG9lcyBub3QgYWRkcmVzcyB0aGUNCiAgIGlzc3VlcyB0aGF0IGNvdWxk IG9jY3VyIHdoZW4gdGhlIG1lZGlhIHNlcnZlciBhbmQgdGhlIElNQVAgc2VydmVyIGFyZQ0KICAg cHJvdmlkZWQgYnkgZGlmZmVyZW50IGVudGl0aWVzLCBhbmQgbmV0d29yayBzZWN1cml0eSBwcm90 b2NvbHMNCiAgIHJlc3RyaWN0IHRoZSBjb21tdW5pY2F0aW9uIGJldHdlZW4gdGhlIGRpZmZlcmVu dCBjb21wb25lbnRzLA0KICAgZXNwZWNpYWxseSBiZXR3ZWVuIHRoZSBtZWRpYSBzZXJ2ZXIgYW5k IHRoZSBJTUFQIHNlcnZlci4NCg0KMi4yLiAgQ2xpZW50IHVzZSBvZiBHRU5VUkxBVVRIIENvbW1h bmQNCg0KICAgVGhlIGRlY2lzaW9uIHRvIG1ha2UgdXNlIG9mIHN0cmVhbWluZyBzZXJ2aWNlcyBm b3IgYSBtZXNzYWdlIHBhcnQNCiAgIHdpbGwgdXN1YWxseSBiZSBwcmVkaWNhdGVkIG9uIHRoZSBj b250ZW50IHR5cGUgb2YgdGhlIG1lc3NhZ2UgcGFydC4NCiAgIFVzaW5nIHRoZSBjYXBhYmlsaXRp ZXMgb2YgdGhlIElNQVAgRkVUQ0ggY29tbWFuZCwgY2xpZW50cyBjYW4NCg0KDQoNCkNvb2sgICAg ICAgICAgICAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMjAsIDIwMDYgICAgICAgICAgICAgICBb UGFnZSA1XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgIExlbW9uYWRlIE11bHRpbWVkaWEgU3Ry ZWFtaW5nICAgICAgICAgICAgIE1heSAyMDA2DQoNCg0KICAgZGV0ZXJtaW5lIHRoZSBNSU1FIFs5 XSBDb250ZW50LVR5cGUgb2YgcGFydGljdWxhciBtZXNzYWdlIHBhcnRzLCBhbmQNCiAgIGJhc2Vk IG9uIGxvY2FsIHBvbGljaWVzIG9yIGhldXJpc3RpY3MsIGRlY2lkZSB0aGF0IHN0cmVhbWluZyBm b3IgdGhhdA0KICAgbWVzc2FnZSBwYXJ0IHdpbGwgYmUgYXR0ZW1wdGVkLg0KDQogICBPbmNlIHRo ZSBjbGllbnQgaGFzIGRldGVybWluZWQgdGhhdCBhIHBhcnRpY3VsYXIgbWVzc2FnZSBwYXJ0DQog ICByZXF1aXJlcyBzdHJlYW1pbmcsIHRoZSBjbGllbnQgZ2VuZXJhdGVzIGFuIElNQVAgVVJMIHRo YXQgcmVmZXJzIHRvDQogICB0aGUgbWVzc2FnZSBwYXJ0IGFjY29yZGluZyB0byB0aGUgbWV0aG9k IGRlc2NyaWJlZCBpbiBSRkMgMjE5MiBbNF0uDQogICBUaGUgY2xpZW50IHRoZW4gYmVnaW5zIHRo ZSBwcm9jZXNzIG9mIGdlbmVyYXRpbmcgYW4gVVJMQVVUSCBVUkwsIGJ5DQogICBhcHBlbmRpbmcg IjtFWFBJUkU9PGRhdGV0aW1lPiIgYW5kICI7VVJMQVVUSD08YWNjZXNzPiIgdG8gdGhlIGluaXRp YWwNCiAgIFVSTC4NCg0KICAgVGhlICI7RVhQSVJFPTxkYXRldGltZT4iIHBhcmFtZXRlciBpcyBv cHRpb25hbCwgaG93ZXZlciBpdCBTSE9VTEQgYmUNCiAgIHVzZWQsIHNpbmNlIHRoZSB1c2Ugb2Yg YW5vbnltb3VzIFVSTEFVVEggYXV0aG9yaXplZCBVUkxzIGlzIGENCiAgIHNlY3VyaXR5IHJpc2ss IGFuZCBkb2luZyBzbyBlbnN1cmVzIHRoYXQgYXQgc29tZSBwb2ludCBpbiB0aGUgZnV0dXJlLA0K ICAgcGVybWlzc2lvbiB0byBhY2Nlc3MgdGhhdCBVUkwgd2lsbCBjZWFzZS4NCg0KICAgVGhlIDxh Y2Nlc3M+IHBvcnRpb24gb2YgdGhlIFVSTEFVVEggcGFyYW1ldGVyIFNIT1VMRCBiZSAnYW5vbnlt b3VzJy4NCiAgIFRoaXMgZG9jdW1lbnQgbWFrZXMgdGhlIGFzc3VtcHRpb24gdGhhdCBNZWRpYSBT ZXJ2ZXJzIGFyZSB1bmxpa2VseSB0bw0KICAgYmUgY29uZmlndXJlZCBhcyBhdXRob3JpemVkIHVz ZXJzIHRvIElNQVAgc2VydmVycy4gIEluIHRoaXMgY2FzZSwNCiAgIHdpdGhvdXQgc3BlY2lmaWMg cHJpb3Iga25vd2xlZGdlIG9mIHN1Y2ggYSBjb25maWd1cmF0aW9uLCB0aGUgY2xpZW50DQogICBN VVNUIHVzZSB0aGUgJ2Fub255bW91cycgYWNjZXNzIGlkZW50aWZpZXIuICBJbiB0aGUgZXZlbnQg dGhhdCB0aGUNCiAgIGNsaWVudCBkb2VzIGhhdmUgcHJpb3Iga25vd2xlZGdlIG9mIGEgbWVkaWEg c2VydmVyIHdoaWNoIGlzDQogICBjb25maWd1cmVkIGZvciBhdXRob3JpemVkIGFjY2VzcyB0byB0 aGUgbWVkaWEgc2VydmVyLCB0aGUgJ2F1dGh1c2VyJw0KICAgYWNjZXNzIGlkZW50aWZpZXIgU0hP VUxEIGJlIHVzZWQuDQoNCiAgIFRoZSBjbGllbnQgdXNlcyB0aGUgVVJMIGdlbmVyYXRlZCBhcyBh IHBhcmFtZXRlciB0byB0aGUgR0VOQVVUSFVSTA0KICAgY29tbWFuZCwgdXNpbmcgdGhlIElOVEVS TkFMIGF1dGhvcml6YXRpb24gbWVjaGFuaXNtLiAgVGhlIFVSTA0KICAgcmV0dXJuZWQgYnkgYSBz dWNjZXNzZnVsIHJlc3BvbnNlIHRvIHRoaXMgY29tbWFuZCB3aWxsIHRoZW4gYmUgcGFzc2VkDQog ICB0byB0aGUgbWVkaWEgc2VydmVyLiAgSWYgbm8gc3VjY2Vzc2Z1bCByZXNwb25zZSB0byB0aGUg R0VOVVJMQVVUSA0KICAgY29tbWFuZCBpcyByZWNlaXZlZCwgdGhlbiBubyBmdXJ0aGVyIGFjdGlv biB3aWxsIGJlIHBvc3NpYmxlIHdpdGgNCiAgIHJlc3BlY3QgdG8gc3RyZWFtaW5nIG1lZGlhIHRv IHRoZSBjbGllbnQuDQoNCiAgIEV4YW1wbGVzOg0KDQogICBDOiBhMTIyIFVJRCBGRVRDSCAyNDM1 NiBCT0RZWzEuMi5NSU1FXQ0KICAgUzogKiAyNiBGRVRDSCAoQk9EWVsxLjIuTUlNRV0gezEyN30N CiAgIFM6IENvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IGJhc2U2NA0KICAgUzogQ29udGVudC1U eXBlOiB2aWRlby9tcGVnOw0KICAgUzogVUlEIDI0MzU2IEZMQUdTIChcU2VlbikpDQogICBTOiBh MTIyIE9LIEZFVENIIGNvbXBsZXRlZC4NCiAgIEM6IGExMjMgR0VOVVJMQVVUSCAiaW1hcDovL2pv ZUBleGFtcGxlLmNvbS9JTkJPWC87dWlkPTI0MzU2LztcDQogICBzZWN0aW9uPTEuMjtleHBpcmU9 MjAwNi0xMi0xOVQxNjozOTo1Ny0wODowMDtcDQogICB1cmxhdXRoPWFub255bW91cyIgSU5URVJO QUwNCiAgIFM6ICogR0VOVVJMQVVUSCAiaW1hcDovL2pvZUBleGFtcGxlLmNvbS9JTkJPWC87dWlk PTI0MzU2LztcDQogICBzZWN0aW9uPTEuMjtleHBpcmU9MjAwNi0xMi0xOVQxNjozOTpcNTctMDg6 MDA7XA0KICAgdXJsYXV0aD1hbm9ueW1vdXM6XA0KICAgaW50ZXJuYWw6MjM4MjM0OTgyMzk4MjM5 ODk4YTk4OTg5OTg3OThiOTg3czg3OTIwIg0KICAgUzogYTEyMyBPSyBHRU5VUkxBVVRIIGNvbXBs ZXRlZA0KDQoNCg0KQ29vayAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMCwg MjAwNiAgICAgICAgICAgICAgIFtQYWdlIDZdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgTGVt b25hZGUgTXVsdGltZWRpYSBTdHJlYW1pbmcgICAgICAgICAgICAgTWF5IDIwMDYNCg0KDQogICBD OiBhMTIyIFVJRCBGRVRDSCAyNDM1OSBCT0RZWzEuMi5NSU1FXQ0KICAgUzogKiAyNiBGRVRDSCAo Qk9EWVsxLjMuTUlNRV0gezEyN30NCiAgIFM6IENvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IGJh c2U2NA0KICAgUzogQ29udGVudC1UeXBlOiBhdWRpby9HNzI5Ow0KICAgUzogVUlEIDI0MzU5IEZM QUdTIChcU2VlbikpDQogICBTOiBhMTIyIE9LIEZFVENIIGNvbXBsZXRlZC4NCiAgIEM6IGExMjMg R0VOVVJMQVVUSCAiaW1hcDovL2pvZUBleGFtcGxlLmNvbS9JTkJPWC87dWlkPTI0MzU5LztcDQog ICBzZWN0aW9uPTEuMztleHBpcmU9MjAwNi0xMi0xOVQxNjozOTo1Ny0wODowMDtcDQogICB1cmxh dXRoPWFub255bW91cyIgSU5URVJOQUwNCiAgIFM6ICogR0VOVVJMQVVUSCAiaW1hcDovL2pvZUBl eGFtcGxlLmNvbS9JTkJPWC87dWlkPTI0MzU5LztcDQogICBzZWN0aW9uPTEuMztleHBpcmU9MjAw Ni0xMi0yMFQxODozMTpcNDUtMDg6MDA7XA0KICAgdXJsYXV0aD1hdXRodXNlcjpcDQogICBpbnRl cm5hbDowOTgyMzA5MjM0MDkyODQwOTIzODQwOTI4NDAyOTM0ODAyMzk0ODIiDQogICBTOiBhMTIz IE9LIEdFTlVSTEFVVEggY29tcGxldGVkDQoNCjIuMy4gIENsaWVudCBVc2Ugb2YgdGhlIE1lZGlh IFNlcnZlciBBbm5vdW5jZW1lbnQgU2VydmljZQ0KDQogICBPbmNlIGFuIGF1dGhvcml6ZWQgSU1B UCBVUkwgaGFzIGJlZW4gZ2VuZXJhdGVkLCBpdCBpcyB1cCB0byB0aGUNCiAgIGNsaWVudCB0byBw YXNzIHRoYXQgVVJMIHRvIGEgc3VpdGFibGUgbWVkaWEgc2VydmVyIHRoYXQgaXMgY2FwYWJsZSBv Zg0KICAgcmV0cmlldmluZyB0aGUgVVJMIHZpYSBJTUFQLCBhbmQgc3RyZWFtaW5nIHRoZSBjb250 ZW50IHRvIHRoZSBjbGllbnQNCiAgIHVzaW5nIHRoZSBSVFAgWzZdcHJvdG9jb2wuDQoNCiAgIFRo ZSBtZWRpYSBzZXJ2ZXIgYW5ub3VuY2VtZW50IHNlcnZpY2UgaXMgdXNlZCwgYXMgZGVzY3JpYmVk IGluIFJGQw0KICAgNDI0MCBbMV0uICBUaGlzIHNlcnZpY2UgYWxsb3dzIHRoZSBjbGllbnQgdG8g c2VuZCBhIFNJUCBJTlZJVEUgdG8gYQ0KICAgc3BlY2lhbCB1c2VybmFtZSAoJ2FubmMnKSBhdCB0 aGUgbWVkaWEgc2VydmVyICh0aGUgImFubm91bmNlbWVudCINCiAgIHVzZXIpLCBzdXBwbHlpbmcg dGhlIFVSTCBvYnRhaW5lZCBhcyBwZXIgdGhlIHByZXZpb3VzIHNlY3Rpb24uDQoNCiAgIFRoZSBT SVAgSU5WSVRFIGlzIGNvbnN0cnVjdGVkIGFzIHNob3duIGluIHRoZSBleGFtcGxlcyBiZWxvdywg bm90ZQ0KICAgdGhhdCBhcyBwZXIgUkZDIDQyNDAsIHRoZSBwbGF5IHBhcmFtZXRlciBpcyBtYW5k YXRvcnksIGFuZCBzcGVjaWZpZXMNCiAgIHRoZSBhdXRob3JpemVkIElNQVAgVVJMIHRvIGJlIHBs YXllZC4NCg0KICAgVGhlIGNvbnRlbnQtdHlwZSBwYXJhbWV0ZXIgaXMgb3B0aW9uYWwgaW4gUkZD IDQyNDAsIGhvd2V2ZXIgaXQgTVVTVA0KICAgYmUgc3VwcGxpZWQgaGVyZSwgdXNpbmcgdGhlIENv bnRlbnQtVHlwZSBoZWFkZXIgcmV0dXJuZWQgYnkgdGhlIElNQVANCiAgIHNlcnZlciBmb3IgdGhl IG1lc3NhZ2UgcGFydC4gIFRoZSByZWFzb24gZm9yIHN1cHBseWluZyB0aGUgY29udGVudC0NCiAg IHR5cGUgcGFyYW1ldGVyIGlzIHRoYXQgd2hlbiB0aGUgbWVkaWEgc2VydmVyIGlzc3VlcyBhIFVS TEZFVENIDQogICBjb21tYW5kIHRvIHJldHJpZXZlIHRoZSBtZXNzYWdlIHBhcnQsIHRoZSBtZXNz YWdlIHBhcnQgd2lsbCBiZQ0KICAgcmV0dXJuZWQgd2l0aG91dCBhbnkgY29udGVudCB0eXBlIGlu Zm9ybWF0aW9uLiAgU2luY2UgdGhlIG1lZGlhDQogICBzZXJ2ZXIgaXMgbm90IGxpa2VseSB0byBo YXZlIGF1dGhvcml6ZWQgYWNjZXNzIHRvIG90aGVyIHNlY3Rpb25zIGluDQogICB0aGF0IG1lc3Nh Z2UsIGZvciBleGFtcGxlIHRoZSBNSU1FIHNlY3Rpb24sIHRoZW4gaXQgbWF5IGZhaWwgdG8NCiAg IHN0cmVhbSB0aGUgY29udGVudCBpZiB0aGUgY29udGVudCB0eXBlIGlzIG5vdCBzdXBwbGllZCBh cyBhIHBhcmFtZXRlcg0KICAgdG8gdGhlIFNJUCBJTlZJVEUgVVJJLg0KDQogICBTaW1pbGFybHks IHRoZSBtZXNzYWdlIHdlbGwgYmUgZW5jb2RlZCB3aXRoIGEgY29udGVudCB0cmFuc2Zlcg0KICAg ZW5jb2Rpbmcgc3VjaCBhcyBiYXNlIDY0LiAgSG93ZXZlciwgUkZDIDQyNDAgZG9lcyBub3QgaW5j bHVkZSBhDQogICBtZXRob2QgZm9yIGNvbW11bmljYXRpbmcgY29udGVudCB0cmFuc2ZlciBlbmNv ZGluZyB0byB0aGUgbWVkaWENCiAgIHNlcnZlciBhcyBwYXJ0IG9mIHRoZSBhbm5vdW5jZW1lbnQg c2VydmljZSwgbm9yIGRvZXMgdGhlIFVSTEZFVENIDQogICBjb21tYW5kIGluY2x1ZGUgYSBtZWNo YW5pc20gZm9yIHJldHJpZXZpbmcgbWVzc2FnZSBwYXJ0cyB3aXRob3V0DQogICBlbmNvZGluZyAo Yy5mLiB0aGUgW0JJTkFSWV0gZXh0ZW5zaW9uIHRvIElNQVApLiAgVGhlcmVmb3JlLCBhbg0KDQoN Cg0KQ29vayAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMCwgMjAwNiAgICAg ICAgICAgICAgIFtQYWdlIDddDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgTGVtb25hZGUgTXVs dGltZWRpYSBTdHJlYW1pbmcgICAgICAgICAgICAgTWF5IDIwMDYNCg0KDQogICBleHRlbnNpb24g cGFyYW1ldGVyIGlzIHJlcXVpcmVkLCBuYW1lbHkgYSAnY29udGVudC10cmFuc2Zlci1lbmNvZGlu ZycNCiAgIHBhcmFtZXRlciwgdXNpbmcgdGhlIHZhbHVlIG9mIHRoZSBDb250ZW50LVRyYW5zZmVy LUVuY29kaW5nIE1JTUUNCiAgIGhlYWRlciByZXR1cm5lZCBieSB0aGUgSU1BUCBzZXJ2ZXIgZm9y IHRoZSBtZXNzYWdlIHBhcnQuICBUaGUNCiAgIGNvbnRlbnQtdHJhbnNmZXItZW5jb2RpbmcgcGFy YW1ldGVyIE1VU1QgYmUgc3VwcGxpZWQgaWYgYSBDb250ZW50LQ0KICAgVHJhbnNmZXItRW5jb2Rp bmcgaGVhZGVyIGZvciB0aGUgbWVzc2FnZSBwYXJ0IGV4aXN0ZWQgaW4gdGhlIG9yaWdpbmFsDQog ICBtZXNzYWdlLg0KDQogICBFeGFtcGxlcyBvZiB2YWxpZCBTSVAgSU5WSVRFIFVSSXMgc2VudCB0 byB0aGUgbWVkaWEgc2VydmVyDQogICBhbm5vdW5jZW1lbnQgc2VydmljZToNCg0KICAgc2lwOmFu bmNAbXMyLmV4YW1wbGUubmV0OyBcDQogICBwbGF5PWltYXA6Ly9qb2VAZXhhbXBsZS5jb20vSU5C T1gvO3VpZD0yNDM1Ni87c2VjdGlvbj0xLjI7XA0KICAgZXhwaXJlPTIwMDYtMTItMTlUMTY6Mzk6 XDU3LTA4OjAwO3VybGF1dGg9YW5vbnltb3VzOlwNCiAgIGludGVybmFsOjIzODIzNDk4MjM5ODIz OTg5OGE5ODk4OTk4Nzk4Yjk4N3M4NzkyMDsgXA0KICAgY29udGVudC10eXBlPXZpZGVvL21wZWc7 IFwNCiAgIGNvbnRlbnQtdHJhbnNmZXItZW5jb2Rpbmc9YmFzZTY0DQoNCg0KICAgc2lwOmFubmNA bXMxLmV4YW1wbGUubmV0OyBcDQogICBwbGF5PWltYXA6Ly9mcmVkQGV4YW1wbGUuY29tL0lOQk9Y Lzt1aWQ9MjQzNTkvO3NlY3Rpb249MS4zO1wNCiAgIGV4cGlyZT0yMDA2LTEyLTIwVDE4OjMxOlw0 NS0wODowMDt1cmxhdXRoPWF1dGh1c2VyOlwNCiAgIGludGVybmFsOjA5ODIzMDkyMzQwOTI4NDA5 MjM4NDA5Mjg0MDI5MzQ4MDIzOTQ4MjsgXA0KICAgY29udGVudC10eXBlPWF1ZGlvL0c3Mjk7IFwN CiAgIGNvbnRlbnQtdHJhbnNmZXItZW5jb2Rpbmc9YmFzZTY0DQoNCiAgIElmIHRoZSBTSVAgSU5W SVRFIGlzIHN1Y2Nlc3NmdWwsIGFzIGluZGljYXRlZCBieSBhIDIwMCBPSyByZXNwb25zZSwNCiAg IHRoZSBjbGllbnQgY2FuIGFzc3VtZSB0aGF0IHRoZSBtZWRpYSBzZXJ2ZXIgaGFzIHN1Y2Nlc3Nm dWxseQ0KICAgcmV0cmlldmVkIHRoZSBjb250ZW50IGZyb20gdGhlIElNQVAgc2VydmVyLCBhbmQg dGhhdCB0aGUgbmVnb3RpYXRlZA0KICAgUlRQIHN0cmVhbSB3aWxsIHNob3J0bHkgYmVnaW4uDQoN CiAgIEFuIHVuc3VjY2Vzc2Z1bCByZXNwb25zZSBjb2RlIG9mIDQwNCByZWNlaXZlZCBmcm9tIHRo ZSBtZWRpYSBzZXJ2ZXINCiAgIGluZGljYXRlcyB0aGF0IHRoZSBjb250ZW50IGNvdWxkIG5vdCBi ZSBmb3VuZCBvciBjb3VsZCBub3QgYmUNCiAgIHJldHJpZXZlZCBmb3Igc29tZSByZWFzb24uICBG b3IgZXhhbXBsZSwgdGhlIG1lZGlhIHNlcnZlciBtYXkgbm90DQogICBzdXBwb3J0IHRoZSB1c2Ug b2YgSU1BUCBVUkxzLiAgQXQgdGhpcyBwb2ludCwgdGhlcmUgYXJlIHNldmVyYWwNCiAgIG9wdGlv bnMgdG8gdGhlIGNsaWVudCwgc3VjaCBhcyB1c2luZyBhbHRlcm5hdGUgbWVkaWEgc2VydmVycywg b3INCiAgIGdpdmluZyB1cCBpbiBhdHRlbXB0aW5nIHRvIHN0cmVhbSB0aGUgcmVxdWlyZWQgbWVz c2FnZSBwYXJ0Lg0KDQogICBUaGlzIGRvY3VtZW50IGRvZXMgbm90IGdvIGludG8gdGhlIGRldGFp bHMgb2YgdGhlIFNJUCBbNV0sIFNEUCBbMTFdDQogICBvciBSVFAgWzZdIHByb3RvY29sczsgdGhl c2UgYXJlIHdlbGwgZGVzY3JpYmVkIGVsc2V3aGVyZS4NCg0KMi40LiAgTWVkaWEgU2VydmVyIFVz ZSBvZiBJTUFQIFNlcnZlcg0KDQogICBBIG1lZGlhIHNlcnZlciByZWNlaXZpbmcgYSBTSVAgSU5W SVRFIHRvIHRoZSBhbm5jIHVzZXIgbXVzdCBmaXJzdA0KICAgYXR0ZW1wdCB0byByZXRyaWV2ZSB0 aGUgY29udGVudCBpbmRpY2F0ZWQgaW4gdGhlIHBsYXkgcGFyYW1ldGVyLA0KICAgYmVmb3JlIHJl dHVybmluZyBhIHJlc3BvbnNlIHRvIHRoZSBjbGllbnQuICBUaGlzIHNlY3Rpb24gZGVzY3JpYmVz DQogICBob3cgdGhlIG1lZGlhIHNlcnZlciBjb252ZXJ0cyB0aGUgcmVjZWl2ZWQgSU1BUCBVUkwg aW50byBzdWl0YWJsZQ0KICAgSU1BUCBjb21tYW5kcyBmb3IgcmV0cmlldmluZyB0aGUgY29udGVu dC4NCg0KDQoNCg0KQ29vayAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMCwg MjAwNiAgICAgICAgICAgICAgIFtQYWdlIDhdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgTGVt b25hZGUgTXVsdGltZWRpYSBTdHJlYW1pbmcgICAgICAgICAgICAgTWF5IDIwMDYNCg0KDQogICBU aGUgbWVkaWEgc2VydmVyIGZpcnN0IGNvbm5lY3RzIHRvIHRoZSBJTUFQIHNlcnZlciBzcGVjaWZp ZWQgaW4gdGhlDQogICBVUkwuICBPbmNlIGNvbm5lY3RlZCwgdGhlIG1lZGlhIHNlcnZlciBNQVkg Y2hvb3NlIHRvIHVzZSBUTFMgWzEwXSB0bw0KICAgZW5jcnlwdCB0aGUgY29tbXVuaWNhdGlvbiBw YXRoLg0KDQogICBJZiB0aGUgbWVkaWEgc2VydmVyIGlzIGNvbmZpZ3VyZWQgYXMgYW4gYXV0aG9y aXplZCB1c2VyIG9mIHRoZSBJTUFQDQogICBzZXJ2ZXIsIGl0IFNIT1VMRCBhdXRoZW50aWNhdGUg dG8gdGhlIElNQVAgc2VydmVyIHVzaW5nIHRoZQ0KICAgY3JlZGVudGlhbHMgZm9yIHRoYXQgdXNl ci4gIFRoaXMgZG9jdW1lbnQgZG9lcyBub3QgZ28gaW50byB0aGUNCiAgIGRldGFpbHMgb2YgSU1B UCBhdXRoZW50aWNhdGlvbiwgYnV0IHRoZSBhdXRoZW50aWNhdGlvbiBTSE9VTEQgTk9UIHVzZQ0K ICAgdGhlIExPR0lOIGNvbW1hbmQgb3ZlciBhIG5vbi1lbmNyeXB0ZWQgY29tbXVuaWNhdGlvbiBw YXRoLg0KDQogICBJZiB0aGUgbWVkaWEgc2VydmVyIGlzIG5vdCBjb25maWd1cmVkIGFzIGFuIGF1 dGhvcml6ZWQgdXNlciBvZiB0aGUNCiAgIElNQVAgc2VydmVyLCBpdCBNVVNUIGF1dGhlbnRpY2F0 ZSB0byB0aGUgSU1BUCBzZXJ2ZXIgdXNpbmcgdGhlIExPR0lODQogICBjb21tYW5kLCB3aXRoIHRo ZSB1c2VybmFtZSBvZiAiYW5vbnltb3VzIi4gIEhvd2V2ZXIsIGluIHRoaXMgY2FzZSwgaWYNCiAg IHRoZSBVUkwgc3VwcGxpZWQgaW4gdGhlICdwbGF5JyBwYXJhbWV0ZXIgb2YgdGhlIFNJUCBpbnZp dGUgc3BlY2lmaWVzDQogICBhbiBhdXRob3JpemF0aW9uIG9mICdhdXRodXNlcicsIHRoZW4gdGhl IG1lZGlhIHNlcnZlciBTSE9VTEQgTk9UDQogICBhdHRlbXB0IHRvIGNvbnRhY3QgdGhlIElNQVAg c2VydmVyLCBidXQgU0hPVUxEIGluc3RlYWQgaW1tZWRpYXRlbHkNCiAgIHJldHVybiBhIHJlc3Bv bnNlIGNvZGUgb2YgNDA0IHdpdGggYSByZWFzb24gcGhyYXNlIG9mICdOb3QgYXV0aG9yaXplZA0K ICAgdG8gYWNjZXNzIHJlc291cmNlJy4gcmVhc29uLg0KDQogICBPbmNlIGF1dGhlbnRpY2F0ZWQs IHRoZSBtZWRpYSBzZXJ2ZXIgaXNzdWVzIHRoZSBVUkxGRVRDSCBjb21tYW5kLA0KICAgdXNpbmcg dGhlIFVSTCBzdXBwbGllZCBpbiB0aGUgJ3BsYXknIHBhcmFtZXRlciBvZiB0aGUgU0lQIGludml0 ZS4gIEENCiAgIHN1Y2Nlc3NmdWwgVVJMRkVUQ0ggY29tbWFuZCB3aWxsIHJldHVybiB0aGUgbWVz c2FnZSBwYXJ0LCB3aGljaCBtdXN0DQogICBiZSBkZWNvZGVkIGJ5IHRoZSBtZWRpYSBzZXJ2ZXIs IGFjY29yZGluZyB0byB0aGUgY29udGVudC10cmFuc2Zlci0NCiAgIGVuY29kaW5nIGhlYWRlciBw cm92aWRlZCBieSB0aGUgY2xpZW50IChpZiBhbnkpLiAgSWYgdGhlIFVSTEZFVENIIHdhcw0KICAg dW5zdWNjZXNzZnVsLCB0aGVuIHRoZSBtZWRpYSBzZXJ2ZXIgTVVTVCByZXR1cm4gYSByZXNwb25z ZSBjb2RlIG9mDQogICA0MDQgd2l0aCBhbiBhcHByb3ByaWF0ZSByZWFzb24gY29kZS4NCg0KICAg QXNzdW1pbmcgdGhlIGNvbnRlbnQgaXMgcmV0cmlldmVkIGFuZCBkZWNvZGVkIHN1Y2Nlc3NmdWxs eSwgdGhlIG1lZGlhDQogICBzZXJ2ZXIgcmV0dXJucyBhIDIwMCBPSyByZXNwb25zZSBjb2RlLCBh bmQgYWZ0ZXIgYW4gQUNLIGlzIHJlY2VpdmVkLA0KICAgYW4gUlRQIHN0cmVhbSBpcyBkZWxpdmVy ZWQgdG8gdGhlIGNsaWVudCB1c2luZyB0aGUgcGFyYW1ldGVycw0KICAgbmVnb3RpYXRlZCBpbiB0 aGUgU0RQLg0KDQogICBUaGUgbWVkaWEgc2VydmVyIE1BWSBjaG9vc2UgdG8gaW1wbGVtZW50IGNv bm5lY3Rpb24gY2FjaGluZywgaW4gd2hpY2gNCiAgIGNhc2UgY29ubmVjdGlvbiBhbmQgZGlzY29u bmVjdGlvbiBmcm9tIHRoZSBJTUFQIHNlcnZlciBhcmUgaGFuZGxlZA0KICAgYWNjb3JkaW5nIHRv IHdoYXRldmVyIGFsZ29yaXRobSB0aGUgbWVkaWEgc2VydmVyIGNob29zZXMuDQoNCiAgIEV4YW1w bGVzOg0KDQogICBDOiBhMDAxIExPR0lOIGFub255bW91cyBudWxsDQogICBTOiBhMDAxIE9LIExP R0lOIGNvbXBsZXRlZC4NCiAgIEM6IGEwMDIgVVJMRkVUQ0gNCiAgICJpbWFwOi8vam9lQGV4YW1w bGUuY29tL0lOQk9YLzt1aWQ9MjQzNTYvO3NlY3Rpb249MS4yOyBcDQogICBleHBpcmU9MjAwNi0x Mi0xOVQxNjozOTpcNTctMDg6MDA7dXJsYXV0aD1hbm9ueW1vdXM6XA0KICAgaW50ZXJuYWw6MjM4 MjM0OTgyMzk4MjM5ODk4YTk4OTg5OTg3OThiOTg3czg3OTIwIg0KICAgUzogKiBVUkxGRVRDSCAi aW1hcDovL2pvZUBleGFtcGxlLmNvbS9JTkJPWC87dWlkPTI0MzU2LzsgXA0KICAgc2VjdGlvbj0x LjI7ZXhwaXJlPTIwMDYtMTItMTlUMTY6Mzk6XDU3LTA4OjAwO3VybGF1dGg9YW5vbnltb3VzOiBc DQogICBpbnRlcm5hbDoyMzgyMzQ5ODIzOTgyMzk4OThhOTg5ODk5ODc5OGI5ODdzODc5MjAiIHsz Nn0NCiAgIFM6IFUya2dkbWx6SUhCaFkyVnRMQ0J3WVhKaElHSmxiR3gxYlM0Sw0KDQoNCg0KQ29v ayAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMCwgMjAwNiAgICAgICAgICAg ICAgIFtQYWdlIDldDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgTGVtb25hZGUgTXVsdGltZWRp YSBTdHJlYW1pbmcgICAgICAgICAgICAgTWF5IDIwMDYNCg0KDQogICBTOiBhMDAyIE9LIFVSTEZF VENIIGNvbXBsZXRlZC4NCiAgIEM6IGEwMDMgTE9HT1VUDQogICBTOiBhMDAzIE9LIExPR09VVCBj b21wbGV0ZWQuDQoNCjIuNS4gIFByb3RvY29sIERpYWdyYW0NCg0KICAgVGhlIGZvbGxvd2luZyBk aWFncmFtIHNob3dzIGEgc2ltcGxpZmllZCB2aWV3IG9mIHRoZSBwcm90b2NvbA0KICAgaW50ZXJh Y3Rpb25zIGJldHdlZW4gdGhlIGVtYWlsIGNsaWVudCwgdGhlIElNQVAgc2VydmVyIGFuZCB0aGUg bWVkaWENCiAgIHNlcnZlci4gIFRoZSBJTUFQLCBTSVAgYW5kIFJUUCBwcm90b2NvbHMgYXJlIGRp c3Rpbmd1aXNoZWQgd2l0aA0KICAgZGlmZmVyZW50IGxpbmUgc3R5bGVzLg0KDQogICBDbGllbnQg ICAgICAgICAgICAgICAgICAgICBJTUFQIFNlcnZlciAgICAgICAgICAgICAgICAgICBNZWRpYSBT ZXJ2ZXINCiAgICAgfCAgIEZFVENIIEJPRFlbTUlNRV0gICAgICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwNCiAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+fCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgfCAgIEdFTlVSTEFVVEggICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgfC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0+fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwNCiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgU0lQIElOVklURSAgICAg ICAgICAgICAgICAgICAgICAgIHwNCiAgICAgfD09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PnwNCiAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICBVUkxGRVRDSCAgICAgICAgICAgIHwN CiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfDwtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLXwNCiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg MjAwIE9LICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgfDw9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PXwNCiAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgQUNLICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwNCiAgICAgfD09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PnwNCiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgfCAgICAgICAgICAgICAgICAgICAgU3Ry ZWFtIE1lc3NhZ2UgUGFydCAoUlRQKSAgICAgICAgICAgICAgIHwNCiAgICAgfDwrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrK3wNCiAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpDb29rICAgICAg ICAgICAgICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDIwLCAyMDA2ICAgICAgICAgICAgICBbUGFn ZSAxMF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICBMZW1vbmFkZSBNdWx0aW1lZGlhIFN0cmVh bWluZyAgICAgICAgICAgICBNYXkgMjAwNg0KDQoNCjMuICBTZWN1cml0eSBDb25zaWRlcmF0aW9u cw0KDQogICBUaGlzIGRvY3VtZW50IHByb3Bvc2VzIHRoZSB1c2Ugb2YgVVJMQVVUSCAicGF3bi10 aWNrZXRzIiB0byBncmFudA0KICAgYWNjZXNzIHRvIG1lc3NhZ2UgcGFydHMgdGhhdCBhcmUgcmVx dWlyZWQgdG8gYmUgc3RyZWFtZWQgYnkgdGhlIG1lZGlhDQogICBzZXJ2ZXIuICBJZiBhbiBhbm9u eW1vdXMgcGF3bi10aWNrZXQgaXMgdXNlZCwgdGhhdCBncmFudHMgYWNjZXNzIHRvDQogICBhbnkg Y2xpZW50IG9mIHRoZSBJTUFQIHNlcnZlciwgd2l0aG91dCByZXF1aXJpbmcgYW55IGF1dGhlbnRp Y2F0aW9uDQogICBjcmVkZW50aWFscy4gIEV2ZW4gaWYgYW4gYXV0aG9yaXplZCBwYXduLXRpY2tl dCBpcyBncmFudGVkLCBhY2Nlc3MgaXMNCiAgIGdyYW50ZWQgdG8gYW55IGNsaWVudCB0aGF0IGhh cHBlbnMgdG8gYmUgYW4gYXV0aG9yaXplZCB1c2VyIG9mIHRoZQ0KICAgSU1BUCBzZXJ2ZXIuDQoN CiAgIENsZWFybHksIGFueSB0aGlyZCBwYXJ0aWVzIHdoaWNoIGdhaW4gYWNjZXNzIHRvIHRoZSBw YXduLXRpY2tldHMgY2FuDQogICBwb3RlbnRpYWxseSBhY2Nlc3MgcHJpdmF0ZSBkYXRhLiAgVG8g bWluaW1pc2UgdGhpcywgaW1wbGVtZW50b3JzDQogICBzaG91bGQgY29uc2lkZXIgdGhlIGZvbGxv d2luZzoNCg0KICAgICAgSU1BUCBjbGllbnRzIFNIT1VMRCB1c2UgZW5jcnlwdGlvbiBzdWNoIGFz IFRMUyBbMTBdIHRvIHNlY3VyZSB0aGUNCiAgICAgIGNvbW11bmljYXRpb24gcGF0aCB0byB0aGUg SU1BUCBzZXJ2ZXINCg0KICAgICAgVGhlIG1lZGlhIHNlcnZlciBTSE9VTEQgdXNlIGVuY3J5cHRp b24gc3VjaCBhcyBUTFMgc2VjdXJlIHRoZQ0KICAgICAgY29tbXVuaWNhdGlvbiBwYXRoIHRvIHRo ZSBJTUFQIHNlcnZlcg0KDQogICBIb3dldmVyLCB0aGUgY29tbXVuaWNhdGlvbiBwYXRoIGJldHdl ZW4gdGhlIGNsaWVudCBhbmQgdGhlIG1lZGlhDQogICBzZXJ2ZXIgdXNlcyBTSVAsIHdoaWNoIGN1 cnJlbnRseSBoYXMgbm8gbWVjaGFuaXNtIHRvIHNlY3VyZSB0aGUgZGF0YQ0KICAgY29udGFpbmVk IGluIHRoZSBTSVAgSU5WSVRFIFVSSS4gIFRodXMsIGV2ZW4gaWYgYW4gZW5jcnlwdGVkDQogICBj b21tdW5pY2F0aW9uIHBhdGggaXMgdXNlZCB0byB0aGUgSU1BUCBzZXJ2ZXIsIHRoZSBwb3RlbnRp YWwgZm9yDQogICB0aGlyZCBwYXJ0aWVzIHRvIGdhaW4gYWNjZXNzIHRvIHRoZSBwYXduLXRpY2tl dCBzdGlsbCBleGlzdHMuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KQ29vayAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMCwg MjAwNiAgICAgICAgICAgICAgW1BhZ2UgMTFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgTGVt b25hZGUgTXVsdGltZWRpYSBTdHJlYW1pbmcgICAgICAgICAgICAgTWF5IDIwMDYNCg0KDQo0LiAg Q29udHJpYnV0b3JzDQoNCjUuICBSZWZlcmVuY2VzDQoNCiAgIFsxXSAgIEJ1cmdlciwgRS4sICJC YXNpYyBOZXR3b3JrIE1lZGlhIFNlcnZpY2VzIHdpdGggU0lQIiwgUkZDIDQyNDAsDQogICAgICAg ICBEZWNlbWJlciAyMDA1Lg0KDQogICBbMl0gICBDcmlzcGluLCBNLiwgIkludGVybmV0IE1lc3Nh Z2UgQWNjZXNzIFByb3RvY29sIChJTUFQKSAtIFVSTEFVVEgNCiAgICAgICAgIEV4dGVuc2lvbiIs IGRyYWZ0LWlldGYtbGVtb25hZGUtdXJsYXV0aC0wOC50eHQgKHdvcmsgaW4NCiAgICAgICAgIHBy b2dyZXNzKSwgT2N0b2JlciAyMDA1Lg0KDQogICBbM10gICBDcmlzcGluLCBNLiwgIkludGVybmV0 IE1lc3NhZ2UgQWNjZXNzIFByb3RvY29sIC0gVmVyc2lvbg0KICAgICAgICAgNHJldjEiLCBSRkMg MzUwMSwgTWFyY2ggMjAwMy4NCg0KICAgWzRdICAgTmV3bWFuLCBDLiwgIklNQVAgVVJMIFNjaGVt ZSIsIFJGQyAyMTkyLCBTZXB0ZW1iZXIgMTk5Ny4NCg0KICAgWzVdICAgUm9zZW5iZXJnLCBKLiwg U2NodWx6cmlubmUsIEguLCBDYW1hcmlsbG8sIEcuLCBKb2huc3RvbiwgQS4sDQogICAgICAgICBQ ZXRlcnNvbiwgSi4sIFNwYXJrcywgUi4sIEhhbmRsZXksIE0uLCBhbmQgRS4gU2Nob29sZXIsICJT SVA6DQogICAgICAgICBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wiLCBSRkMgMzI2MSwgSnVu ZSAyMDAyLg0KDQogICBbNl0gICBTY2h1bHpyaW5uZSwgSC4sIENhc25lciwgUy4sIEZyZWRlcmlj aywgUi4sIGFuZCBWLiBKYWNvYnNvbiwNCiAgICAgICAgICJSVFA6IEEgVHJhbnNwb3J0IFByb3Rv Y29sIGZvciBSZWFsLVRpbWUgQXBwbGljYXRpb25zIiwNCiAgICAgICAgIFJGQyAzNTUwLCBKdWx5 IDIwMDMuDQoNCiAgIFs3XSAgIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZD cyB0byBJbmRpY2F0ZSBSZXF1aXJlbWVudA0KICAgICAgICAgTGV2ZWxzIiwgUkZDIDIxMTksIEJD UCAxNCwgTWFyY2ggMTk5Ny4NCg0KICAgWzhdICAgQ2FtYXJpbGxvLCBHLiwgIlRoZSBJbnRlcm5l dCBBc3NpZ25lZCBOdW1iZXIgQXV0aG9yaXR5IChJQU5BKQ0KICAgICAgICAgVW5pZm9ybSBSZXNv dXJjZSBJZGVudGlmaWVyIChVUkkpIFBhcmFtZXRlciBSZWdpc3RyeSBmb3IgdGhlDQogICAgICAg ICBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgKFNJUCkiLCBSRkMgMzk2OSwgQkNQIDk5LA0K ICAgICAgICAgRGVjZW1iZXIgMjAwNC4NCg0KICAgWzldICAgRnJlZWQsIE4uLCBCb3JlbnN0ZWlu LCBOLiwgTW9vcmUsIEsuLCBLbGVuc2luLCBKLiwgYW5kIEouDQogICAgICAgICBQb3N0ZWwsICJN dWx0aXB1cnBvc2UgSW50ZXJuZXQgTWFpbCBFeHRlbnNpb25zIChNSU1FKSIsDQogICAgICAgICBS RkMgMjA0NSwgUkZDIDIwNDYsIFJGQyAyMDQ3LCBSRkMgMjA0OCwgUkZDIDIwNDksDQogICAgICAg ICBOb3ZlbWJlciAxOTk2Lg0KDQogICBbMTBdICBEaWVya3MsIFQuIGFuZCBDLiBBbGxlbiwgIlRo ZSBUTFMgUHJvdG9jb2wiLCBSRkMgMjI0NiwNCiAgICAgICAgIEphbnVhcnkgMTk5OS4NCg0KICAg WzExXSAgSGFuZGxleSwgTS4gYW5kIFYuIEphY29ic29uLCAiU0RQOiBTZXNzaW9uIERlc2NyaXB0 aW9uDQogICAgICAgICBQcm90b2NvbCIsIFJGQyAyMzI3LCBBcHJpbCAxOTk4Lg0KDQoNCg0KDQoN Cg0KDQoNCg0KQ29vayAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMCwgMjAw NiAgICAgICAgICAgICAgW1BhZ2UgMTJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgTGVtb25h ZGUgTXVsdGltZWRpYSBTdHJlYW1pbmcgICAgICAgICAgICAgTWF5IDIwMDYNCg0KDQpBdXRob3In cyBBZGRyZXNzDQoNCiAgIE5laWwgTCBDb29rDQogICBPcGVud2F2ZSBTeXN0ZW1zDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KQ29vayAgICAgICAgICAgICAgICAgICAgRXhw aXJlcyBOb3ZlbWJlciAyMCwgMjAwNiAgICAgICAgICAgICAgW1BhZ2UgMTNdDQoMDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgTGVtb25hZGUgTXVsdGltZWRpYSBTdHJlYW1pbmcgICAgICAgICAgICAg TWF5IDIwMDYNCg0KDQpJbnRlbGxlY3R1YWwgUHJvcGVydHkgU3RhdGVtZW50DQoNCiAgIFRoZSBJ RVRGIHRha2VzIG5vIHBvc2l0aW9uIHJlZ2FyZGluZyB0aGUgdmFsaWRpdHkgb3Igc2NvcGUgb2Yg YW55DQogICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIG9yIG90aGVyIHJpZ2h0cyB0aGF0 IG1pZ2h0IGJlIGNsYWltZWQgdG8NCiAgIHBlcnRhaW4gdG8gdGhlIGltcGxlbWVudGF0aW9uIG9y IHVzZSBvZiB0aGUgdGVjaG5vbG9neSBkZXNjcmliZWQgaW4NCiAgIHRoaXMgZG9jdW1lbnQgb3Ig dGhlIGV4dGVudCB0byB3aGljaCBhbnkgbGljZW5zZSB1bmRlciBzdWNoIHJpZ2h0cw0KICAgbWln aHQgb3IgbWlnaHQgbm90IGJlIGF2YWlsYWJsZTsgbm9yIGRvZXMgaXQgcmVwcmVzZW50IHRoYXQg aXQgaGFzDQogICBtYWRlIGFueSBpbmRlcGVuZGVudCBlZmZvcnQgdG8gaWRlbnRpZnkgYW55IHN1 Y2ggcmlnaHRzLiAgSW5mb3JtYXRpb24NCiAgIG9uIHRoZSBwcm9jZWR1cmVzIHdpdGggcmVzcGVj dCB0byByaWdodHMgaW4gUkZDIGRvY3VtZW50cyBjYW4gYmUNCiAgIGZvdW5kIGluIEJDUCA3OCBh bmQgQkNQIDc5Lg0KDQogICBDb3BpZXMgb2YgSVBSIGRpc2Nsb3N1cmVzIG1hZGUgdG8gdGhlIElF VEYgU2VjcmV0YXJpYXQgYW5kIGFueQ0KICAgYXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0byBiZSBt YWRlIGF2YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBhbg0KICAgYXR0ZW1wdCBtYWRlIHRvIG9i dGFpbiBhIGdlbmVyYWwgbGljZW5zZSBvciBwZXJtaXNzaW9uIGZvciB0aGUgdXNlIG9mDQogICBz dWNoIHByb3ByaWV0YXJ5IHJpZ2h0cyBieSBpbXBsZW1lbnRlcnMgb3IgdXNlcnMgb2YgdGhpcw0K ICAgc3BlY2lmaWNhdGlvbiBjYW4gYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBvbi1saW5lIElQ UiByZXBvc2l0b3J5IGF0DQogICBodHRwOi8vd3d3LmlldGYub3JnL2lwci4NCg0KICAgVGhlIElF VEYgaW52aXRlcyBhbnkgaW50ZXJlc3RlZCBwYXJ0eSB0byBicmluZyB0byBpdHMgYXR0ZW50aW9u IGFueQ0KICAgY29weXJpZ2h0cywgcGF0ZW50cyBvciBwYXRlbnQgYXBwbGljYXRpb25zLCBvciBv dGhlciBwcm9wcmlldGFyeQ0KICAgcmlnaHRzIHRoYXQgbWF5IGNvdmVyIHRlY2hub2xvZ3kgdGhh dCBtYXkgYmUgcmVxdWlyZWQgdG8gaW1wbGVtZW50DQogICB0aGlzIHN0YW5kYXJkLiAgUGxlYXNl IGFkZHJlc3MgdGhlIGluZm9ybWF0aW9uIHRvIHRoZSBJRVRGIGF0DQogICBpZXRmLWlwckBpZXRm Lm9yZy4NCg0KDQpEaXNjbGFpbWVyIG9mIFZhbGlkaXR5DQoNCiAgIFRoaXMgZG9jdW1lbnQgYW5k IHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGFyZSBwcm92aWRlZCBvbiBhbg0KICAg IkFTIElTIiBiYXNpcyBhbmQgVEhFIENPTlRSSUJVVE9SLCBUSEUgT1JHQU5JWkFUSU9OIEhFL1NI RSBSRVBSRVNFTlRTDQogICBPUiBJUyBTUE9OU09SRUQgQlkgKElGIEFOWSksIFRIRSBJTlRFUk5F VCBTT0NJRVRZIEFORCBUSEUgSU5URVJORVQNCiAgIEVOR0lORUVSSU5HIFRBU0sgRk9SQ0UgRElT Q0xBSU0gQUxMIFdBUlJBTlRJRVMsIEVYUFJFU1MgT1IgSU1QTElFRCwNCiAgIElOQ0xVRElORyBC VVQgTk9UIExJTUlURUQgVE8gQU5ZIFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBPRiBUSEUNCiAgIElO Rk9STUFUSU9OIEhFUkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBBTlkgUklHSFRTIE9SIEFOWSBJTVBM SUVEDQogICBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBPUiBGSVRORVNTIEZPUiBBIFBB UlRJQ1VMQVIgUFVSUE9TRS4NCg0KDQpDb3B5cmlnaHQgU3RhdGVtZW50DQoNCiAgIENvcHlyaWdo dCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDYpLiAgVGhpcyBkb2N1bWVudCBpcyBzdWJq ZWN0DQogICB0byB0aGUgcmlnaHRzLCBsaWNlbnNlcyBhbmQgcmVzdHJpY3Rpb25zIGNvbnRhaW5l ZCBpbiBCQ1AgNzgsIGFuZA0KICAgZXhjZXB0IGFzIHNldCBmb3J0aCB0aGVyZWluLCB0aGUgYXV0 aG9ycyByZXRhaW4gYWxsIHRoZWlyIHJpZ2h0cy4NCg0KDQpBY2tub3dsZWRnbWVudA0KDQogICBG dW5kaW5nIGZvciB0aGUgUkZDIEVkaXRvciBmdW5jdGlvbiBpcyBjdXJyZW50bHkgcHJvdmlkZWQg YnkgdGhlDQogICBJbnRlcm5ldCBTb2NpZXR5Lg0KDQoNCg0KDQpDb29rICAgICAgICAgICAgICAg ICAgICBFeHBpcmVzIE5vdmVtYmVyIDIwLCAyMDA2ICAgICAgICAgICAgICBbUGFnZSAxNF0NCgwN Cg0K ------_=_NextPart_001_01C6844B.F9D38F6B Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade ------_=_NextPart_001_01C6844B.F9D38F6B-- From lemonade-bounces@ietf.org Tue May 30 23:32:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlHR8-0003S6-9s; Tue, 30 May 2006 23:31:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlHR6-0003Rv-Df for lemonade@ietf.org; Tue, 30 May 2006 23:31:56 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlHR4-00081g-2A for lemonade@ietf.org; Tue, 30 May 2006 23:31:56 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4V3VOvu011255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 30 May 2006 20:31:24 -0700 Received: from [172.28.175.180] (vpn-10-50-16-170.qualcomm.com [10.50.16.170]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4V3VLOB018410; Tue, 30 May 2006 20:31:22 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <0FA975F2D8295A448BE3ADC1612446570C6DD4@esebe199.NOE.Nokia.com> References: <0FA975F2D8295A448BE3ADC1612446570C6DD4@esebe199.NOE.Nokia.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Tue, 30 May 2006 12:10:59 -0700 To: , , From: Randall Gellens Subject: RE: [lemonade] Notifications Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.2 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 11:25 AM +0300 5/26/06, wrote: > -----Original Message----- > From: ext Randall Gellens [mailto:randy@qualcomm.com] > Sent: 25 May, 2006 04:45 > To: Ordogh Zoltan (Nokia-TP-MSW/Tampere);=20 > dave@cridland.net; lemonade@ietf.org > Subject: RE: [lemonade] Notifications > > At 12:09 PM +0300 5/22/06, wrote: > >> My understanding is that SIEVE or VFOLDER are simply filters - they >> do not provide notifications, they simply filter which emails need to >> be notified to the client (either online or offline) and if something >> has passed the filter, the server will send the notification about >> those emails that passed the filters. > > Not exactly. Sieve has rules that trigger=20 > actions. One of the actions can be to send a=20 > notification. > > [Z=D6r] SIEVE is responsible for triggering the=20 > notification only - not for sending it, right? My understanding is that the Sieve implementation=20 will send notifications. Sieve extensions are=20 used to indicate that a notification is to be=20 sent. How it is sent will depend on the Sieve=20 implementation, for example, it might support SMS. > >> So, in the end, when an email has passed the notification filters, >> the server will check whether the client is online or offline. If >> online: no problem with inband notification; if offline: the server >> will look up the client's offline notification settings, and send the >> notification accordingly. > > I'm not aware that Sieve has any knowledge of=20 > the connected state of any client. My=20 > understanding is that Sieve rules might say=20 > "send notification to address foo", regardless=20 > if a client at address foo happens to be=20 > connected to the IMAP server at that moment. > > [Z=D6r] SIEVE triggers the notification only,=20 > isn't it? When the server is told that some=20 > mail needs to be notified, the server will=20 > check the online/offline state (not the SIEVE=20 > script). However, the SIEVE script could be=20 > also enhanced with built-in variables (like=20 > HAS_SESSION, IS_CONNECTED, etc whatever the=20 > syntax of SIEVE is) and then the SIEVE script=20 > could make the decisions as well. Server=20 > implementation people have more experience=20 > about which one would be better and why. Enhancements to Sieve should be discussed in the=20 Sieve group. But there are always edge cases in=20 doing this, for example, the client could connect=20 or disconnect to the IMAP server immediately=20 after the Sieve script has tested the condition.=20 We'd want to make sure that any added complexity=20 to Sieve is worth it. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Dogs have owners. Cats have staff. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue May 30 23:54:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlHn4-0003ZQ-Dv; Tue, 30 May 2006 23:54:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlHn2-0003ZK-RU for lemonade@ietf.org; Tue, 30 May 2006 23:54:36 -0400 Received: from rgminet01.oracle.com ([148.87.113.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlHn0-0001JD-FS for lemonade@ietf.org; Tue, 30 May 2006 23:54:36 -0400 Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k4V3sWL2017117 for ; Tue, 30 May 2006 21:54:33 -0600 Received: from us.oracle.com (dhcp-amer-whq-csvpn-gw3-141-144-80-93.vpn.oracle.com [141.144.80.93]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k4V3sTW3005939 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 30 May 2006 21:54:32 -0600 From: "Stephane H. Maes" To: "Enhancements to Internet email to support diverse service enivronments" Subject: RE: [lemonade] Profile extensions "under discussion" Date: Tue, 30 May 2006 20:54:29 -0700 Organization: Oracle Message-ID: <20060530205429046.00000005016@smaes-lap3> In-Reply-To: <8556.1148543894.731843@peirce.dave.cridland.net> X-Mailer: Oracle Connector for Outlook 10.1.2.0.3 71207 (11.0.8010) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "stephane.maes@oracle.com" List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Yes I do not believe that his si what we have decided... Note however the proposal to dea with this in draft-ietf-lemonade-convert-0= 3. Thanks Stephane = _____ Stephane H. Maes, PhD, Director of Architecture, Mobile, Voice, and Communications Platforms, Orac= le. Ph: +1-203-300-7786 (mobile/SMS); Fax / Office UM: +1-650-607-6296 e-mail: stephane.maes@oracle.com IM: shmaes (AIM/Y!/skype) or stephane_maes@hotmail.com (MSN Messenger) or s= tephane.maes@gmail.com (Google) -----Original Message----- From: Dave Cridland [mailto:dave@cridland.net] = Sent: Thursday, May 25, 2006 12:58 AM To: Randall Gellens Cc: Enhancements to Internet email to support diverse service enivronments Subject: Re: [lemonade] Profile extensions "under discussion" On Thu May 25 02:44:49 2006, Randall Gellens wrote: > At 5:42 PM +0100 5/19/06, Dave Cridland wrote: > >> 6) TLS compression / Deflate etc. >> >> Included Everything: I don't feel there is any clear consensus on = >> compression. My working copy currently has a section on compression = >> in IMAP which includes two alternate paragraphs for LZIP and = >> COMPRESS=3DDEFLATE. > > My sense was that Ned and several others made compelling arguments = > that we should go with something like DEFLATE, and that there was no = > benefit to per-object client control, since there were no cases where = > a client capable of decompression would not want it when the server = > thought an object would benefit from it. Therefore DEFLATE controlled = > by a single command from the client that says "compress at will". > > That was my thought too, but the minutes (which include an Action for Pete = to summarize the positions to "sharpen consensus"), and the slides from Lem= onade Day 2 of IETF65, don't seem to quite indicate that. >> 8) Proxy / firewalls >> >> Informative: I'll include the document as an informative reference. > > Which document? Firewall traversal using HTTP. Deployments is currently referenced, too. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue May 30 23:55:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlHnV-0003an-KC; Tue, 30 May 2006 23:55:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlHnU-0003ai-Rb for lemonade@ietf.org; Tue, 30 May 2006 23:55:04 -0400 Received: from rgminet01.oracle.com ([148.87.113.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlHnT-0001Jm-Fx for lemonade@ietf.org; Tue, 30 May 2006 23:55:04 -0400 Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k4V3t2i0017606 for ; Tue, 30 May 2006 21:55:02 -0600 Received: from us.oracle.com (dhcp-amer-whq-csvpn-gw3-141-144-80-93.vpn.oracle.com [141.144.80.93]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k4V3sxDF018277 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 30 May 2006 21:55:01 -0600 From: "Stephane H. Maes" To: "Enhancements to Internet email to support diverse service enivronments" Subject: RE: [lemonade] Profile extensions "under discussion" Date: Tue, 30 May 2006 20:54:58 -0700 Organization: Oracle Message-ID: <20060530205458578.00000005016@smaes-lap3> In-Reply-To: <8556.1148543894.731843@peirce.dave.cridland.net> X-Mailer: Oracle Connector for Outlook 10.1.2.0.3 71207 (11.0.8010) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "stephane.maes@oracle.com" List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org = >>8) Proxy / firewalls >> >> Informative: I'll include the document as an informative reference. > > Which document? Firewall traversal using HTTP. Deployments is currently referenced, too. ---- This has become Lemonade in TCP Challenged Environment as in draft-maes-lem= onade-tcp-challenged-environments-00. _____ Stephane H. Maes, PhD, Director of Architecture, Mobile, Voice, and Communications Platforms, Orac= le. Ph: +1-203-300-7786 (mobile/SMS); Fax / Office UM: +1-650-607-6296 e-mail: stephane.maes@oracle.com IM: shmaes (AIM/Y!/skype) or stephane_maes@hotmail.com (MSN Messenger) or s= tephane.maes@gmail.com (Google) -----Original Message----- From: Dave Cridland [mailto:dave@cridland.net] = Sent: Thursday, May 25, 2006 12:58 AM To: 'Randall Gellens' Cc: 'Enhancements to Internet email to support diverse service enivronments= ' Subject: Re: [lemonade] Profile extensions "under discussion" On Thu May 25 02:44:49 2006, Randall Gellens wrote: > At 5:42 PM +0100 5/19/06, Dave Cridland wrote: > >> 6) TLS compression / Deflate etc. >> >> Included Everything: I don't feel there is any clear consensus on = >> compression. My working copy currently has a section on compression = >> in IMAP which includes two alternate paragraphs for LZIP and = >> COMPRESS=3DDEFLATE. > > My sense was that Ned and several others made compelling arguments = > that we should go with something like DEFLATE, and that there was no = > benefit to per-object client control, since there were no cases where = > a client capable of decompression would not want it when the server = > thought an object would benefit from it. Therefore DEFLATE controlled = > by a single command from the client that says "compress at will". > > That was my thought too, but the minutes (which include an Action for Pete = to summarize the positions to "sharpen consensus"), and the slides from Lem= onade Day 2 of IETF65, don't seem to quite indicate that. >> 8) Proxy / firewalls >> >> Informative: I'll include the document as an informative reference. > > Which document? Firewall traversal using HTTP. Deployments is currently referenced, too. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 31 04:34:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlMA5-0003O8-Ru; Wed, 31 May 2006 04:34:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlMA4-0003O3-Mc for lemonade@ietf.org; Wed, 31 May 2006 04:34:40 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlMA2-0002X6-64 for lemonade@ietf.org; Wed, 31 May 2006 04:34:40 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4V8YT2U028267 for ; Wed, 31 May 2006 11:34:37 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 11:34:21 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 11:34:21 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-03.txt Date: Wed, 31 May 2006 11:34:09 +0300 Message-ID: <0FA975F2D8295A448BE3ADC16124465725F671@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-03.txt Thread-Index: AcaEO4/hVFbUxxDVTuWSS32Q7M1RmQAUQqKA From: To: X-OriginalArrivalTime: 31 May 2006 08:34:21.0490 (UTC) FILETIME=[03C16920:01C6848D] X-Spam-Score: 0.2 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Stephane, I am looking for clarification. What is the purpose of section 10. Compression? I mean what does it have to do with the conversion draft? I thought = compression is applicable to anything. As such, it is not necessary to = describe it in this draft. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan.ordogh at nokia.com Phone: +358 50 386 0566 -----Original Message----- From: ext lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org]=20 Sent: 31 May, 2006 01:50 To: i-d-announce@ietf.org Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-03.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Enhancements to Internet email to = support diverse service environments Working Group of the IETF. Title : CONVERT Author(s) : S. Maes, R. Cromwell Filename : draft-ietf-lemonade-convert-03.txt Pages : 18 Date : 2006-5-30 =09 CONVERT defines extensions to the IMAPv4 Rev1 protocol [RFC3501] for = optimization in a mobile setting, aimed at allowing adaptation and = transcoding of attachments as needed by the client. Conversion = (adaptation, transcoding) may be requested by the client and performed = by the server on a best effort basis or decided by the server based on = its knowledge of the client capabilities, user or administrator = preferences or its settings. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-convert-03.txt To remove yourself from the I-D Announcement list, send a message to = i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After = logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-convert-03.txt". A list of Internet-Drafts directories can be found in = http://www.ietf.org/shadow.html or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-convert-03.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 31 04:38:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlMDM-0004pD-O0; Wed, 31 May 2006 04:38:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlMDL-0004p7-F2 for lemonade@ietf.org; Wed, 31 May 2006 04:38:03 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlMDJ-00031a-VQ for lemonade@ietf.org; Wed, 31 May 2006 04:38:03 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4V8bvlO007192 for ; Wed, 31 May 2006 11:38:01 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 11:38:00 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 11:38:00 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-search-within-01.txt Date: Wed, 31 May 2006 11:37:47 +0300 Message-ID: <0FA975F2D8295A448BE3ADC16124465725F67B@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] I-D ACTION:draft-ietf-lemonade-search-within-01.txt Thread-Index: AcaEO4/CTCxfhYKER/KLzfPvr4/DGQAUcoww From: To: X-OriginalArrivalTime: 31 May 2006 08:38:00.0063 (UTC) FILETIME=[860900F0:01C6848D] X-Spam-Score: 0.2 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Stephane, Now that the "WITHIN" is gone, will this draft be still called WITHIN? Thank You. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan.ordogh at nokia.com Phone: +358 50 386 0566 -----Original Message----- From: ext lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org]=20 Sent: 31 May, 2006 01:50 To: i-d-announce@ietf.org Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-search-within-01.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Enhancements to Internet email to = support diverse service environments Working Group of the IETF. Title : WITHIN Search extension to the IMAP Protocol Author(s) : S. Maes, R. Cromwell Filename : draft-ietf-lemonade-search-within-01.txt Pages : 5 Date : 2006-5-30 =09 WITHIN is an extension to [RFC3501] SEARCH which returns messages=20 whose internal date is within or outside a specified interval and=20 differs from SINCE in that an interval in days is specified instead=20 of a date. WITHIN is expected to be most useful for persistent=20 searches in combination with mobile devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-search-within-01.= txt To remove yourself from the I-D Announcement list, send a message to = i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After = logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-search-within-01.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-search-within-01.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 31 06:04:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlNYL-00037q-Mv; Wed, 31 May 2006 06:03:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlNYK-00037l-K0 for lemonade@ietf.org; Wed, 31 May 2006 06:03:48 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlNYK-0002of-Hs for lemonade@ietf.org; Wed, 31 May 2006 06:03:48 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FlNXn-0004e8-I6 for lemonade@ietf.org; Wed, 31 May 2006 06:03:17 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4VA3Dha000405 for ; Wed, 31 May 2006 13:03:13 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 13:03:10 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 13:03:07 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt Date: Wed, 31 May 2006 13:02:55 +0300 Message-ID: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt Thread-Index: AcaEO5WchgMnCSmiShOMiq7J99TwDAAVLYmQ From: To: X-OriginalArrivalTime: 31 May 2006 10:03:07.0911 (UTC) FILETIME=[6A8CC170:01C68499] X-Spam-Score: -2.6 (--) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Stephane, Few comments: - what is a "potentially large or high velocity mailbox"=20 - "APPEND/COPY to a vfolder SHOULD be supported as well, but may not on = some implementations" - how does one determine whether it is supported = or not? - "a vfolder should appear to function as a regular mailbox" Question: = Can one create a VFOLDER based on a VFOLDER? - "A server which supports LVFOLDER" -> "A server which supports = VFOLDER" - "S: a2 OK CREATE LPSEARCH Completed" -> "S: a2 OK CREATE VFOLDER = Completed" - "existing vfolders which reference the mailbox should be deleted and = not" -> "existing vfolders which reference the mailbox MUST be deleted = and MUST NOT" - "server MAY treat it in the same way as a DELETE command by removing = all vfolders attached to the old mailbox name, OR it MAY track the new = name and modify all dependent vfolders to use the new folder name" Would = it be possible to mandate updating the vfolders to use the new name = instead and disallow deletions? It would be better for user experience = and interoperability. - "MAY be used to append/copy messages to vfolder, depending on the = implementation" Could we drop ", depending on the implementation" from = this sentence? - "A NO response should be generated if the server lacks APPEND/COPY = support on VFOLDER." What is the reason for not making this a MUST? - "Servers SHOULD expunge only the messages visible in the view, or MAY = expunge the entire mailbox. The former is more desirable, if possible." = Could we make the first one mandatory and get rid of the latter one? It = would be better for user experience and interoperability. - "The i right (COPY/APPEND) MAY or MAY NOT be granted on a view." -> = "The 'i' right (COPY/APPEND) MAY or MAY NOT be granted on a view." Also, = what does MAY NOT mean? It MUST be either granted or not (like any other = right), so is this sentence useful? - "However, it may or may not consider the underlying mailbox ACL," Same = comment as above about the "may or may not". - "Clients wishing to check if a message is a duplicate at..." Compating = headers vs the local database consumes memory, processing power, and = ultimately battery power. Would it be possible to do this on the server = side and make sure that duplicate mails always have the same UID? Or, = add a new flag 'LEMONADE-Duplicate-Of:' and include the old UID there? = It should not be in a future version. - The WITHIN extension is referenced and the WITHIN command is used in = example(s) in section 6: "C: a2 CREATE mobile (VFOLDER (INBOX FROM = "boss@mycompany.com" WITHIN 3))" - however the WITHIN extension does not = have such comment (the latest draft). Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan.ordogh at nokia.com Phone: +358 50 386 0566 -----Original Message----- From: ext lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org]=20 Sent: 31 May, 2006 01:50 To: i-d-announce@ietf.org Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Enhancements to Internet email to = support diverse service environments Working Group of the IETF. Title : Persistent Virtual Folder extension to the IMAP Protocol Author(s) : S. Maes, et al. Filename : draft-ietf-lemonade-vfolder-01.txt Pages : 12 Date : 2006-5-30 =09 Persistent Extensions to the IMAP Protocol (LPSEARCH) defines extension = parameters to the [RFC3501] CREATE command to allow virtual mailboxes to = be created which are views of other mailboxes narrowed by search = criteria. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-vfolder-01.txt To remove yourself from the I-D Announcement list, send a message to = i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After = logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-vfolder-01.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-vfolder-01.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 31 07:41:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlP4t-00032s-Um; Wed, 31 May 2006 07:41:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlP4s-00032c-I2 for lemonade@ietf.org; Wed, 31 May 2006 07:41:30 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlP4q-0003Yv-LP for lemonade@ietf.org; Wed, 31 May 2006 07:41:30 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 749654AC30; Wed, 31 May 2006 13:41:01 +0200 (CEST) Message-Id: Date: Wed, 31 May 2006 13:41:28 +0200 From: Arnt Gulbrandsen To: "Stephane H. Maes" , lemonade@ietf.org Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> In-Reply-To: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Stephane, here's a few comments from me too. Most of this would benefit from other people's comment, so I'm sending it to the list as well as directly to you. I see you've merged my VIEW into VFOLDER and added me as author. Fine with me. The vfolder-01 draft is IMO perfectly adequate. I'll modify my VIEW implementation to be a VFOLDER implementation. Some nits. Some text refers to view instead of vfolder and to underlying instead of backing. Better change that. (I actually think backing is the better term and would have used that if I'd thought of it.) The Abstract says LPSEARCH where it shouldn't. In section 2, the term "high velocity" is a little odd, I'd prefer "frequently changing". The final sentence of section 4 uses the verb "correct"; I think "modify" is a better word there. The draft uses the word folder throughout. In IMAP, the word mailbox is used. (I don't know why, though, perhaps Mark can elaborate?) Anyway, I think there is value in consistency, ie. it's better to say mailbox than folder simply because that's what RFC 3501 says. (I'm using vfolder, not vmailbox, here, because in a message about vfolder-01, I'd better be consistent with _its_ terminology.) And there are some substantive issues. 1. APPEND/COPY. In section 1 and 8, APPEND and COPY are explicitly permitted on vfolders. I think that's desirable, but there's a problem, perhaps a nasty one: A client may expect that if it appends/copies a message to a mailbox, that message shows up in that mailbox. If the mailbox happens to be a vfolder and the message doesn't match the search, the message may (apparently) disappear without a trace. There are three possibilities: Either the message must be made to fit the search (e.g. by setting the right flags if the search uses flags), or the search must be modified to include that message's UID, or the WG considers it acceptable that the message sometimes goes only to the backing mailbox, not to the vfolder. Personally, I think the first two are horrid and strongly favour the latter, I'm just a little nervous that it might confuse some IMAP clients. Section 8 should probably get a sentence or paragraph on this, once there's consensus. 2. VFOLDER on VFOLDER. In section 2, a vfolders may be created with another vfolder as backing. I don't see a use-case for that, and I do see one drawback, namely that it complicates making a vfolder "users.stephane.blah" with "users.stephane.*" as backing. The present draft does not permit multi-mailbox backing, but I don't expect that state of affairs to last very long. People want multi-mailbox backing. More on that below. Can anyone think of a use-case or other argument for allowing vfolders on vfolders? 3. ACL. In the security considerations, the ACL issue needs mentioning. 4. Catchall vfolders. One thing people ask for is a way to catch the rest of the mail. Suppose you sort your inbox into seven vfolders. What happens to the messages that fit none of the seven searches? The answer is a vfolder catching the rest, e.g. "INBOX.other" with has search expression "UNKEYWORD $Spam NOT INVFOLDER" (showing all messages which don't have the $spam flag and which aren't in any other view). I can supply exact text for INVFOLDER, but not right now. (It's a little bit tricky, since if the MUA selects the catchall vfolder before it has selected all of the others, the server may not have updated the others with the most recent messages yet, so some messages may appear to not be in any view.) 5. Vfolders with multiple backing mailboxes. People want it. If you look at e.g. Apple Mail, it has that feature and people use it. I didn't specify anything in the VIEW draft because I didn't know how it ought to be done. The key question is how to specify the backing. Should the backing be specified as a mailbox name prefix, as a wildcard pattern, as a list of mailboxes or perhaps as "all mailboxes I own"? There are arguments for all four. The main difference is what happens when mailboxes are created or renamed. I'd like to hear what people on this list would use themselves, and what they think would be useful in general. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 31 07:50:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlPDd-0001VD-2O; Wed, 31 May 2006 07:50:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlPDb-0001Qo-SG for lemonade@ietf.org; Wed, 31 May 2006 07:50:31 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlPDa-0005M4-E6 for lemonade@ietf.org; Wed, 31 May 2006 07:50:31 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 71C7C4AC30; Wed, 31 May 2006 13:50:29 +0200 (CEST) Message-Id: Date: Wed, 31 May 2006 13:51:01 +0200 From: Arnt Gulbrandsen To: "Stephane H. Maes" , lemonade@ietf.org Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Arnt Gulbrandsen writes: > 5. Vfolders with multiple backing mailboxes. > > People want it. If you look at e.g. Apple Mail, it has that feature > and people use it. I didn't specify anything in the VIEW draft > because I didn't know how it ought to be done. > > The key question is how to specify the backing. Should the backing be > specified as a mailbox name prefix, as a wildcard pattern, as a list > of mailboxes or perhaps as "all mailboxes I own"? There are arguments > for all four. The main difference is what happens when mailboxes are > created or renamed. > > I'd like to hear what people on this list would use themselves, and > what they think would be useful in general. Ack. I forgot that ACL becomes a twisted maze once a vfolder has multiple backing mailboxes with potentially different owners or ACLs. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 31 08:10:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlPWi-0001Cy-Gm; Wed, 31 May 2006 08:10:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlPWg-0001Cb-Px for lemonade@ietf.org; Wed, 31 May 2006 08:10:14 -0400 Received: from rgminet01.oracle.com ([148.87.113.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlPWf-0006nk-E5 for lemonade@ietf.org; Wed, 31 May 2006 08:10:14 -0400 Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k4VCACGI015970 for ; Wed, 31 May 2006 06:10:12 -0600 Received: from us.oracle.com (dhcp-amer-rmdc-csvpn-gw5-141-144-104-163.vpn.oracle.com [141.144.104.163]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k4VCAAQq018899 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 31 May 2006 06:10:11 -0600 From: "Stephane H. Maes" To: "lemonade@ietf.org" Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-03.txt Date: Wed, 31 May 2006 05:10:07 -0700 Organization: Oracle Message-ID: <20060531051007531.00000005016@smaes-lap3> In-Reply-To: <0FA975F2D8295A448BE3ADC16124465725F671@esebe199.NOE.Nokia.com> X-Mailer: Oracle Connector for Outlook 10.1.2.0.3 71207 (11.0.8010) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-Spam-Score: 0.5 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "stephane.maes@oracle.com" List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org We decided in Dallas to consider object level compression via convert. Stephane = _____ Stephane H. Maes, PhD, Director of Architecture, Mobile, Voice, and Communications Platforms, Orac= le. Ph: +1-203-300-7786 (mobile/SMS); Fax / Office UM: +1-650-607-6296 e-mail: stephane.maes@oracle.com IM: shmaes (AIM/Y!/skype) or stephane_maes@hotmail.com (MSN Messenger) or s= tephane.maes@gmail.com (Google) -----Original Message----- From: Zoltan.Ordogh@nokia.com [mailto:Zoltan.Ordogh@nokia.com] = Sent: Wednesday, May 31, 2006 1:34 AM To: lemonade@ietf.org Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-03.txt Hi Stephane, I am looking for clarification. What is the purpose of section 10. Compression? I mean what does it have to do with the conversion draft? I thought compres= sion is applicable to anything. As such, it is not necessary to describe it= in this draft. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan.ordogh at nokia.com Phone: +358 50 386 0566 -----Original Message----- From: ext lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] Sent: 31 May, 2006 01:50 To: i-d-announce@ietf.org Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-03.txt = A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Enhancements to Internet email to support = diverse service environments Working Group of the IETF. Title : CONVERT Author(s) : S. Maes, R. Cromwell Filename : draft-ietf-lemonade-convert-03.txt Pages : 18 Date : 2006-5-30 = CONVERT defines extensions to the IMAPv4 Rev1 protocol [RFC3501] for optimi= zation in a mobile setting, aimed at allowing adaptation and transcoding of= attachments as needed by the client. Conversion (adaptation, transcoding) = may be requested by the client and performed by the server on a best effort= basis or decided by the server based on its knowledge of the client capabi= lities, user or administrator preferences or its settings. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-convert-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-an= nounce-request@ietf.org with the word unsubscribe in the body of the messag= e. = You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the usernam= e "anonymous" and a password of your e-mail address. After logging in, type= "cd internet-drafts" and then "get draft-ietf-lemonade-convert-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/s= hadow.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-convert-03.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 implementa= tion to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 31 08:53:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlQB0-0005tf-Eo; Wed, 31 May 2006 08:51:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlQAz-0005tZ-SM for lemonade@ietf.org; Wed, 31 May 2006 08:51:53 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlQAy-0001cr-AD for lemonade@ietf.org; Wed, 31 May 2006 08:51:53 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4VCpl99014913; Wed, 31 May 2006 15:51:49 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 15:51:16 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 15:51:16 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-03.txt Date: Wed, 31 May 2006 15:51:03 +0300 Message-ID: <0FA975F2D8295A448BE3ADC16124465725FAFA@esebe199.NOE.Nokia.com> In-Reply-To: <20060531051007531.00000005016@smaes-lap3> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-03.txt Thread-Index: AcaEq7xjfAZdb6lTTLCfdMjO8kA0pAABQr0A From: To: , X-OriginalArrivalTime: 31 May 2006 12:51:16.0681 (UTC) FILETIME=[E7ECE390:01C684B0] X-Spam-Score: 0.2 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Aha, I knew I was missing something, thank You. So it means that now the client needs to request compression explicitly = every time, right? Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan.ordogh at nokia.com Phone: +358 50 386 0566 -----Original Message----- From: ext Stephane H. Maes [mailto:stephane.maes@oracle.com]=20 Sent: 31 May, 2006 15:10 To: lemonade@ietf.org Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-03.txt We decided in Dallas to consider object level compression via convert. Stephane=20 _____ Stephane H. Maes, PhD, Director of Architecture, Mobile, Voice, and Communications Platforms, = Oracle. Ph: +1-203-300-7786 (mobile/SMS); Fax / Office UM: +1-650-607-6296 e-mail: stephane.maes@oracle.com IM: shmaes (AIM/Y!/skype) or stephane_maes@hotmail.com (MSN Messenger) = or stephane.maes@gmail.com (Google) -----Original Message----- From: Zoltan.Ordogh@nokia.com [mailto:Zoltan.Ordogh@nokia.com] Sent: Wednesday, May 31, 2006 1:34 AM To: lemonade@ietf.org Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-03.txt Hi Stephane, I am looking for clarification. What is the purpose of section 10. Compression? I mean what does it have to do with the conversion draft? I thought = compression is applicable to anything. As such, it is not necessary to = describe it in this draft. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan.ordogh at nokia.com Phone: +358 50 386 0566 -----Original Message----- From: ext lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] Sent: 31 May, 2006 01:50 To: i-d-announce@ietf.org Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-03.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Enhancements to Internet email to = support diverse service environments Working Group of the IETF. Title : CONVERT Author(s) : S. Maes, R. Cromwell Filename : draft-ietf-lemonade-convert-03.txt Pages : 18 Date : 2006-5-30 =09 CONVERT defines extensions to the IMAPv4 Rev1 protocol [RFC3501] for = optimization in a mobile setting, aimed at allowing adaptation and = transcoding of attachments as needed by the client. Conversion = (adaptation, transcoding) may be requested by the client and performed = by the server on a best effort basis or decided by the server based on = its knowledge of the client capabilities, user or administrator = preferences or its settings. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-convert-03.txt To remove yourself from the I-D Announcement list, send a message to = i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After = logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-convert-03.txt". A list of Internet-Drafts directories can be found in = http://www.ietf.org/shadow.html or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-convert-03.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader = implementation to automatically retrieve the ASCII version of the = Internet-Draft. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 31 09:10:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlQSF-00005f-Of; Wed, 31 May 2006 09:09:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlQSE-00005Z-2K for lemonade@ietf.org; Wed, 31 May 2006 09:09:42 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlQSA-0002pM-68 for lemonade@ietf.org; Wed, 31 May 2006 09:09:42 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Wed, 31 May 2006 13:59:20 +0100 Message-ID: <447D92EC.6060702@isode.com> Date: Wed, 31 May 2006 13:58:20 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: lemonade@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Subject: [lemonade] Jabber room for the Lemonade WG X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Is on the server: "jabber.ietf.org", not "rooms.jabber.ietf.org". _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 31 10:33:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlRla-00013L-6U; Wed, 31 May 2006 10:33:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlRlZ-00013F-FC for lemonade@ietf.org; Wed, 31 May 2006 10:33:45 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlRlX-0000bx-99 for lemonade@ietf.org; Wed, 31 May 2006 10:33:45 -0400 X-IronPort-AV: i="4.05,193,1146456000"; d="scan'208"; a="33482129:sNHT26740112" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 31 May 2006 10:33:41 -0400 Message-ID: <330A23D8336C0346B5C1A5BB1966664702F6CC86@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OMA Presentation on Lemonade Thread-Index: AcaEvzZDLm3lsrFrT9+5AFUYBomD5A== From: "Burger, Eric" To: "Enhancements to Internet email to support diverse serviceenivronments" X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [lemonade] OMA Presentation on Lemonade X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Do we want to use meeting time in Montreal for a presentation from the OMA on how they will use the lemonade RFC's to realize mobile e-mail? The chairs are leaning towards having face-to-face, non-meeting time in Montreal. Of course, the OMA MEM may not be ready in time for Montreal to give us a presentation, so this may be mute. Please send your thoughts to the list. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 31 11:01:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlSBw-0004k0-TA; Wed, 31 May 2006 11:01:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlSBv-0004jQ-D5 for lemonade@ietf.org; Wed, 31 May 2006 11:00:59 -0400 Received: from agminet01.oracle.com ([141.146.126.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlSBu-00052p-3Q for lemonade@ietf.org; Wed, 31 May 2006 11:00:59 -0400 Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k4VF0qGL019230; Wed, 31 May 2006 10:00:52 -0500 Received: from us.oracle.com (dhcp-amer-rmdc-csvpn-gw4-141-144-96-63.vpn.oracle.com [141.144.96.63]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k4VF0o19008358 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 31 May 2006 09:00:51 -0600 From: "Stephane H. Maes" To: "Burger, Eric" , "Enhancements to Internet email to support diverse serviceenivronments" Subject: RE: [lemonade] OMA Presentation on Lemonade Date: Wed, 31 May 2006 08:00:49 -0700 Organization: Oracle Message-ID: <20060531080049406.00000005884@smaes-lap3> In-Reply-To: <330A23D8336C0346B5C1A5BB1966664702F6CC86@ATLANTIS.Brooktrout.com> X-Mailer: Oracle Connector for Outlook 10.1.2.0.3 71207 (11.0.8010) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "stephane.maes@oracle.com" List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org It would be good if OMA can do. Montreal may be too early for them. We shou= ld ask them to do (when they can) and we will see... I don't mind it during or outside WG time. We should in any way have a shor= t WG discussion after the session. So if the session is not the WG session,= it should be before the last WG session... Thanks Stephane = _____ Stephane H. Maes, PhD, Director of Architecture, Mobile, Voice, and Communications Platforms, Orac= le. Ph: +1-203-300-7786 (mobile/SMS); Fax / Office UM: +1-650-607-6296 e-mail: stephane.maes@oracle.com IM: shmaes (AIM/Y!/skype) or stephane_maes@hotmail.com (MSN Messenger) or s= tephane.maes@gmail.com (Google) -----Original Message----- From: Burger, Eric [mailto:eburger@cantata.com] = Sent: Wednesday, May 31, 2006 7:34 AM To: Enhancements to Internet email to support diverse serviceenivronments Subject: [lemonade] OMA Presentation on Lemonade Do we want to use meeting time in Montreal for a presentation from the OMA = on how they will use the lemonade RFC's to realize mobile e-mail? The chairs are leaning towards having face-to-face, non-meeting time in Mon= treal. Of course, the OMA MEM may not be ready in time for Montreal to giv= e us a presentation, so this may be mute. Please send your thoughts to the list. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 31 11:14:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlSOq-0002RQ-Ay; Wed, 31 May 2006 11:14:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlSOo-0002RB-6B for lemonade@ietf.org; Wed, 31 May 2006 11:14:18 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlRSH-0007Yw-Is for lemonade@ietf.org; Wed, 31 May 2006 10:13:49 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FlRBi-0007uq-It for lemonade@ietf.org; Wed, 31 May 2006 09:56:47 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4VDudTA028381 for ; Wed, 31 May 2006 16:56:41 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 16:56:37 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 16:56:37 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-notifications-02.txt Date: Wed, 31 May 2006 16:56:23 +0300 Message-ID: <0FA975F2D8295A448BE3ADC16124465725FBB7@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] I-D ACTION:draft-ietf-lemonade-notifications-02.txt Thread-Index: AcaEO50//gNmXbq9TaO8/6IiRUJcCQAarh/A From: To: X-OriginalArrivalTime: 31 May 2006 13:56:37.0642 (UTC) FILETIME=[09000EA0:01C684BA] X-Spam-Score: -2.6 (--) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Stephane, a great step forward, thank You for the update. A few comments: - "generates a outband" -> "generates an outband" - "If the MUA is not connected, and outband notification is disabled, = the client must perform..." I do not see how this is a must. The client = may connect the determine the changes? - "If the MUA has only momentarily lost connection, it should also = attempt to use [RECONNECT]." The client has no control over loosing a = connection momentarily or otherwise, so I do not see how it helps the = notifications - what if it disconnected it intentionally? Outband = notifications will kick in anyway, right? I do not think such cases are = to be discussed in this draft - the RECONNECT draft is a better place to = do so. Also, this paragraph discusses the case when the client is = offline, so it should not be here anyway. - "appropriate format to a particular IP address and port." No = MSIDN/MDN? No SIP address? IP address might work for IP-based networks. = Or, was it meant to be the IP address of an "aggregator server" which is = ultimately responsible for sending out the notification for the right = place using the appropriate bearer? If so, how is it configured? - "The payload for wake-up notifications is the OMA EMN format" Is this = a must, should or a may? - "The mailbox URI formats are defined in [OMN-EN]" - no reference = found for OMN-EN: OMA-EN perhaps?. - "Example extended payload" This is not an extended payload, this is = the normal payload. - "the server MAY stop sending outband notifications" Can we change it = to something like "adaptively" stop? I mean that the notifications would = slow down (fade out) after a while, and in the end they might stop? - "10. Provisioning..." Is there any way for the server to indicate = that provisioning is not done using ANNOTATEMORE, but relies on an = external mechanism? (like OMA DM?) - "A client only needs to access = provision information once" Is this valid? Some things might be changed = on the server over time. We should not encourage this since it might = cause IOP problems in the long run. - "10.3. Preference Entries" Are these per-session settings? I mean: = can the client set it up its own settings for the current session only = and several sessions may co-exist with different preferences? - ""filter.priv" =3D "ALL" / "NEW" / "NONE"" I though that a SIEVE = script would do this. Should it be the filename (or some other = identifier) of a SIEVE script? (NIL if no filter, otherwise the ID of = the active filter.) SIEVE scripts could be stored on the server in a = common storage for the user, and the user could select for each session = separately which one is active during the current session. Or, am I = missing something? - Section 13, general question: I have difficulties understanding some = of the sentences here because I do not know what exactly the "messaging = system" in this context. Would it be possible to clarify this? - "which describe potential notification events" What makes a = notification event "potential"? - "sent to a notification mechanisms" -> "sent to a notification = mechanism" or "sent to notification mechanisms" - "while allowing the messaging system, not to be familiar with the end = user's notification preferences" -> "without the messaging system having = knowledge about the end user's notification preferences" What I do not = understand here is that how does the server know that a notification is = to be sent if it does not know what my preferences are. Or perhaps the = outband notification format and bearer settings are meant to be said = here? - "mechanisms are the entities which is familiar" -> "mechanisms are = the entities which are familiar" - "Using server to server notifications, allow the messaging system to = provide the end user, a unified notification experience" -> "The server = to server notifications allow the messaging system to provide the end = user a unified notification experience" - "suite of Internet mail protocols (POP3, IMAP4)" -> "suite of = Internet mail protocols (POP3, IMAP4, WebDAV, etc)" - "server to server notifications do not deal with the communications" = -> "server to server notifications do not deal directly with the = communications" - Figure 3 - should there be an additional box there which indicates = that the Notification Mechanism retrieves user preferences from the = server before choosing the appropriate notification route? - "notification request SHOULD contain data regarding" Isn't this a = MUST? - 13.3 terminology - should we move this up in the document? Would have = been more helpful in the beginning of this chapter. - "Within the context of Lemonade profile (Figure 1)," Isn't it = supposed to say Lemonade bis? - "Realize the messaging mecanisms'" -> "Realize the messaging = mechanisms'" - "The notification mechanisms SHOULD notify the messaging system = whenever" Why is it only a SHOULD? - "or generic server to server notifications, the order may matter" How = does a server determine about another server that the order does matter? -"MUST buffer the notifications" Does it apply to all notifications? I = mean, what's the benefit of buffering and providing "new mail" = notifications after the client connected and performed synch? - "It should be possible to authenticate sender and" -> "It should be = possible to authenticate the sender of the notification and" Thank You. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan.ordogh at nokia.com Phone: +358 50 386 0566 -----Original Message----- From: ext lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org]=20 Sent: 31 May, 2006 01:50 To: i-d-announce@ietf.org Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-notifications-02.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Enhancements to Internet email to = support diverse service environments Working Group of the IETF. Title : Lemonade notifications and filters Author(s) : R. Cromwell, S. Maes Filename : draft-ietf-lemonade-notifications-02.txt Pages : 25 Date : 2006-5-30 =09 This document discusses how to provide notification and filtering=20 mechanisms to IMAP [RFC3501] as part the Lemonade profile=20 [LEMONADEPROFILEBIS]. =20 =20 This document also discusses the use of Lemonade notifications to=20 implement server to server notifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-notifications-02.= txt To remove yourself from the I-D Announcement list, send a message to = i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After = logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-notifications-02.txt". A list of Internet-Drafts directories can be found in = http://www.ietf.org/shadow.html or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-notifications-02.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 31 11:22:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlSWs-0008Ek-5k; Wed, 31 May 2006 11:22:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlSWq-0008EB-HC for lemonade@ietf.org; Wed, 31 May 2006 11:22:36 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlSWp-0008CY-Av for lemonade@ietf.org; Wed, 31 May 2006 11:22:36 -0400 X-IronPort-AV: i="4.05,193,1146456000"; d="scan'208"; a="33484346:sNHT27698168" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 31 May 2006 11:22:32 -0400 Message-ID: <330A23D8336C0346B5C1A5BB1966664702F6CD47@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RECONNECT Thread-Index: AcaExglf4zHCqkZbQFWRzlqaCldD0g== From: "Burger, Eric" To: "Enhancements to Internet email to support diverse serviceenivronments" X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [lemonade] RECONNECT X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dave and Alexey realized that it is the same number of bytes and round-trips to have the client store the state for reconnect than to have the server store the state. Alexey believes it is a small number of edits to make the change to the document. Because of our short time-lines, we will not abandon the server-side RECONNECT mechanism. Rather, we will have a new document, draft-ietf-lemonade-reconnect-client, that will describe the client-side mechanism. The work group will examine both drafts and preferably pick one approach. That approach will go standards-track while the other will die. Less preferably, we can keep both drafts, make one Experimental, and reference the standards-track document in Profile bis. Least preferably, we go with both drafts. Thoughts? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 31 12:37:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlThT-0007ah-Os; Wed, 31 May 2006 12:37:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlThS-0007ac-OQ for lemonade@ietf.org; Wed, 31 May 2006 12:37:38 -0400 Received: from nwkea-mail-5.sun.com ([192.18.42.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlThP-000734-AL for lemonade@ietf.org; Wed, 31 May 2006 12:37:38 -0400 Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwkea-mail-5.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k4VGbV6W021993; Wed, 31 May 2006 09:37:31 -0700 (PDT) Received: from we-gotmail.red.iplanet.com (gotmail-1.red.iplanet.com [192.18.73.251]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k4VGbUtx000841; Wed, 31 May 2006 09:37:30 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; charset=US-ASCII Received: from [192.18.127.162] (dhcp-usca15-127-162.red.iplanet.com [192.18.127.162]) by we-gotmail.red.iplanet.com (Sun Java(tm) System Messaging Server 6.3-0.07 (built Apr 11 2006)) with ESMTPSA id <0J0500G1J26HWI00@we-gotmail.red.iplanet.com>; Wed, 31 May 2006 09:37:30 -0700 (PDT) Date: Wed, 31 May 2006 09:37:23 -0700 (Pacific Daylight Time) From: Anil SRIVASTAVA To: "Burger, Eric" Subject: Re: [lemonade] RECONNECT In-reply-to: <330A23D8336C0346B5C1A5BB1966664702F6CD47@ATLANTIS.Brooktrout.com> Message-id: References: <330A23D8336C0346B5C1A5BB1966664702F6CD47@ATLANTIS.Brooktrout.com> X-Message-flag: Outlook: the best virus distribution system around Accept-Language: English; en Organization: Sun Microsystems [http://www.sun.com] X-Mailer: Pine 4.64 (Windows XP) - Got Pine? [http://www.washington.edu/pine] X-Message-Class: normal X-Endorsement: Message brought to you by Sun Java Enterprise System Communication Suite 4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Enhancements to Internet email to support diverse serviceenivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: anil.srivastava@Sun.COM List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Offloading the state information to the client is clearly preferable. Anil On 2006-05-31/11:22 [-0400], eburger@cantata.com [Burger, Eric] wrote: > Dave and Alexey realized that it is the same number of bytes and > round-trips to have the client store the state for reconnect than to > have the server store the state. > > Alexey believes it is a small number of edits to make the change to the > document. > > Because of our short time-lines, we will not abandon the server-side > RECONNECT mechanism. Rather, we will have a new document, > draft-ietf-lemonade-reconnect-client, that will describe the client-side > mechanism. > > The work group will examine both drafts and preferably pick one > approach. That approach will go standards-track while the other will > die. > > Less preferably, we can keep both drafts, make one Experimental, and > reference the standards-track document in Profile bis. > > Least preferably, we go with both drafts. > > Thoughts? > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade > _______________ Anil SRIVASTAVA anil.srivastava@Sun.COM _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 31 13:00:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlU3d-0001Ip-GM; Wed, 31 May 2006 13:00:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlU3c-0001GH-Dj for lemonade@ietf.org; Wed, 31 May 2006 13:00:32 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlU3Z-0000fr-T3 for lemonade@ietf.org; Wed, 31 May 2006 13:00:32 -0400 Received: from [192.168.0.9] ([62.3.217.253]) by rufus.isode.com via TCP (submission) with ESMTPA; Wed, 31 May 2006 18:00:23 +0100 Message-ID: <447DCB67.90506@isode.com> Date: Wed, 31 May 2006 17:59:19 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Burger, Eric" Subject: Re: [lemonade] OMA Presentation on Lemonade References: <20060531080049406.00000005884@smaes-lap3> In-Reply-To: <20060531080049406.00000005884@smaes-lap3> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Enhancements to Internet email to support diverse serviceenivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Stephane H. Maes wrote: >It would be good if OMA can do. > Yes. >Montreal may be too early for them. We should ask them to do (when they can) and we will see... > >I don't mind it during or outside WG time. We should in any way have a short WG discussion after the session. So if the session is not the WG session, it should be before the last WG session... > > I agree. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 31 13:29:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlUV7-0006AL-2p; Wed, 31 May 2006 13:28:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlUV5-0006AE-Nw for lemonade@ietf.org; Wed, 31 May 2006 13:28:55 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlUV3-0002Yv-9F for lemonade@ietf.org; Wed, 31 May 2006 13:28:55 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4VHSl0i026051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 31 May 2006 10:28:48 -0700 Received: from [172.28.175.180] (vpn-10-50-0-87.qualcomm.com [10.50.0.87]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4VHShrg029135 for ; Wed, 31 May 2006 10:28:46 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Wed, 31 May 2006 08:38:05 -0700 To: lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-03.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Please edit the document to replace non-US-ASCII characters (I think there are a number of instances where 'smart quotes' in Word were converted to 8-bit characters.) I'd suggest deleting the first two paragraphs of Section 2 (Relation with other E-mail specifications), and replace the third paragraph with "Conversion during streaming of attachments is out if scope of the CONVERT extension." I'd suggest changing Section 3 from: This document does not specify how conversions are to be done by the server. It is however noted that the conversion MUST NOT affect the document stored in the message storage server in order to remain accessible unaffected through other clients that do not request conversion as well as in order to allow replies or forward of the documents as they were originally received by the server. To: Conversions only affect what is sent to the client; the original data in the message store MUST NOT be altered. This document does not specify how the server performs conversions. (The requirement that original data be unaltered allows such data to remain accessible by other clients, permits replies or forwards of the documents, and preserves BODYSTRUCTURE and related information.) I'd also suggest changing the name of Section 3, perhaps to "Scope of Conversions". In Section 4.1, is LDELIVER there by accident? In Section 4.2, what does "For any proposed conversion, the client MAY discover a list of optional parameters that the conversion SHOULD accept" mean? Also in Section 4.2, perhaps it would be more compact, and easier on clients and servers, to advertise the supported conversions under the media type rather than sub-type? So rather than have '/convert/image/jpeg' just have '/convert/image' contain the supported destination formats? LPerhaps also likewise for the parameters? This may come down to how these mailbox annotations are generated and used: if servers generate the annotations dynamically, and if clients fetch and consume them immediately prior to requesting a conversion, then having the extra levels of hierarchy are fine. But if the data will be stored or cached by either side, flattening seems beneficial. I know the example shows a server that can convert from only one image format but can convert into a number of them. But is that realistic? It's also true that it would be possible for conversion parameters to be advertised that don't make sense or aren't supported for all subtypes, but how likely is it that clients would request them, and even so, this can be handled with an error. In the case of some media types (especially 'application') it might not make sense to flatten the hierarchy. In Section 5, if the client asks for US-ASCII, is it proper for the server to unilaterally return UTF-8? If the client supports UTF-8, wouldn't it have asked for it? It might be better for the server to either encode the non-US-ASCII characters or return an error. I realize the STRICT qualifier can force this, but it seems to apply to both media type/subtype and parameters. Also in Section 5, the text mentions the server having knowledge of the device: how does the client identify a specific device? Users may have multiple devices. Also in Section 5, the wording says that if a client doesn't use STRICT the server MAY honor its request. That seems a strange way to allow the server to use whatever knowledge it has of the client. Would it make more sense to have a ORWHATEVER modifier for this? So STRICT would mean MUST do this, ORWHATEVER means MAY do this, and nothing means SHOULD do this. Alternatively, the destination format and parameters could be omitted to request the server to use its knowledge. In Section 6, what is a "CONVERT server"? Is it an IMAP server that supports CONVERT, or is it a media conversion server utilized by the IMAP server to perform conversions? In Section 6.1, I think you meant "while preserving" instead of "without preserving". In Section 6.1.1, what does it mean to "recommend" SHOULDs? Also in Section 6.1.1, does "conversion of HTML and XHTML documents to text" mean to 'text/plain'? In Section 8, would it be better to use NO rather than BAD? These errors are dependent on the target data or server resources. BAD does not seem appropriate. In Section 10, I really think compression belongs in its own document. Personally, I think Ned and others made very compelling arguments in Dallas that there are no use cases where clients wouldn't want compressible data compressed, but even if there turn out to be, and even if compression therefore ends up using CONVERT, it can be an extension to it. But otherwise compression can be something that the server advertises support for and the client requests once ("compress at will") with the server determining based on its own criteria which data to compress. In Section 11, I think encryption also belongs in its own document. There are too many issues with it that should be dealt with on their own, not tied up with conversion. In Appendix A, what does "The enterprise network is assumed to be secure" mean? Secure in what way? -- 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 lemonade-bounces@ietf.org Wed May 31 13:29:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlUVB-0006Bs-7U; Wed, 31 May 2006 13:29:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlUVA-0006Bl-Ay for lemonade@ietf.org; Wed, 31 May 2006 13:29:00 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlUV8-0002e8-W1 for lemonade@ietf.org; Wed, 31 May 2006 13:29:00 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4VHSvad026062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 31 May 2006 10:28:58 -0700 Received: from [172.28.175.180] (vpn-10-50-0-87.qualcomm.com [10.50.0.87]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4VHShri029135; Wed, 31 May 2006 10:28:51 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <20060531051007531.00000005016@smaes-lap3> References: <20060531051007531.00000005016@smaes-lap3> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Wed, 31 May 2006 08:43:23 -0700 To: "stephane.maes@oracle.com" , "lemonade@ietf.org" From: Randall Gellens Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-03.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Ned Freed X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 5:10 AM -0700 5/31/06, Stephane H. Maes wrote: > We decided in Dallas to consider object level compression via convert. I don't think we did. It was proposed in Dallas that compression be done (along with several other proposals on compression) but I believe Ned and others made compelling arguments that compression should be done by the server compressing data whenever it makes sense to do so and the client can decompress. What convinced me was the absence of any use cases where the client wouldn't want data to be compressed (assuming it can decompress). Since the server has access to the data prior to compression, it is in the best position to determine if compression makes sense. It's been stated that decompression is cheaper for a mobile client than over the air reception, so its always in the client's interests. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- We adore chaos because we love to produce order. --M. C. Escher _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 31 13:29:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlUV7-0006AL-2p; Wed, 31 May 2006 13:28:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlUV5-0006AE-Nw for lemonade@ietf.org; Wed, 31 May 2006 13:28:55 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlUV3-0002Yv-9F for lemonade@ietf.org; Wed, 31 May 2006 13:28:55 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4VHSl0i026051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 31 May 2006 10:28:48 -0700 Received: from [172.28.175.180] (vpn-10-50-0-87.qualcomm.com [10.50.0.87]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4VHShrg029135 for ; Wed, 31 May 2006 10:28:46 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Wed, 31 May 2006 08:38:05 -0700 To: lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-03.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Please edit the document to replace non-US-ASCII characters (I think there are a number of instances where 'smart quotes' in Word were converted to 8-bit characters.) I'd suggest deleting the first two paragraphs of Section 2 (Relation with other E-mail specifications), and replace the third paragraph with "Conversion during streaming of attachments is out if scope of the CONVERT extension." I'd suggest changing Section 3 from: This document does not specify how conversions are to be done by the server. It is however noted that the conversion MUST NOT affect the document stored in the message storage server in order to remain accessible unaffected through other clients that do not request conversion as well as in order to allow replies or forward of the documents as they were originally received by the server. To: Conversions only affect what is sent to the client; the original data in the message store MUST NOT be altered. This document does not specify how the server performs conversions. (The requirement that original data be unaltered allows such data to remain accessible by other clients, permits replies or forwards of the documents, and preserves BODYSTRUCTURE and related information.) I'd also suggest changing the name of Section 3, perhaps to "Scope of Conversions". In Section 4.1, is LDELIVER there by accident? In Section 4.2, what does "For any proposed conversion, the client MAY discover a list of optional parameters that the conversion SHOULD accept" mean? Also in Section 4.2, perhaps it would be more compact, and easier on clients and servers, to advertise the supported conversions under the media type rather than sub-type? So rather than have '/convert/image/jpeg' just have '/convert/image' contain the supported destination formats? LPerhaps also likewise for the parameters? This may come down to how these mailbox annotations are generated and used: if servers generate the annotations dynamically, and if clients fetch and consume them immediately prior to requesting a conversion, then having the extra levels of hierarchy are fine. But if the data will be stored or cached by either side, flattening seems beneficial. I know the example shows a server that can convert from only one image format but can convert into a number of them. But is that realistic? It's also true that it would be possible for conversion parameters to be advertised that don't make sense or aren't supported for all subtypes, but how likely is it that clients would request them, and even so, this can be handled with an error. In the case of some media types (especially 'application') it might not make sense to flatten the hierarchy. In Section 5, if the client asks for US-ASCII, is it proper for the server to unilaterally return UTF-8? If the client supports UTF-8, wouldn't it have asked for it? It might be better for the server to either encode the non-US-ASCII characters or return an error. I realize the STRICT qualifier can force this, but it seems to apply to both media type/subtype and parameters. Also in Section 5, the text mentions the server having knowledge of the device: how does the client identify a specific device? Users may have multiple devices. Also in Section 5, the wording says that if a client doesn't use STRICT the server MAY honor its request. That seems a strange way to allow the server to use whatever knowledge it has of the client. Would it make more sense to have a ORWHATEVER modifier for this? So STRICT would mean MUST do this, ORWHATEVER means MAY do this, and nothing means SHOULD do this. Alternatively, the destination format and parameters could be omitted to request the server to use its knowledge. In Section 6, what is a "CONVERT server"? Is it an IMAP server that supports CONVERT, or is it a media conversion server utilized by the IMAP server to perform conversions? In Section 6.1, I think you meant "while preserving" instead of "without preserving". In Section 6.1.1, what does it mean to "recommend" SHOULDs? Also in Section 6.1.1, does "conversion of HTML and XHTML documents to text" mean to 'text/plain'? In Section 8, would it be better to use NO rather than BAD? These errors are dependent on the target data or server resources. BAD does not seem appropriate. In Section 10, I really think compression belongs in its own document. Personally, I think Ned and others made very compelling arguments in Dallas that there are no use cases where clients wouldn't want compressible data compressed, but even if there turn out to be, and even if compression therefore ends up using CONVERT, it can be an extension to it. But otherwise compression can be something that the server advertises support for and the client requests once ("compress at will") with the server determining based on its own criteria which data to compress. In Section 11, I think encryption also belongs in its own document. There are too many issues with it that should be dealt with on their own, not tied up with conversion. In Appendix A, what does "The enterprise network is assumed to be secure" mean? Secure in what way? -- 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 lemonade-bounces@ietf.org Wed May 31 13:29:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlUVB-0006Bs-7U; Wed, 31 May 2006 13:29:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlUVA-0006Bl-Ay for lemonade@ietf.org; Wed, 31 May 2006 13:29:00 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlUV8-0002e8-W1 for lemonade@ietf.org; Wed, 31 May 2006 13:29:00 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4VHSvad026062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 31 May 2006 10:28:58 -0700 Received: from [172.28.175.180] (vpn-10-50-0-87.qualcomm.com [10.50.0.87]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4VHShri029135; Wed, 31 May 2006 10:28:51 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <20060531051007531.00000005016@smaes-lap3> References: <20060531051007531.00000005016@smaes-lap3> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Wed, 31 May 2006 08:43:23 -0700 To: "stephane.maes@oracle.com" , "lemonade@ietf.org" From: Randall Gellens Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-03.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Ned Freed X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 5:10 AM -0700 5/31/06, Stephane H. Maes wrote: > We decided in Dallas to consider object level compression via convert. I don't think we did. It was proposed in Dallas that compression be done (along with several other proposals on compression) but I believe Ned and others made compelling arguments that compression should be done by the server compressing data whenever it makes sense to do so and the client can decompress. What convinced me was the absence of any use cases where the client wouldn't want data to be compressed (assuming it can decompress). Since the server has access to the data prior to compression, it is in the best position to determine if compression makes sense. It's been stated that decompression is cheaper for a mobile client than over the air reception, so its always in the client's interests. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- We adore chaos because we love to produce order. --M. C. Escher _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 31 13:37:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlUcv-0003fD-PR; Wed, 31 May 2006 13:37:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlUcv-0003ew-3J for lemonade@ietf.org; Wed, 31 May 2006 13:37:01 -0400 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlUcq-0003nc-Ko for lemonade@ietf.org; Wed, 31 May 2006 13:37:01 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1FlUcp-0006ap-Qh; Wed, 31 May 2006 17:36:55 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 885BB498007; Wed, 31 May 2006 18:40:18 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17445-08; Wed, 31 May 2006 18:40:12 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 8DA85498006; Wed, 31 May 2006 18:40:12 +0100 (BST) Date: Wed, 31 May 2006 18:36:47 +0100 Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-03.txt References: <20060531051007531.00000005016@smaes-lap3> In-Reply-To: MIME-Version: 1.0 Message-Id: <32212.1149097008.660990@peirce.dave.cridland.net> From: Dave Cridland To: Randall Gellens Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Heisenberg-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Enhancements to Internet email to support diverse service enivronments , Ned Freed , "Stephane H. Maes" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed May 31 16:43:23 2006, Randall Gellens wrote: > At 5:10 AM -0700 5/31/06, Stephane H. Maes wrote: > >> We decided in Dallas to consider object level compression via >> convert. > > I don't think we did. > > No, we did, but we didn't reach consensus that we would be mandating object-level compression at all - we just decided that if we were going to do it, we'd do it via conversion. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 31 13:55:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlUuM-0003zI-Iq; Wed, 31 May 2006 13:55:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlUuK-0003yB-UQ for lemonade@ietf.org; Wed, 31 May 2006 13:55:00 -0400 Received: from smtp.andrew.cmu.edu ([128.2.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlUoq-00054e-KM for lemonade@ietf.org; Wed, 31 May 2006 13:49:22 -0400 Received: from [192.168.137.17] (69-171-17-197.kntnny.adelphia.net [69.171.17.197]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.5/8.13.6) with ESMTP id k4VHnEXK001133 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 31 May 2006 13:49:15 -0400 Message-ID: <447DD719.4000000@andrew.cmu.edu> Date: Wed, 31 May 2006 13:49:13 -0400 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Burger, Eric" Subject: Re: [lemonade] RECONNECT References: <330A23D8336C0346B5C1A5BB1966664702F6CD47@ATLANTIS.Brooktrout.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Enhancements to Internet email to support diverse serviceenivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Anil SRIVASTAVA wrote: > Offloading the state information to the client is clearly preferable. I agree. > > On 2006-05-31/11:22 [-0400], eburger@cantata.com [Burger, Eric] wrote: > > >>Dave and Alexey realized that it is the same number of bytes and >>round-trips to have the client store the state for reconnect than to >>have the server store the state. >> >>Alexey believes it is a small number of edits to make the change to the >>document. >> >>Because of our short time-lines, we will not abandon the server-side >>RECONNECT mechanism. Rather, we will have a new document, >>draft-ietf-lemonade-reconnect-client, that will describe the client-side >>mechanism. >> >>The work group will examine both drafts and preferably pick one >>approach. That approach will go standards-track while the other will >>die. >> >>Less preferably, we can keep both drafts, make one Experimental, and >>reference the standards-track document in Profile bis. >> >>Least preferably, we go with both drafts. >> >>Thoughts? >> >>_______________________________________________ >>lemonade mailing list >>lemonade@ietf.org >>https://www1.ietf.org/mailman/listinfo/lemonade >> > > > _______________ > Anil SRIVASTAVA > anil.srivastava@Sun.COM > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade > -- Kenneth Murchison Systems Programmer Carnegie Mellon University _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 31 14:01:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlV0Z-00073a-Tf; Wed, 31 May 2006 14:01:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlV0Y-00073V-M6 for lemonade@ietf.org; Wed, 31 May 2006 14:01:26 -0400 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlV0X-0005sP-At for lemonade@ietf.org; Wed, 31 May 2006 14:01:26 -0400 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M32IHT91LS00A91J@mauve.mrochek.com> for lemonade@ietf.org; Wed, 31 May 2006 11:01:18 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1149098478; h=Date: From:Subject:MIME-version:Content-type; b=s42VQ0yzZ0yht3LCnPP6Nw1n6 AhqgdCk4SVjUgxCghAacfwfieqAMGaQxPir0MXlOtsRxae9/n6XVCLsra6A5Q== Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M32HYJCXGG0008CX@mauve.mrochek.com>; Wed, 31 May 2006 11:01:17 -0700 (PDT) To: Randall Gellens Message-id: <01M32IHSAAUW0008CX@mauve.mrochek.com> Date: Wed, 31 May 2006 10:49:58 -0700 (PDT) From: Ned Freed Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-03.txt In-reply-to: "Your message dated Wed, 31 May 2006 08:43:23 -0700" MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <20060531051007531.00000005016@smaes-lap3> X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: lemonadeietforg , Ned Freed , stephanemaesoraclecom X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > At 5:10 AM -0700 5/31/06, Stephane H. Maes wrote: > > We decided in Dallas to consider object level compression via convert. > I don't think we did. > It was proposed in Dallas that compression be done (along with > several other proposals on compression) but I believe Ned and others > made compelling arguments that compression should be done by the > server compressing data whenever it makes sense to do so and the > client can decompress. To be fair, I also pointed out that a side effect of object conversion could be a significant reduction in object size, and that in some cases this will produce a much smaller object than any general compression scheme ever could. Obvious examples are the conversion of hi-res audio or video to formats more appropriate for use on a cell phone with limited visual and audible fidelity. But this falls far short of adding a compression facility to the convert extension. I remain to be convinced that this is a good idea. > What convinced me was the absence of any use cases where the client > wouldn't want data to be compressed (assuming it can decompress). Exactly so. I also find the argument that compressing already compressed data is an issue to be pretty weak: Modern compression formats provide the ability to switch off compression, and it shouldn't be hard to have a list of formats where compression is unlikely to be useful and can be disabled. > Since the server has access to the data prior to compression, it is > in the best position to determine if compression makes sense. It's > been stated that decompression is cheaper for a mobile client than > over the air reception, so its always in the client's interests. Also true. A really smart server could determine in advance whether a given object is worth compressing before transfer. Of course such calculations go straight into the dumpster when a conversion operation is used - in that case the server has to go by general media type characters or else perform the compression and see if it helps before sending the data. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 31 14:10:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlV8z-00030x-IA; Wed, 31 May 2006 14:10:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlV8z-00030m-3i for lemonade@ietf.org; Wed, 31 May 2006 14:10:09 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlV8z-0006XI-2J for lemonade@ietf.org; Wed, 31 May 2006 14:10:09 -0400 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FlV7p-0003GF-9A for lemonade@ietf.org; Wed, 31 May 2006 14:08:57 -0400 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M32IR8RKOW00AAAN@mauve.mrochek.com> for lemonade@ietf.org; Wed, 31 May 2006 11:08:55 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1149098934; h=Date: From:Subject:MIME-version:Content-type; b=DnC2Pn5bpTGj1NCNqRerecUEz +7qX46+Eg11ElZEQSbfDe6p/05rDMWF/gJDahhJqX9W4mbdOomLQDi4S8nX9g== Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M32HYJCXGG0008CX@mauve.mrochek.com>; Wed, 31 May 2006 11:08:53 -0700 (PDT) To: Ken Murchison Message-id: <01M32IR82PY60008CX@mauve.mrochek.com> Date: Wed, 31 May 2006 11:08:26 -0700 (PDT) From: Ned Freed Subject: Re: [lemonade] RECONNECT In-reply-to: "Your message dated Wed, 31 May 2006 13:49:13 -0400" <447DD719.4000000@andrew.cmu.edu> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <330A23D8336C0346B5C1A5BB1966664702F6CD47@ATLANTIS.Brooktrout.com> <447DD719.4000000@andrew.cmu.edu> X-Spam-Score: -2.6 (--) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Enhancements to Internet email to support diverse serviceenivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > Anil SRIVASTAVA wrote: > > Offloading the state information to the client is clearly preferable. > I agree. I concur as well. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 31 14:19:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlVHY-0007W8-JA; Wed, 31 May 2006 14:19:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlVHX-0007W3-EX for lemonade@ietf.org; Wed, 31 May 2006 14:18:59 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlVHW-00078U-04 for lemonade@ietf.org; Wed, 31 May 2006 14:18:59 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 4F97E4AC50; Wed, 31 May 2006 20:18:48 +0200 (CEST) Message-Id: Date: Wed, 31 May 2006 20:19:21 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-03.txt References: <20060531051007531.00000005016@smaes-lap3> <01M32IHSAAUW0008CX@mauve.mrochek.com> In-Reply-To: <01M32IHSAAUW0008CX@mauve.mrochek.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Ned Freed X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Ned Freed writes: > I also find the argument that compressing already compressed data is > an issue to be pretty weak: Modern compression formats provide the > ability to switch off compression, and it shouldn't be hard to have a > list of formats where compression is unlikely to be useful and can be > disabled. Not very hard. If a COMPRESS=DEFLATE + BINARY server knows to send Z_SYNC_FLUSH when a literal starts and finishes and is big enough to make the flush worthwhile, and sets its compression level to zero when the first two bytes of the literal are either 0xFF 0xD8 or 0x1F 0x8B, you're already more than 80% of the way there. A COMPRESS=DEFLATE receiver just works, even when the sender plays such tricks. Its zlib receives the literal uncompressed and the client never knows that anything hapened. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 31 14:22:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlVKe-00089s-Qg; Wed, 31 May 2006 14:22:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlVKe-00089n-9v for lemonade@ietf.org; Wed, 31 May 2006 14:22:12 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlVKc-0007K4-T9 for lemonade@ietf.org; Wed, 31 May 2006 14:22:12 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id DFF7D4AC50; Wed, 31 May 2006 20:22:09 +0200 (CEST) Message-Id: Date: Wed, 31 May 2006 20:22:43 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-03.txt References: <20060531051007531.00000005016@smaes-lap3> <01M32IHSAAUW0008CX@mauve.mrochek.com> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Ned Freed X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Arnt Gulbrandsen writes: > If a COMPRESS=DEFLATE + BINARY server knows to send Z_SYNC_FLUSH when > a literal starts and finishes and is big enough to make the flush > worthwhile, and sets its compression level to zero when the first two > bytes of the literal are either 0xFF 0xD8 or 0x1F 0x8B, you're > already more than 80% of the way there. Shall I write a new revision where I explain this in bothersome detail? Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 31 14:22:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlVLE-0008O4-1s; Wed, 31 May 2006 14:22:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlVLD-0008Nz-Ax for lemonade@ietf.org; Wed, 31 May 2006 14:22:47 -0400 Received: from brooklyn.mumbo.ca ([209.89.70.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlVLC-0007Kz-3E for lemonade@ietf.org; Wed, 31 May 2006 14:22:47 -0400 Received: from [209.89.70.52] (tribeca.mumbo.ca [209.89.70.52]) by brooklyn.mumbo.ca (Postfix) with ESMTP id A7C59272B4; Wed, 31 May 2006 12:22:45 -0600 (MDT) In-Reply-To: <447DD719.4000000@andrew.cmu.edu> References: <330A23D8336C0346B5C1A5BB1966664702F6CD47@ATLANTIS.Brooktrout.com> <447DD719.4000000@andrew.cmu.edu> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6C853C65-29F5-461C-81BB-214C25B336EE@mumbo.ca> Content-Transfer-Encoding: 7bit From: Curtis King Subject: Re: [lemonade] RECONNECT Date: Wed, 31 May 2006 12:22:46 -0600 To: Ken Murchison X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Enhancements to Internet email to support diverse serviceenivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On 31-May-06, at 11:49 AM, Ken Murchison wrote: > Anil SRIVASTAVA wrote: > >> Offloading the state information to the client is clearly preferable. > > I agree. I agree. ck _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 31 15:21:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlWFy-0002Wv-TH; Wed, 31 May 2006 15:21:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlWFw-0002Wg-RF for lemonade@ietf.org; Wed, 31 May 2006 15:21:24 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlWFv-0005kq-HF for lemonade@ietf.org; Wed, 31 May 2006 15:21:24 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4VJKrW7006323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 31 May 2006 12:20:54 -0700 Received: from [172.28.175.180] (vpn-10-50-0-87.qualcomm.com [10.50.0.87]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4VJK6ti009056; Wed, 31 May 2006 12:20:36 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20060531051007531.00000005016@smaes-lap3> <01M32IHSAAUW0008CX@mauve.mrochek.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Wed, 31 May 2006 12:15:52 -0700 To: Arnt Gulbrandsen , lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-03.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Ned Freed X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 8:22 PM +0200 5/31/06, Arnt Gulbrandsen wrote: > Arnt Gulbrandsen writes: >> If a COMPRESS=DEFLATE + BINARY server knows to send Z_SYNC_FLUSH >> when a literal starts and finishes and is big enough to make the >> flush worthwhile, and sets its compression level to zero when the >> first two bytes of the literal are either 0xFF 0xD8 or 0x1F 0x8B, >> you're already more than 80% of the way there. > > Shall I write a new revision where I explain this in bothersome detail? Yes, please. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Computer Science: solving today's problems tomorrow. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 31 15:28:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlWNG-00076Q-Kx; Wed, 31 May 2006 15:28:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlWNE-00076K-Ru for lemonade@ietf.org; Wed, 31 May 2006 15:28:56 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlWNC-0006NM-I3 for lemonade@ietf.org; Wed, 31 May 2006 15:28:56 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4VJSqtA019385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 31 May 2006 12:28:53 -0700 Received: from [172.28.175.180] (vpn-10-50-0-87.qualcomm.com [10.50.0.87]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4VJSenq013436; Wed, 31 May 2006 12:28:48 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Wed, 31 May 2006 12:20:32 -0700 To: , From: Randall Gellens Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 1:02 PM +0300 5/31/06, wrote: > - what is a "potentially large or high velocity mailbox" I thought this was amusing wording. I suppose "high velocity" mailbox is one that resides on a mobile device that has been hurtled at high speed towards someone or something? (I assume the intent is one whose contents change frequently.) > - "a vfolder should appear to function as a regular mailbox" > Question: Can one create a VFOLDER based on a VFOLDER? The draft says this is supported. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Nine out of 10 doctors agree that 1 out of 10 doctors is an idiot. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 31 15:29:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlWNv-0007Cv-TE; Wed, 31 May 2006 15:29:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlWNt-0007Co-Pc for lemonade@ietf.org; Wed, 31 May 2006 15:29:37 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlWNs-0006O0-J1 for lemonade@ietf.org; Wed, 31 May 2006 15:29:37 -0400 X-IronPort-AV: i="4.05,194,1146456000"; d="scan'208"; a="33492103:sNHT27688468" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 31 May 2006 15:29:26 -0400 Message-ID: <330A23D8336C0346B5C1A5BB1966664702F6D036@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: COMPRESS Thoughts Thread-Index: AcaE6IcwSbuZnYNoR36SjY1FK4h+ng== From: "Burger, Eric" To: "Enhancements to Internet email to support diverse serviceenivronments" X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [lemonade] COMPRESS Thoughts X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org (1) Going back to COMPRESS in its own document (not CONVERT) (2) Consensus that compression is directional, i.e., downstream compressed, upstream uncompressed. This is because IMAP upstream commands may be real short (meaning compression actually adds CPU *and* bits used), while content may be real long. (3) Basis for COMPRESS document is Arnt's imap-deflate-02 [compress=3Ddeflate]. We will call the new document draft-ietf-lemonade-compress-04 (delete existing compress text) (4) Protocol allows for client to turn it on or off at will (not per body part, but point in time in session) (5) review SASL mechanism for handling glare: server is busy streaming down compressed content, and the client says, "stop compressing". Right now looks like server will continue until finished with IMAP transaction. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 31 16:26:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlXGE-0000ob-KR; Wed, 31 May 2006 16:25:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlXGC-0000mO-SB for lemonade@ietf.org; Wed, 31 May 2006 16:25:44 -0400 Received: from mxout5.cac.washington.edu ([140.142.32.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlXG8-0003to-H1 for lemonade@ietf.org; Wed, 31 May 2006 16:25:44 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.13.6+UW06.03/8.13.6+UW06.03) with ESMTP id k4VKPdcc006780 for ; Wed, 31 May 2006 13:25:39 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.6+UW06.03/8.13.6+UW06.03) with ESMTP id k4VKPcLm016396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 31 May 2006 13:25:39 -0700 Date: Wed, 31 May 2006 13:25:38 -0700 (PDT) From: Mark Crispin To: lemonade@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [lemonade] a lighter topic with VFOLDER... X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org As I requested in jabber, please s/VFOLDER/VMAILBOX and otherwise s/folder/mailbox in documents. "Folder" is not an IMAP term, and it creates an ambiguity with \NoSelect names. I didn't think this was worth bringing up in the spoken discussion. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 31 17:27:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlYDt-0000t2-2P; Wed, 31 May 2006 17:27:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlYDs-0000sx-9V for lemonade@ietf.org; Wed, 31 May 2006 17:27:24 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FlYDq-0002wQ-1J for lemonade@ietf.org; Wed, 31 May 2006 17:27:24 -0400 X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-7.tower-121.messagelabs.com!1149110841!10698424!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 1088 invoked from network); 31 May 2006 21:27:21 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-7.tower-121.messagelabs.com with SMTP; 31 May 2006 21:27:21 -0000 Received: from [135.91.110.64] (thansen-n.mt.att.com[135.91.110.64](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20060531212721gw100100gae> (Authid: tony); Wed, 31 May 2006 21:27:21 +0000 Message-ID: <447E0A2C.4050500@att.com> Date: Wed, 31 May 2006 17:27:08 -0400 From: Tony Hansen User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 CC: Enhancements to Internet email to support diverse serviceenivronments Subject: Re: [lemonade] RECONNECT References: <330A23D8336C0346B5C1A5BB1966664702F6CD47@ATLANTIS.Brooktrout.com> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org In principle, yes. I'd like to see the I-D first, though, before making final judgements. Tony Anil SRIVASTAVA wrote: > Offloading the state information to the client is clearly preferable. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 31 17:36:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlYMP-0008MT-6e; Wed, 31 May 2006 17:36:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlYMN-0008K3-Jy for lemonade@ietf.org; Wed, 31 May 2006 17:36:11 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlXhe-0007on-D6 for lemonade@ietf.org; Wed, 31 May 2006 16:54:06 -0400 Received: from agminet01.oracle.com ([141.146.126.228]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FlWnT-0004VG-Qd for lemonade@ietf.org; Wed, 31 May 2006 15:56:07 -0400 Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k4VJu2gk013716 for ; Wed, 31 May 2006 14:56:02 -0500 Received: from us.oracle.com (dhcp-amer-rmdc-csvpn-gw4-141-144-96-63.vpn.oracle.com [141.144.96.63]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k4VJttmG028500 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 31 May 2006 13:56:01 -0600 From: "Stephane H. Maes" To: "lemonade@ietf.org" Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt Date: Wed, 31 May 2006 12:55:48 -0700 Organization: Oracle Message-ID: <20060531125548578.00000005884@smaes-lap3> In-Reply-To: X-Mailer: Oracle Connector for Outlook 10.1.2.0.3 71207 (11.0.8010) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-Spam-Score: -2.6 (--) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "stephane.maes@oracle.com" List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org = >>> - what is a "potentially large or high velocity mailbox" I thought this was amusing wording. I suppose "high velocity" mailbox is one that resides on a mobile device that has been hurtled at hig= h speed towards someone or something? (I assume the intent is one whose co= ntents change frequently.)<< Yeah... Stephane _____ Stephane H. Maes, PhD, Director of Architecture, Mobile, Voice, and Communications Platforms, Orac= le. Ph: +1-203-300-7786 (mobile/SMS); Fax / Office UM: +1-650-607-6296 e-mail: stephane.maes@oracle.com IM: shmaes (AIM/Y!/skype) or stephane_maes@hotmail.com (MSN Messenger) or s= tephane.maes@gmail.com (Google) -----Original Message----- From: Randall Gellens [mailto:randy@qualcomm.com] = Sent: Wednesday, May 31, 2006 12:21 PM To: Zoltan.Ordogh@nokia.com; lemonade@ietf.org Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt At 1:02 PM +0300 5/31/06, wrote: > - what is a "potentially large or high velocity mailbox" I thought this was amusing wording. I suppose "high velocity" mailbox is one that resides on a mobile device that has been hurtled at hig= h speed towards someone or something? (I assume the intent is one whose co= ntents change frequently.) > - "a vfolder should appear to function as a regular mailbox" > Question: Can one create a VFOLDER based on a VFOLDER? The draft says this is supported. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Nine out of 10 doctor= s agree that 1 out of 10 doctors is an idiot. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 31 18:36:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlZIq-0003d6-1d; Wed, 31 May 2006 18:36:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlZIp-0003d1-C0 for lemonade@ietf.org; Wed, 31 May 2006 18:36:35 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlZIn-00029i-Su for lemonade@ietf.org; Wed, 31 May 2006 18:36:35 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.34) id 1FlZIm-0006AC-Od for lemonade@ietf.org; Wed, 31 May 2006 22:36:32 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 78ABF498007 for ; Wed, 31 May 2006 23:39:58 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20758-02 for ; Wed, 31 May 2006 23:39:48 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 40A15498006 for ; Wed, 31 May 2006 23:39:48 +0100 (BST) Date: Wed, 31 May 2006 23:36:21 +0100 Subject: Re: [lemonade] COMPRESS Thoughts References: <330A23D8336C0346B5C1A5BB1966664702F6D036@ATLANTIS.Brooktrout.com> In-Reply-To: <330A23D8336C0346B5C1A5BB1966664702F6D036@ATLANTIS.Brooktrout.com> MIME-Version: 1.0 Message-Id: <6226.1149114982.248218@peirce.dave.cridland.net> From: Dave Cridland To: Enhancements to Internet email to support diverse service enivronments Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Rutherford-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed May 31 20:29:26 2006, Burger, Eric wrote: > (1) Going back to COMPRESS in its own document (not CONVERT) > > (2) Consensus that compression is directional, i.e., downstream > compressed, upstream uncompressed. This is because IMAP upstream > commands may be real short (meaning compression actually adds CPU > *and* > bits used), while content may be real long. > > This is not quite true. The issue is that the upstream data flow compresses worse, as far as I can tell, than downstream, and compression is, in general, more expensive than decompression in terms of memory and resource usage. I may have results skewed on how well the upstream data flow compresses, though, so be warned. So there is a chance that a client may decide to avoid compression upstream - note that for most mobile handsets this is probably not the case, because there is compression (my results indicate about 50% - as I say, these may be skewed), and as I understand things, every bit on the radio transmitter is costly. In the case were the client wants to avoid upstream compression, it could do so by using uncompressed data blocks in deflate, but these do not stream - they're prefixed with an octet count (or two octet counts and a block type code, to be precise), so every "send" - ie, command or pipeline of them - will incur a 5 octet overhead, and is worth avoiding. As I say, though, actually compressing does reduce the octet count, and compressed blocks don't have the overhead - I'm not clear if a new block needs to be started for a Z_SYNC_FLUSH or not, in fact. I've never seen compression actually expand data. This is solely an issue with deliberately not wanting to compress. Also, please note, if you're intending using TLS, you always want to compress, because the CPU cost of compression and encryption is lower than the CPU cost of encryption alone, if the compression is at all effective. > (3) Basis for COMPRESS document is Arnt's imap-deflate-02 > [compress=deflate]. We will call the new document > draft-ietf-lemonade-compress-04 (delete existing compress text) > > Why? It's obviously not a revision of that document. Is there a procedural reason for this? > (4) Protocol allows for client to turn it on or off at will (not per > body part, but point in time in session) > > (5) review SASL mechanism for handling glare: server is busy > streaming > down compressed content, and the client says, "stop compressing". > Right > now looks like server will continue until finished with IMAP > transaction. > > So you apply the same rules to turning compression off as already exist for turning it on - the compression stops (or starts) after the CR LF of the tagged OK response to the COMPRESS command. The interesting thing is where you apply compression before SASL (SASL exchanges compress, they're base64), and SASL then negotiates a security layer. This requires SASL to "slip a new layer" under compression. Perfectly possible to do, but I'd be interested in how difficult people actually find this in practise. Also, I think there's a (6) - a direct analogue of Arnt's draft can also be used in Submission. Although the "protocol chatter" is less, it makes sense to keep to the same form of mechanism if possible. I use it both in Submission and in ACAP, currently. (I'll do a draft for it if Arnt wants to keep them distinct, unless anyone else wants to). Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 31 18:48:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlZUN-0004Hi-70; Wed, 31 May 2006 18:48:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlZUL-0004HD-Iq for lemonade@ietf.org; Wed, 31 May 2006 18:48:29 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlY2G-0001nq-8d for lemonade@ietf.org; Wed, 31 May 2006 17:15:24 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FlXr9-0008Ts-2v for lemonade@ietf.org; Wed, 31 May 2006 17:03:56 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k4VL3pu21693 for ; Wed, 31 May 2006 17:03:52 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 31 May 2006 17:03:26 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D0A58F134@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Interim Meeting - Day 2 Thread-Index: AcaE9aknodwG6ixTTn+/0p76ccLA7Q== From: "Glenn Parsons" To: X-Spam-Score: -2.6 (--) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Subject: [lemonade] Interim Meeting - Day 2 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0614927342==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============0614927342== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C684F5.9DF09281" This is a multi-part message in MIME format. ------_=_NextPart_001_01C684F5.9DF09281 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, Thanks for the good discussion today. Noting we have several participants on the other side of the pond, we will start at 8:30am ET tomorrow. The plan is to end by 3pm, but we might even finish earlier. Cheers, Glenn. ------_=_NextPart_001_01C684F5.9DF09281 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Interim Meeting - Day 2

Folks,

Thanks for the good discussion = today.

Noting we have several participants on = the other side of the pond, we will start at 8:30am ET = tomorrow.

The plan is to end by 3pm, but we might = even finish earlier.

Cheers,
Glenn.

------_=_NextPart_001_01C684F5.9DF09281-- --===============0614927342== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --===============0614927342==--