From lemonade-bounces@ietf.org Mon Mar 05 15:56:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOKDw-0007Zm-4H; Mon, 05 Mar 2007 15:56:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOK9Y-0001zd-Ov; Mon, 05 Mar 2007 15:51:28 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HOK9Y-0000Io-27; Mon, 05 Mar 2007 15:51:28 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 3BA512ACC3; Mon, 5 Mar 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HOK8A-0005fH-Ur; Mon, 05 Mar 2007 15:50:02 -0500 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, 05 Mar 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-msgevent-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 : Internet Message Store Events Author(s) : C. Newman Filename : draft-ietf-lemonade-msgevent-01.txt Pages : 14 Date : 2007-3-5 One of the missing features in the existing Internet mail and messaging standards is a facility for server-to-server and server-to- client event notifications related to message store events. As the scope of Internet mail expands to support more diverse media (such as voice mail), devices (such as cell phones) and to provide rich interactions with other services (such as web portals and legal compliance systems), the need for an interoperable notification system increases. This document attempts to enumerate the types of events which interest real-world consumers of such a system. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-msgevent-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-msgevent-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-msgevent-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: <2007-3-5122208.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-msgevent-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-msgevent-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-5122208.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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --NextPart-- From lemonade-bounces@ietf.org Wed Mar 07 18:10:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP5HU-0001xZ-3N; Wed, 07 Mar 2007 18:10:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP5HS-0001vO-OR for lemonade@ietf.org; Wed, 07 Mar 2007 18:10:46 -0500 Received: from mail146.messagelabs.com ([216.82.245.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HP5HR-000598-Jn for lemonade@ietf.org; Wed, 07 Mar 2007 18:10:46 -0500 X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-3.tower-146.messagelabs.com!1173309044!6089422!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 18632 invoked from network); 7 Mar 2007 23:10:44 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-3.tower-146.messagelabs.com with SMTP; 7 Mar 2007 23:10:44 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l27NAipG016821 for ; Wed, 7 Mar 2007 18:10:44 -0500 (EST) Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l27NAfXg016798 for ; Wed, 7 Mar 2007 18:10:41 -0500 (EST) 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 <20070307231041gw10010g4te> (Authid: tony); Wed, 7 Mar 2007 23:10:41 +0000 Message-ID: <45EF467A.60909@att.com> Date: Wed, 07 Mar 2007 18:10:50 -0500 From: Tony Hansen User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ietf-smtp@imc.org 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: 97adf591118a232206bdb5a27b217034 Cc: lemonade@ietf.org, imapext , ietf-822 mailing list Subject: [lemonade] update to SMTP/RFC2821 about to become available 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 There is an update to RFC 2821 (Simple Mail Transfer Protocol, aka SMTP) about to become available from the secretariat in an internet-drafts repository near you. It will be discussed on the ietf-smtp@imc.org mailing list. Here are the guidelines to follow for comments on it: We want to advance RFC2821/SMTP to Draft Standard. Thus, we don't want to design anything "new" or "better" for SMTP as part of this particular effort, which would require recycling at Proposed Standard -- in fact, we want to be conservative in minimizing changes. As with any movement from DS to PS, changes should be limited to: 1) clarifications of the spec where there are discrepancies, and 2) removal of unused features. 3) The fixing of "bugs" should be limited to those that have a *very strong* consensus. *Do not* bother raising the issue of reorganizing the document once again, and/or breaking it up into separate pieces. Such emails will be summarily ignored. *Do not* ask us to reopen the NDN question (whether it is reasonable to accept a message and then send a message-type rejection, and prohibit that behavior "unless the sender can be guaranteed to be authentic"). While quite a worthy topic, this question will not be addressed in 2821bis. >>>Instead<<<, write an internet-draft that is an *UPDATE* to 2821/2821bis, and we will be happy to review such an I-D on the ietf-smtp@imc.org mailing list. Your pseudo-chair for this effort, Tony Hansen tony@att.com _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Mar 08 12:02:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPM0I-0005Di-6S; Thu, 08 Mar 2007 12:02:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPM0H-0005DY-8q for lemonade@ietf.org; Thu, 08 Mar 2007 12:02:09 -0500 Received: from ppsw-4.csi.cam.ac.uk ([131.111.8.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPM0D-0004sr-Lf for lemonade@ietf.org; Thu, 08 Mar 2007 12:02:09 -0500 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:37191) by ppsw-4.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.154]:25) with esmtpa (EXTERNAL:fanf2) id 1HPM02-0006jR-Dy (Exim 4.63) for lemonade@ietf.org (return-path ); Thu, 08 Mar 2007 17:01:54 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1HPM02-0004pT-9b (Exim 4.54) for lemonade@ietf.org (return-path ); Thu, 08 Mar 2007 17:01:54 +0000 Date: Thu, 8 Mar 2007 17:01:54 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: lemonade@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1870869256-1411204027-1173373085=:8816" Content-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f671485bda3f2f1be548f998883cfbd Subject: [lemonade] draft-fanf-smtp-quickstart-00 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 message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1870869256-1411204027-1173373085=:8816 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: The attached draft is to be discussed at the Prague meeting. I submitted it before the -00 cutoff but it was rejected: they said > Please read carefully the instructions at > http://www.ietf.org/ietf/1id-guidelines.html. Make sure that you give to > your draft proper file name and resubmit. I've had no luck getting an explanation of what they don't like about the filename, and they now seem to be ignoring my messages to ietf-action@ietf.org, so I've given up trying to get the draft published properly. Tony. -- f.a.n.finch http://dotat.at/ VIKING:: SOUTHWEST, BACKING SOUTH FOR A TIME, 4 OR 5 INCREASING 6 TO GALE 8, PERHAPS SEVERE GALE 9 LATER. MODERATE OR ROUGH BECOMING VERY ROUGH. RAIN OR SHOWERS. MODERATE OR GOOD.. --1870869256-1411204027-1173373085=:8816 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=draft-fanf-smtp-quickstart-00.txt Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME=draft-fanf-smtp-quickstart-00.txt DQoNCg0KU01UUCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFQuIEZpbmNoDQpJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVW5pdmVy c2l0eSBvZiBDYW1icmlkZ2UNCkludGVuZGVkIHN0YXR1czogU3RhbmRhcmRz IFRyYWNrICAgICAgICAgICAgICAgICAgICAgICBGZWJydWFyeSAyNCwgMjAw Nw0KRXhwaXJlczogQXVndXN0IDI4LCAyMDA3DQoNCg0KICAgICAgICAgICAg ICAgICBUaGUgUVVJQ0tTVEFSVCBTTVRQIHNlcnZpY2UgZXh0ZW5zaW9uDQog ICAgICAgICAgICAgICAgICAgICBkcmFmdC1mYW5mLXNtdHAtcXVpY2tzdGFy dC0wMA0KDQpTdGF0dXMgb2YgdGhpcyBNZW1vDQoNCiAgIEJ5IHN1Ym1pdHRp bmcgdGhpcyBJbnRlcm5ldC1EcmFmdCwgZWFjaCBhdXRob3IgcmVwcmVzZW50 cyB0aGF0IGFueQ0KICAgYXBwbGljYWJsZSBwYXRlbnQgb3Igb3RoZXIgSVBS IGNsYWltcyBvZiB3aGljaCBoZSBvciBzaGUgaXMgYXdhcmUNCiAgIGhhdmUg YmVlbiBvciB3aWxsIGJlIGRpc2Nsb3NlZCwgYW5kIGFueSBvZiB3aGljaCBo ZSBvciBzaGUgYmVjb21lcw0KICAgYXdhcmUgd2lsbCBiZSBkaXNjbG9zZWQs IGluIGFjY29yZGFuY2Ugd2l0aCBTZWN0aW9uIDYgb2YgQkNQIDc5Lg0KDQog ICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRo ZSBJbnRlcm5ldCBFbmdpbmVlcmluZw0KICAgVGFzayBGb3JjZSAoSUVURiks IGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhh dA0KICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2lu ZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtDQogICBEcmFmdHMuDQoNCiAgIElu dGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBh IG1heGltdW0gb2Ygc2l4IG1vbnRocw0KICAgYW5kIG1heSBiZSB1cGRhdGVk LCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBh dCBhbnkNCiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJ bnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlDQogICBtYXRlcmlhbCBvciB0 byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4i DQoNCiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNh biBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRm LzFpZC1hYnN0cmFjdHMudHh0Lg0KDQogICBUaGUgbGlzdCBvZiBJbnRlcm5l dC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vzc2VkIGF0 DQogICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sLg0KDQogICBU aGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIEF1Z3VzdCAyOCwg MjAwNy4NCg0KQ29weXJpZ2h0IE5vdGljZQ0KDQogICBDb3B5cmlnaHQgKEMp IFRoZSBJRVRGIFRydXN0ICgyMDA3KS4NCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQpGaW5jaCAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1 c3QgMjgsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgMV0NCgwNCkludGVy bmV0LURyYWZ0ICAgIFRoZSBRVUlDS1NUQVJUIFNNVFAgc2VydmljZSBleHRl bnNpb24gICAgRmVicnVhcnkgMjAwNw0KDQoNCkFic3RyYWN0DQoNCiAgIFRo aXMgbWVtbyBzcGVjaWZpZXMgbW9kaWZpY2F0aW9ucyB0byBTTVRQJ3Mgc3Rh cnQtdXAgc2VxdWVuY2Ugd2hpY2gNCiAgIHJlZHVjZSB0aGUgbnVtYmVyIG9m IHJvdW5kIHRyaXBzIGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIHNlcnZl cg0KICAgYmVmb3JlIG1lc3NhZ2UgdHJhbnNtaXNzaW9uIHN0YXJ0cy4gIFRo aXMgY2FuIHNpZ25pZmljYW50bHkgcmVkdWNlDQogICB0aGUgZGVsYXkgZm9y IGludGVyYWN0aXZlIG1lc3NhZ2Ugc3VibWlzc2lvbiBvdmVyIHNsb3cgbGlu a3MuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQpGaW5jaCAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3Qg MjgsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgMl0NCgwNCkludGVybmV0 LURyYWZ0ICAgIFRoZSBRVUlDS1NUQVJUIFNNVFAgc2VydmljZSBleHRlbnNp b24gICAgRmVicnVhcnkgMjAwNw0KDQoNCkRvY3VtZW50IHJldmlzaW9uDQoN CiAgICRDYW1icmlkZ2U6IGhlcm1lcy9kb2MvcXNtdHAvZHJhZnQtZmFuZi1z bXRwLXF1aWNrc3RhcnQueG1sLHYgMS4yMA0KICAgMjAwNy8wMi8yNCAxMDo1 MDowNCBmYW5mMiBFeHAgJA0KDQoNClRhYmxlIG9mIENvbnRlbnRzDQoNCiAg IDEuICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNA0KICAgMi4gIFRlcm1pbm9sb2d5 ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICA1DQogICAzLiAgUVVJQ0tTVEFSVCBTTVRQIHNlcnZpY2UgZXh0 ZW5zaW9uIGRlZmluaXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gIDYNCiAgIDQu ICBFeHRlbmRlZCBzZXJ2ZXIgZ3JlZXRpbmcgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgNw0KICAgNS4gIFRoZSBRSExPIGNvbW1h bmQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICA4DQogICA2LiAgVGhlIFFUTFMgY29tbWFuZCAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDkNCiAgIDcuICBD aGFuZ2VzIHRvIHRoZSBBVVRIIGNvbW1hbmQgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAxMQ0KICAgOC4gIElzc3VpbmcgY29tbWFuZHMg ZWFybHkgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDEyDQogICA5LiAgQ2hhbmdlcyB0byB0aGUgU1RBUlRUTFMgY29tbWFuZCAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTQNCiAgIDEwLiBCYWNr d2FyZHMgY29tcGF0aWJpbGl0eSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAxNQ0KICAgMTEuIElBTkEgQ29uc2lkZXJhdGlvbnMg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE2 DQogICAxMi4gU2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTcNCiAgIDEzLiBSZWZlcmVu Y2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAxOA0KICAgICAxMy4xLiAgTm9ybWF0aXZlIHJlZmVyZW5j ZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE4DQog ICAgIDEzLjIuICBJbmZvcm1hdGl2ZSByZWZlcmVuY2VzICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTgNCiAgIEFwcGVuZGl4IEEuICBF eGFtcGxlIHJvdW5kIHRyaXAgc3VtbWFyaWVzICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAyMA0KICAgQXV0aG9yJ3MgQWRkcmVzcyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI3DQogICBJ bnRlbGxlY3R1YWwgUHJvcGVydHkgYW5kIENvcHlyaWdodCBTdGF0ZW1lbnRz IC4gLiAuIC4gLiAuIC4gLiAuIC4gMjgNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KRmluY2ggICAgICAgICAg ICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDI4LCAyMDA3ICAgICAgICAgICAg ICAgIFtQYWdlIDNdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICBUaGUgUVVJQ0tT VEFSVCBTTVRQIHNlcnZpY2UgZXh0ZW5zaW9uICAgIEZlYnJ1YXJ5IDIwMDcN Cg0KDQoxLiAgSW50cm9kdWN0aW9uDQoNCiAgIFRoZSBzdGFydCBvZiBhbiBT TVRQIGNvbm5lY3Rpb24gaXMgbm90IGN1cnJlbnRseSBvcHRpbWl6ZWQgdG8g cmVkdWNlDQogICB0aGUgbnVtYmVyIG9mIHJvdW5kIHRyaXBzIGJldHdlZW4g dGhlIGNsaWVudCBhbmQgc2VydmVyLiAgVGhpcyBpcyBhDQogICBwYXJ0aWN1 bGFyIHByb2JsZW0gZm9yIG1lc3NhZ2Ugc3VibWlzc2lvbiBvdmVyIHNsb3cg bGlua3MsIHdoZXJlIHRoZQ0KICAgcmVzdWx0aW5nIGRlbGF5IGNhbiBlYXNp bHkgYmUgbW9yZSB0aGFuIGEgc2Vjb25kLiAgVGhlIFFVSUNLU1RBUlQNCiAg IFNNVFAgc2VydmljZSBleHRlbnNpb24gaW50cm9kdWNlcyBzb21lIGNoYW5n ZXMgd2hpY2ggZWxpbWluYXRlIHJvdW5kDQogICB0cmlwcyBhbmQgdGhlcmVm b3JlIHJlZHVjZSB0aGUgZGVsYXkgYmVmb3JlIG1lc3NhZ2VzIGNhbiBiZQ0K ICAgdHJhbnNtaXR0ZWQuICBUaGUga2V5IGZlYXR1cmVzIG9mIHRoZSBleHRl bnNpb24gYXJlOg0KDQogICBvICBFYXJsaWVyIGFubm91bmNlbWVudCBvZiB0 aGUgbGlzdCBvZiBTTVRQIHNlcnZpY2UgZXh0ZW5zaW9ucw0KICAgICAgc3Vw cG9ydGVkIGJ5IHRoZSBzZXJ2ZXIuDQoNCiAgIG8gIFRoZSBRSExPIGFuZCBR VExTIGNvbW1hbmRzLCB3aGljaCBhcmUgcXVpY2tlciByZXBsYWNlbWVudHMg Zm9yIHRoZQ0KICAgICAgRUhMTyBhbmQgU1RBUlRUTFMgY29tbWFuZHMuDQoN CiAgIG8gIFRoZSBhYmlsaXR5IHRvIHBpcGVsaW5lIHRoZSBTVEFSVFRMUyBh bmQgQVVUSCBjb21tYW5kcy4NCg0KICAgbyAgQSBtZWNoYW5pc20gdG8gYWxs b3cgdGhlIGNsaWVudCB0byBpc3N1ZSBjb21tYW5kcyB3aXRob3V0IGFsd2F5 cw0KICAgICAgaGF2aW5nIHRvIHdhaXQgZm9yIHRoZSBzZXJ2ZXIncyBleHRl bnNpb24gbGlzdC4NCg0KICAgRWFjaCBvZiB0aGVzZSBmZWF0dXJlcyBoYXMg YWR2YW50YWdlcyBieSBpdHNlbGYsIGFuZCB0aGV5IGNhbiBiZSB1c2VkDQog ICB0b2dldGhlciB0byBwcm92aWRlIGdyZWF0ZXIgaW1wcm92ZW1lbnRzLiAg UVVJQ0tTVEFSVCBpcyBkZXNpZ25lZA0KICAgd2l0aCB0d28gcHJvZmlsZXMg aW4gbWluZDogdGhlIGJhc2ljIHByb2ZpbGUgdXNlcyB0aGUgUUhMTyBhbmQg UVRMUw0KICAgY29tbWFuZHMgYW5kIHRoZSBwaXBlbGluZWQgQVVUSCBjb21t YW5kIHRvIGJyaW5nIHRoZSBmaXJzdCBNQUlMDQogICBjb21tYW5kIGZvcndh cmQgZnJvbSB0aGUgY2xpZW50J3MgOXRoIHBhY2tldCB0byB0aGUgNXRoOyB0 aGUgZnVsbA0KICAgcHJvZmlsZSB1c2VzIHRoZSA8cWhsby1pZD4gYW5kIHBp cGVsaW5lZCBTVEFSVFRMUyB0byBicmluZyBpdCBhcw0KICAgZWFybHkgYXMg dGhlIDNyZC4gIEFwcGVuZGl4IEEgaWxsdXN0cmF0ZXMgdGhlc2UgY291bnRz IGluIG1vcmUNCiAgIGRldGFpbC4NCg0KICAgQWx0aG91Z2ggU01UUCBRVUlD S1NUQVJUIGlzIHByb2JhYmx5IG1vc3QgdXNlZnVsIGluIGNvbmp1bmN0aW9u IHdpdGgNCiAgIG1lc3NhZ2Ugc3VibWlzc2lvbiBbUkZDNDQwOV0sIGl0IE1B WSBhbHNvIGJlIHVzZWQgd2l0aCBNVEEtdG8tTVRBDQogICBTTVRQIC0gdGhv dWdoIGF0dGVudGlvbiBzaG91bGQgYmUgcGFpZCB0byB0aGUgc2VjdXJpdHkg Y29uc2lkZXJhdGlvbnMNCiAgIGluIFNlY3Rpb24gMTIuDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KRmluY2ggICAgICAgICAgICAgICAg ICAgIEV4cGlyZXMgQXVndXN0IDI4LCAyMDA3ICAgICAgICAgICAgICAgIFtQ YWdlIDRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICBUaGUgUVVJQ0tTVEFSVCBT TVRQIHNlcnZpY2UgZXh0ZW5zaW9uICAgIEZlYnJ1YXJ5IDIwMDcNCg0KDQoy LiAgVGVybWlub2xvZ3kNCg0KICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJN VVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLA0K ICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1B WSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMNCiAgIGRvY3VtZW50IGFyZSB0 byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gW1JGQzIxMTldLg0K DQogICBUaGUgbWV0YWxpbmd1aXN0aWMgbm90YXRpb24gdXNlZCBpbiB0aGlz IG1lbW8gY29ycmVzcG9uZHMgdG8gdGhlDQogICAiQXVnbWVudGVkIEJORiIg dXNlZCBpbiBvdGhlciBJbnRlcm5ldCBtYWlsIHN5c3RlbSBtZW1vcy4gIFRo ZSByZWFkZXINCiAgIHdobyBpcyBub3QgZmFtaWxpYXIgd2l0aCB0aGF0IHN5 bnRheCBzaG91bGQgY29uc3VsdCB0aGUgQUJORg0KICAgc3BlY2lmaWNhdGlv biBbUkZDNDIzNF0uICBSdWxlcyBub3QgZGVmaW5lZCBpbiB0aGlzIHNwZWNp ZmljYXRpb24gYXJlDQogICBlaXRoZXIgZGVmaW5lZCBpbiB0aGUgQUJORiBj b3JlIHJ1bGVzIG9yIGluIFtSRkMyODIxXS4gIE1ldGFsYW5ndWFnZQ0KICAg dGVybXMgdXNlZCBpbiBydW5uaW5nIHRleHQgYXJlIHN1cnJvdW5kZWQgYnkg cG9pbnRlZCBicmFja2V0cyAoZS5nLiwNCiAgIDxsaXN0LWlkPikgZm9yIGNs YXJpdHkuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KRmluY2gg ICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDI4LCAyMDA3ICAg ICAgICAgICAgICAgIFtQYWdlIDVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICBU aGUgUVVJQ0tTVEFSVCBTTVRQIHNlcnZpY2UgZXh0ZW5zaW9uICAgIEZlYnJ1 YXJ5IDIwMDcNCg0KDQozLiAgUVVJQ0tTVEFSVCBTTVRQIHNlcnZpY2UgZXh0 ZW5zaW9uIGRlZmluaXRpb24NCg0KICAgVGhlIFFVSUNLU1RBUlQgU01UUCBz ZXJ2aWNlIGV4dGVuc2lvbiBpcyBkZWZpbmVkIGFzIGZvbGxvd3M6DQoNCiAg IG8gIFRoZSBuYW1lIG9mIHRoZSBzZXJ2aWNlIGV4dGVuc2lvbiBpcyAiUVVJ Q0tTVEFSVCIuDQoNCiAgIG8gIFRoZSBFSExPIGtleXdvcmQgdmFsdWUgYXNz b2NpYXRlZCB3aXRoIHRoZSBleHRlbnNpb24gaXMNCiAgICAgICJRVUlDS1NU QVJUIi4NCg0KICAgbyAgVGhlIFFVSUNLU1RBUlQgRUhMTyBrZXl3b3JkIHZh bHVlIGhhcyBmb3VyIE9QVElPTkFMIHBhcmFtZXRlcnMNCiAgICAgICgiUVRM UyIsICJBVVRIIiwgIlFITE89PHFobG8taWQ+IiwgYW5kICJTVEFSVFRMUyIp IHRvIHdoaWNoIG1vcmUNCiAgICAgIGNhbiBiZSBhZGRlZCBieSBmdXR1cmUg c3BlY2lmaWNhdGlvbnMuDQoNCiAgIG8gIFRoZSBleHRlbnNpb24gZGVmaW5l cyB0d28gYWRkaXRpb25hbCBjb21tYW5kczogIlFITE8iIGFuZCAiUVRMUyIu DQoNCiAgIG8gIFRoZXJlIGFyZSBubyBhZGRpdGlvbmFsIHBhcmFtZXRlcnMg dG8gdGhlIE1BSUwgb3IgUkNQVCBjb21tYW5kcw0KICAgICAgZGVmaW5lZCBi eSB0aGlzIGV4dGVuc2lvbiBhbmQgdGhlaXIgbWF4aW11bSBsZW5ndGhzIGFy ZSBub3QNCiAgICAgIGluY3JlYXNlZC4NCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN CkZpbmNoICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyOCwg MjAwNyAgICAgICAgICAgICAgICBbUGFnZSA2XQ0KDA0KSW50ZXJuZXQtRHJh ZnQgICAgVGhlIFFVSUNLU1RBUlQgU01UUCBzZXJ2aWNlIGV4dGVuc2lvbiAg ICBGZWJydWFyeSAyMDA3DQoNCg0KNC4gIEV4dGVuZGVkIHNlcnZlciBncmVl dGluZw0KDQogICBBbiBTTVRQIHNlcnZlciB0aGF0IHN1cHBvcnRzIFFVSUNL U1RBUlQgTVVTVCByZXNwb25kIHRvIHRoZSBjbGllbnQncw0KICAgY29ubmVj dGlvbiB3aXRoIGFuIGV4dGVuZGVkIGdyZWV0aW5nIGFjY29yZGluZyB0byB0 aGUgc3ludGF4IGJlbG93Lg0KICAgVGhpcyBncmVldGluZyBoYXMgYSBzaW1p bGFyIGZvcm1hdCB0byB0aGUgU01UUCBFSExPIHJlc3BvbnNlLCB0aGF0DQog ICBpcywgdGhlIGZpcnN0IGxpbmUgaXMgdGhlIHNhbWUgYXMgYW4gdW4tZXh0 ZW5kZWQgZ3JlZXRpbmcsIGFuZA0KICAgc3Vic2VxdWVudCBsaW5lcyBsaXN0 IHRoZSBTTVRQIHNlcnZpY2UgZXh0ZW5zaW9ucyBzdXBwb3J0ZWQgYnkgdGhl DQogICBzZXJ2ZXIuICBUaGUgbGlzdCBNVVNUIGluY2x1ZGUgdGhlIFFVSUNL U1RBUlQga2V5d29yZCBhbmQgU0hPVUxEDQogICBpbmNsdWRlIFBJUEVMSU5J TkcgW1JGQzI5MjBdLg0KDQogICBUaGUgZXh0ZW5kZWQgZ3JlZXRpbmcgYWxs b3dzIGEgY2xpZW50IHRvIGZpbmQgb3V0IHRoZSBzZXJ2ZXIncw0KICAgc3Vw cG9ydGVkIGV4dGVuc2lvbnMgb25lIHJvdW5kIHRyaXAgZWFybGllciB0aGFu IGluIG5vcm1hbCBTTVRQLg0KDQogICBTeW50YXg6DQoNCiAgICAgICAgcXNt dHAtZ3JlZXQgID0gICggICAgIjIyMC0iICAgZG9tYWluIFsgU1AgZWhsby1n cmVldCBdIENSTEYNCiAgICAgICAgICAgICAgICAgICAgICAgICAgKiggIjIy MC0iICAgZWhsby1saW5lICAgICAgICAgICAgICAgIENSTEYgKQ0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAiMjIwIiBTUCBlaGxvLWxpbmUgICAg ICAgICAgICAgICAgQ1JMRiAgICkNCg0KICAgICAgICBlaGxvLWxpbmUgICAg PS8gIlFVSUNLU1RBUlQiICooIFNQIHFzbXRwLXBhcmFtICkNCg0KICAgICAg ICBxc210cC1wYXJhbSAgPSAgIlFITE89IiBxaGxvLWlkIC8gIlFUTFMiIC8N CiAgICAgICAgICAgICAgICAgICAgICAgICJBVVRIIiAvICJTVEFSVFRMUyIg Lw0KICAgICAgICAgICAgICAgICAgICAgICAgZXNtdHAtcGFyYW0NCg0KICAg ICAgICBxaGxvLWlkICAgICAgPSAgZXNtdHAtdmFsdWUNCg0KICAgVGhlIFFV SUNLU1RBUlQga2V5d29yZCBNQVkgYmUgZm9sbG93ZWQgYnkgcGFyYW1ldGVy cyB0aGF0IGluZGljYXRlDQogICB3aGljaCBPUFRJT05BTCBmZWF0dXJlcyBv ZiB0aGlzIHNwZWNpZmljYXRpb24gYXJlIHN1cHBvcnRlZCBieSB0aGUNCiAg IHNlcnZlci4gIENsaWVudHMgTVVTVCBpZ25vcmUgUVVJQ0tTVEFSVCBwYXJh bWV0ZXJzIHRoYXQgdGhleSBkbyBub3QNCiAgIHVuZGVyc3RhbmQuICBUaGUg Zm9sbG93aW5nIHBhcmFtZXRlcnMgYXJlIGRlZmluZWQgaW4gdGhpcw0KICAg c3BlY2lmaWNhdGlvbjoNCg0KICAgbyAgVGhlICJRVExTIiBwYXJhbWV0ZXIg aW5kaWNhdGVzIHRoYXQgdGhlIHNlcnZlciBzdXBwb3J0cyB0aGUgUVRMUw0K ICAgICAgY29tbWFuZCBzcGVjaWZpZWQgaW4gU2VjdGlvbiA2Lg0KDQogICBv ICBUaGUgIkFVVEgiIHBhcmFtZXRlciBpbmRpY2F0ZXMgdGhhdCB0aGUgc2Vy dmVyIHN1cHBvcnRzIHBpcGVsaW5pbmcNCiAgICAgIG9mIHRoZSBBVVRIIGNv bW1hbmQgYXMgc3BlY2lmaWVkIGluIFNlY3Rpb24gNy4NCg0KICAgbyAgVGhl ICJRSExPPTxxaGxvLWlkPiIgcGFyYW1ldGVyIGluZGljYXRlcyB0aGF0IHRo ZSBzZXJ2ZXIgYWxsb3dzDQogICAgICB0aGUgY2xpZW50IHRvIGlzc3VlIGNv bW1hbmRzIGJlZm9yZSByZWNlaXZpbmcgdGhlIHNlcnZlcidzIGxpc3Qgb2YN CiAgICAgIHN1cHBvcnRlZCBleHRlbnNpb25zLCBhcyBkZXNjcmliZWQgaW4g U2VjdGlvbiA4Lg0KDQogICBvICBUaGUgIlNUQVJUVExTIiBwYXJhbWV0ZXIg aW5kaWNhdGVzIHRoYXQgdGhlIHNlcnZlciBzdXBwb3J0cw0KICAgICAgcGlw ZWxpbmluZyBvZiB0aGUgU1RBUlRUTFMgY29tbWFuZCBhcyBzcGVjaWZpZWQg aW4gU2VjdGlvbiA5Lg0KDQoNCg0KDQoNCg0KRmluY2ggICAgICAgICAgICAg ICAgICAgIEV4cGlyZXMgQXVndXN0IDI4LCAyMDA3ICAgICAgICAgICAgICAg IFtQYWdlIDddDQoMDQpJbnRlcm5ldC1EcmFmdCAgICBUaGUgUVVJQ0tTVEFS VCBTTVRQIHNlcnZpY2UgZXh0ZW5zaW9uICAgIEZlYnJ1YXJ5IDIwMDcNCg0K DQo1LiAgVGhlIFFITE8gY29tbWFuZA0KDQogICBUaGUgUUhMTyBjb21tYW5k IGhhcyB0d28gZm9ybXMuICBTdXBwb3J0IGZvciB0aGUgYmFzaWMgZm9ybSBk ZWZpbmVkDQogICBpbiB0aGlzIHNlY3Rpb24gaXMgUkVRVUlSRUQuICBUaGUg ZnVsbCBmb3JtIGlzIE9QVElPTkFMLCBhbmQgaXMNCiAgIGRlZmluZWQgaW4g U2VjdGlvbiA4Lg0KDQogICBBbiBTTVRQIGNsaWVudCB0aGF0IHN1cHBvcnRz IFFVSUNLU1RBUlQgTVVTVCBmaXJzdCBlbnN1cmUgdGhhdCB0aGUNCiAgIHNl cnZlciBzdXBwb3J0cyBpdCBieSBjaGVja2luZyB0aGUgc2VydmVyJ3MgZ3Jl ZXRpbmcgYWdhaW5zdCB0aGUNCiAgIHN5bnRheCBzcGVjaWZpZWQgaW4gU2Vj dGlvbiA0LiAgVGhlIGNsaWVudCB0aGVuIGlzc3VlcyBRSExPIGFzIGl0cw0K ICAgZmlyc3QgY29tbWFuZCBpbnN0ZWFkIG9mIEVITE8uICBUaGUgYmFzaWMg Zm9ybSBvZiBRSExPIGhhcyB0aGUgc2FtZQ0KICAgc2VtYW50aWNzIGFzIHRo ZSBFSExPIGNvbW1hbmQsIGV4Y2VwdCB0aGF0IGl0IE1BWSBiZSBwaXBlbGlu ZWQgaWYgdGhlDQogICBzZXJ2ZXIgYWxzbyBzdXBwb3J0cyBQSVBFTElOSU5H IFtSRkMyOTIwXSwgYW5kIHRoZSBzZXJ2ZXIncyAyMjANCiAgIHJlc3BvbnNl IHRvIFFITE8gZG9lcyBub3QgaW5jbHVkZSBpdHMgbGlzdCBvZiBzdXBwb3J0 ZWQgZXh0ZW5zaW9ucy4NCg0KICAgVGhlIHBpcGVsaW5lZCBRSExPIGNvbW1h bmQgYWxsb3dzIGEgY2xpZW50IHRvIHNhdmUgb25lIHJvdW5kIHRyaXAgYnkN CiAgIG5vdCBoYXZpbmcgdG8gd2FpdCBmb3IgdGhlIHNlcnZlcidzIHJlc3Bv bnNlIGJlZm9yZSBpc3N1aW5nIGZ1cnRoZXINCiAgIGNvbW1hbmRzLg0KDQog ICBTeW50YXg6DQoNCiAgICAgICAgcWhsbyAgICAgICAgID0gICJRSExPIiBT UCBEb21haW4gQ1JMRg0KDQogICAgICAgIHFobG8tb2stcnNwICA9ICAiMjIw IiBTUCBkb21haW4gWyBTUCBlaGxvLWdyZWV0IF0gQ1JMRg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQpGaW5jaCAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjgs IDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgOF0NCgwNCkludGVybmV0LURy YWZ0ICAgIFRoZSBRVUlDS1NUQVJUIFNNVFAgc2VydmljZSBleHRlbnNpb24g ICAgRmVicnVhcnkgMjAwNw0KDQoNCjYuICBUaGUgUVRMUyBjb21tYW5kDQoN CiAgIFN1cHBvcnQgZm9yIHRoZSBRVExTIGNvbW1hbmQgaXMgT1BUSU9OQUws IGFuZCBpcyBpbmRpY2F0ZWQgYnkgdGhlDQogICBwcmVzZW5jZSBvZiB0aGUg UVRMUyBwYXJhbWV0ZXIgYWZ0ZXIgdGhlIFFVSUNLU1RBUlQga2V5d29yZCBp biB0aGUNCiAgIGxpc3Qgb2YgZXh0ZW5zaW9ucyBzdXBwb3J0ZWQgYnkgdGhl IHNlcnZlci4gIElmIHRoZSBzZXJ2ZXIgc3VwcG9ydHMNCiAgIGJvdGggU1RB UlRUTFMgW1JGQzMyMDddIGFuZCBRVUlDS1NUQVJUIHRoZW4gaXQgU0hPVUxE IGFsc28gc3VwcG9ydA0KICAgUVRMUy4NCg0KICAgU3ludGF4Og0KDQogICAg ICAgIHF0bHMgID0gICJRVExTIiBDUkxGDQoNCiAgIFRoZSBRVExTIGNvbW1h bmQgaGFzIG5vIHBhcmFtZXRlcnMuICBBZnRlciBpc3N1aW5nIHRoZSBRVExT IGNvbW1hbmQsDQogICB0aGUgY2xpZW50IGltbWVkaWF0ZWx5IHN0YXJ0cyB0 aGUgVExTIGhhbmRzaGFrZS4gIFRoZSBzZXJ2ZXIgTVVTVCBOT1QNCiAgIGlz c3VlIGFuIFNNVFAgcmVzcG9uc2UgdG8gdGhlIFFUTFMgY29tbWFuZCBiZWZv cmUgdGhlIFRMUyBoYW5kc2hha2UuDQogICBUaGVyZWZvcmUgaXQgaXMgbm90 IHBvc3NpYmxlIGZvciB0aGUgc2VydmVyIHRvIHJlcG9ydCBwcm9ibGVtcyAo YXMNCiAgIHdpdGggdGhlIDQ1NCByZXNwb25zZSB0byB0aGUgU1RBUlRUTFMg Y29tbWFuZCkgZXhjZXB0IGJ5IGNsb3NpbmcgdGhlDQogICBjb25uZWN0aW9u IC0gd2hpY2ggaXQgU0hPVUxEIE5PVCBkby4gIEluc3RlYWQsIHRoZSBzZXJ2 ZXIgU0hPVUxEDQogICBlbnN1cmUgdGhhdCBpdCBjYW4gc3VwcG9ydCBUTFMg KGUuZy4gYnkgaW5pdGlhbGl6aW5nIGl0cyBUTFMgbGlicmFyeSkNCiAgIGJl Zm9yZSBsaXN0aW5nIHRoZSBleHRlbnNpb25zIGl0IHN1cHBvcnRzLCByYXRo ZXIgdGhhbiBsYXppbHkgaW4NCiAgIHJlYWN0aW9uIHRvIGEgUVRMUyBvciBT VEFSVFRMUyBjb21tYW5kLg0KDQogICBBZnRlciB0aGUgVExTIGhhbmRzaGFr ZSBoYXMgYmVlbiBjb21wbGV0ZWQsIHRoZSBTTVRQIHByb3RvY29sIGlzDQog ICByZXNldCB0byB0aGUgc3RhdGUgYXQgdGhlIHN0YXJ0IG9mIGEgY29ubmVj dGlvbiwgc28gdGhlIHNlcnZlcg0KICAgcHJvY2VlZHMgdG8gaXNzdWUgYSBR VUlDS1NUQVJUIGV4dGVuZGVkIDIyMCBncmVldGluZyA8cXNtdHAtZ3JlZXQ+ Lg0KDQogICBJZiB0aGUgc2VydmVyIHJlcXVpcmVzIHRoYXQgdGhlIGNsaWVu dCBwZXJmb3JtcyBhIFRMUyBuZWdvdGlhdGlvbg0KICAgYmVmb3JlIGl0IGFj Y2VwdHMgYW55IGNvbW1hbmRzLCB0aGVuIGl0IFNIT1VMRCBhY2NlcHQgdGhl IFFITE8gYW5kDQogICBRVExTIGNvbW1hbmRzIGJlZm9yZSBUTFMgbmVnb3Rp YXRpb24sIGFzIHdlbGwgYXMgdGhlIE5PT1AsIEVITE8sDQogICBTVEFSVFRM UywgYW5kIFFVSVQgY29tbWFuZHMgc3BlY2lmaWVkIGluIFtSRkMzMjA3XQ0K DQogICBBcGFydCBmcm9tIHRoZXNlIGRpZmZlcmVuY2VzLCB0aGUgUVRMUyBj b21tYW5kIGlzIHRoZSBzYW1lIGFzIHRoZQ0KICAgU1RBUlRUTFMgY29tbWFu ZCwgYW5kIHRoZSBvdGhlciByZXF1aXJlbWVudHMgc3BlY2lmaWVkIGluIFtS RkMzMjA3XQ0KICAgYXBwbHkuDQoNCiAgIFRoZSBRVExTIGNvbW1hbmQgc2F2 ZXMgb25lIHJvdW5kIHRyaXAgYmVmb3JlIHRoZSBUTFMgaGFuZHNoYWtlIGJ5 DQogICBvbWl0dGluZyB0aGUgc2VydmVyJ3MgcmVzcG9uc2UsIGFuZCBzYXZl cyBhbm90aGVyIGFmdGVyIHRoZSBUTFMNCiAgIGhhbmRzaGFrZSBieSBhbm5v dW5jaW5nIHRoZSBsaXN0IG9mIGV4dGVuc2lvbnMgc3VwcG9ydGVkIGJ5IHRo ZQ0KICAgc2VydmVyIGVhcmxpZXIgdGhhbiBpcyB0eXBpY2FsIHdpdGggU1RB UlRUTFMuDQoNCiAgIENsaWVudHMgd2lsbCBnZW5lcmFsbHkgd2FudCB0byBp c3N1ZSB0aGUgUVRMUyBjb21tYW5kIGF0IHRoZSBzdGFydCBvZg0KICAgYSBj b25uZWN0aW9uLCBpbW1lZGlhdGVseSBhZnRlciB0aGUgUUhMTyBjb21tYW5k LiAgVGhlIG1vc3QgZWZmaWNpZW50DQogICB3YXkgb2YgZG9pbmcgc28gaXMg dG8gcGlwZWxpbmUgUUhMTywgUVRMUywgYW5kIHRoZSBUTFMgaGFuZHNoYWtl LCBidXQNCiAgIHRoZW4gaXQgY2FuIGJlIGRpZmZpY3VsdCB0byBkaXNlbnRh bmdsZSB0aGUgc2VydmVyJ3MgcmVzcG9uc2UgdG8gUUhMTw0KICAgZnJvbSBp dHMgc2lkZSBvZiB0aGUgVExTIGhhbmRzaGFrZS4gIFRoZXJlZm9yZSBzZXJ2 ZXJzIE1VU1QgYWxsb3cNCiAgIGNsaWVudHMgdG8gaXNzdWUgdGhlIFFUTFMg Y29tbWFuZCB3aXRob3V0IGlzc3VpbmcgUUhMTyBvciBFSExPIGZpcnN0LA0K ICAgdGhvdWdoIHRoZXkgTUFZIHJlcXVpcmUgdGhhdCB0aGUgY2xpZW50IGRv ZXMgbm90IGlzc3VlIHRoZSBRSExPDQogICBjb21tYW5kIGJlZm9yZSByZWNl aXZpbmcgdGhlIHNlcnZlcidzIGdyZWV0aW5nLiAgVGhpcyBpcyBpbGx1c3Ry YXRlZA0KDQoNCg0KRmluY2ggICAgICAgICAgICAgICAgICAgIEV4cGlyZXMg QXVndXN0IDI4LCAyMDA3ICAgICAgICAgICAgICAgIFtQYWdlIDldDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICBUaGUgUVVJQ0tTVEFSVCBTTVRQIHNlcnZpY2Ug ZXh0ZW5zaW9uICAgIEZlYnJ1YXJ5IDIwMDcNCg0KDQogICBpbiBBcHBlbmRp eCBBLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCkZpbmNoICAgICAgICAgICAgICAgICAgICBFeHBp cmVzIEF1Z3VzdCAyOCwgMjAwNyAgICAgICAgICAgICAgIFtQYWdlIDEwXQ0K DA0KSW50ZXJuZXQtRHJhZnQgICAgVGhlIFFVSUNLU1RBUlQgU01UUCBzZXJ2 aWNlIGV4dGVuc2lvbiAgICBGZWJydWFyeSAyMDA3DQoNCg0KNy4gIENoYW5n ZXMgdG8gdGhlIEFVVEggY29tbWFuZA0KDQogICBUaGlzIHNlY3Rpb24gZGVz Y3JpYmVzIGFuIE9QVElPTkFMIGNoYW5nZSB0byB0aGUgYmVoYXZpb3VyIG9m IHRoZQ0KICAgQVVUSCBjb21tYW5kIFtSRkMyNTU0XSwgc3VwcG9ydCBmb3Ig d2hpY2ggaXMgaW5kaWNhdGVkIGJ5IHRoZQ0KICAgcHJlc2VuY2Ugb2YgdGhl IEFVVEggcGFyYW1ldGVyIGFmdGVyIHRoZSBRVUlDS1NUQVJUIGtleXdvcmQg aW4gdGhlDQogICBsaXN0IG9mIGV4dGVuc2lvbnMgc3VwcG9ydGVkIGJ5IHRo ZSBzZXJ2ZXIuICBUaGlzIGNoYW5nZSBpcyBhbHNvDQogICBzcGVjaWZpZWQg YnkgW1JGQzQ0NjhdLCBzbyBpZiB0aGUgc2VydmVyIGxpc3RzIHN1cHBvcnQg Zm9yIEJVUkwgYW5kDQogICBRVUlDS1NUQVJUIGFuZCBQSVBFTElOSU5HIHRo ZW4gaXQgTVVTVCBpbmNsdWRlIHRoZSBRVUlDS1NUQVJUIEFVVEgNCiAgIHBh cmFtZXRlci4NCg0KICAgSWYgdGhlIGNsaWVudCB1c2VzIGEgU0FTTCBtZWNo YW5pc20gd2hpY2ggY2FuIGJlIGNvbXBsZXRlZCBpbiBvbmUNCiAgIHJvdW5k IHRyaXAsIHN1Y2ggYXMgRVhURVJOQUwgW1JGQzQ0MjJdIG9yIFBMQUlOIFtS RkM0NjE2XSwgdGhlbiBpdA0KICAgTUFZIHBpcGVsaW5lIHRoZSBBVVRIIGNv bW1hbmQuICBJZiB0aGUgYXV0aGVudGljYXRpb24gZmFpbHMsIHRoZQ0KICAg c2VydmVyIFNIT1VMRCByZWplY3QgYWxsIHN1YnNlcXVlbnQgY29tbWFuZHMg b3RoZXIgdGhhbiBBVVRILCBOT09QLA0KICAgSEVMTywgRUhMTywgUUhMTywg b3IgUVVJVCB3aXRoIGEgIjUzMCBBdXRoZW50aWNhdGlvbiBmYWlsdXJlIiBy ZXBseS4NCiAgIElmIHRoZSBzZXJ2ZXIgc3VwcG9ydHMgRU5IQU5DRURTVEFU VVNDT0RFUyBbUkZDMjAzNF0gW1JGQzM0NjNdLCB0aGUNCiAgIHN0YXR1cyBj b2RlIHRvIGJlIHJldHVybmVkIFNIT1VMRCBiZSA1LjcuMC4NCg0KICAgVGhp cyBjaGFuZ2UgYWxsb3dzIGFub3RoZXIgcm91bmQgdHJpcCB0byBiZSBzYXZl ZC4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpGaW5jaCAgICAgICAgICAgICAgICAg ICAgRXhwaXJlcyBBdWd1c3QgMjgsIDIwMDcgICAgICAgICAgICAgICBbUGFn ZSAxMV0NCgwNCkludGVybmV0LURyYWZ0ICAgIFRoZSBRVUlDS1NUQVJUIFNN VFAgc2VydmljZSBleHRlbnNpb24gICAgRmVicnVhcnkgMjAwNw0KDQoNCjgu ICBJc3N1aW5nIGNvbW1hbmRzIGVhcmx5DQoNCiAgIEl0IGlzIHBvc3NpYmxl IHRvIHNhdmUgbW9yZSByb3VuZCB0cmlwcyBpZiB0aGUgY2xpZW50IGNhbiBp c3N1ZQ0KICAgY29tbWFuZHMgYmVmb3JlIHJlY2VpdmluZyB0aGUgbGlzdCBv ZiBleHRlbnNpb25zIHN1cHBvcnRlZCBieSB0aGUNCiAgIHNlcnZlci4gIFRo ZXJlIGFyZSBvcHBvcnR1bml0aWVzIHRvIGRvIHRoaXMgYXQgdGhlIHZlcnkg c3RhcnQgb2YgdGhlDQogICBUQ1AgY29ubmVjdGlvbiwgYWZ0ZXIgdGhlIFNU QVJUVExTIGNvbW1hbmQgW1JGQzMyMDddLCBhbmQgYWZ0ZXIgdGhlDQogICBB VVRIIGNvbW1hbmQgbmVnb3RpYXRlcyBhIHNlY3VyaXR5IGxheWVyIFtSRkMy NTU0XS4gIFRoZXNlIGFyZSBjYWxsZWQNCiAgICJRVUlDS1NUQVJUIHBvaW50 cyIgaW4gdGhpcyBzZWN0aW9uLg0KDQogICBTdXBwb3J0IGZvciB0aGlzIGlz IE9QVElPTkFMLCBhbmQgaXMgaW5kaWNhdGVkIGJ5IHRoZSBwcmVzZW5jZSBv ZiB0aGUNCiAgICJRSExPPTxxaGxvLWlkPiIgcGFyYW1ldGVyIGFmdGVyIHRo ZSBRVUlDS1NUQVJUIGtleXdvcmQgaW4gdGhlIGxpc3QNCiAgIG9mIGV4dGVu c2lvbnMgc3VwcG9ydGVkIGJ5IHRoZSBzZXJ2ZXIuICBUaGUgc2VydmVyIE1V U1QgYWxzbyBzdXBwb3J0DQogICBQSVBFTElOSU5HIFtSRkMyOTIwXS4NCg0K ICAgVGhlIDxxaGxvLWlkPiBwYXJhbWV0ZXIgdmFsdWUgaXMgYSBjYXNlLXNl bnNpdGl2ZSB0b2tlbiB3aGljaA0KICAgaWRlbnRpZmllcyB0aGUgbGlzdCBv ZiBzZXJ2aWNlIGV4dGVuc2lvbnMgYW5kIGFzc29jaWF0ZWQgcGFyYW1ldGVy cw0KICAgaW4gd2hpY2ggaXQgd2FzIGluY2x1ZGVkLiAgVGhlIHNlcnZlciBN VVNUIHN0YXRlIGEgZGlmZmVyZW50DQogICA8cWhsby1pZD4gZm9yIGRpZmZl cmVudCBsaXN0cyBvZiBleHRlbnNpb25zIG9yIGlmIGFueSBvZiB0aGVpcg0K ICAgcGFyYW1ldGVycyBjaGFuZ2VzLiAgVGhpcyBnZW5lcmFsbHkgaW1wbGll cyB0aGF0IHRoZSBzZXJ2ZXIgd2lsbA0KICAgc3RhdGUgZGlmZmVyZW50IDxx aGxvLWlkPnMgYXQgZGlmZmVyZW50IFFVSUNLU1RBUlQgcG9pbnRzLiAgRm9y DQogICBleGFtcGxlLCBpZiB0aGUgc2VydmVyIG9ubHkgc3VwcG9ydHMgQVVU SCBQTEFJTiBhZnRlciBUTFMNCiAgIG5lZ290aWF0aW9uLCBpdCB3aWxsIHN0 YXRlIGEgZGlmZmVyZW50IDxxaGxvLWlkPiBpbiBpdHMgcmVzcG9uc2VzIHRv DQogICBFSExPIGJlZm9yZSBhbmQgYWZ0ZXIgU1RBUlRUTFMuICBJZiB0aGUg c2VydmVyJ3MgU0laRSBwYXJhbWV0ZXINCiAgIFtSRkMxODcwXSBjaGFuZ2Vz IGluIHJlc3BvbnNlIHRvIGF2YWlsYWJsZSBkaXNrIHNwYWNlLCBpdHMgPHFo bG8taWQ+DQogICB3aWxsIGNoYW5nZSB0b28uICBTZWN0aW9uIDEyIGluY2x1 ZGVzIHNvbWUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMNCiAgIGZvciB0aGUg PHFobG8taWQ+Lg0KDQogICBUaGUgY2xpZW50IHVzZXMgdGhlIDxxaGxvLWlk PiB3aXRoIHRoZSBmdWxsIGZvcm0gb2YgdGhlIFFITE8gY29tbWFuZC4NCg0K ICAgU3ludGF4Og0KDQogICAgICAgIHFobG8gID0vICAiUUhMTyIgU1AgRG9t YWluIFNQIHFobG8taWQgQ1JMRg0KDQogICBUaGUgPHFobG8taWQ+IGluIHRo ZSBjbGllbnQncyBRSExPIGNvbW1hbmQgTVVTVCBtYXRjaCB0aGUgPHFobG8t aWQ+DQogICBpc3N1ZWQgYnkgdGhlIHNlcnZlciBpbiBpdHMgPHFzbXRwLWdy ZWV0Piwgb3IgdGhlIDxxaGxvLWlkPiB0aGF0IHRoZQ0KICAgc2VydmVyIHdv dWxkIGhhdmUgaXNzdWVkIGluIGl0cyA8ZWhsby1vay1yc3A+IHJlc3BvbnNl IHRvIGFuIEVITE8NCiAgIGNvbW1hbmQgZnJvbSB0aGUgY2xpZW50LiAgSWYg dGhlIDxxaGxvLWlkPiBtYXRjaGVzLCB0aGUgc2VydmVyIFNIT1VMRA0KICAg cmVzcG9uZCB3aXRoIGEgPHFobG8tb2stcnNwPiByZXNwb25zZS4gIElmIHRo ZSA8cWhsby1pZD4gZG9lcyBub3QNCiAgIG1hdGNoIHRoZXJlIGFyZSB0d28g cG9zc2libGUgcmVzcG9uc2VzOiBpZiB0aGUgc2VydmVyIGhhcyBhbHJlYWR5 DQogICBsaXN0ZWQgaXRzIHN1cHBvcnRlZCBzZXJ2aWNlIGV4dGVuc2lvbnMg KGUuZy4gaW4gYSA8cXNtdHAtZ3JlZXQ+KSBpdA0KICAgcmVzcG9uZHMgd2l0 aCBhICI1MjAgUGxlYXNlIHVzZSB0aGUgY29ycmVjdCBRSExPIElEIiByZXNw b25zZTsNCiAgIG90aGVyd2lzZSAoZS5nLiBhZnRlciBTVEFSVFRMUyBvciBB VVRIKSBpdCByZXNwb25kcyB3aXRoIGEgPHFobG8tDQogICBsb25nLW5vPiwg d2hpY2ggaW5jbHVkZXMgdGhlIGxpc3Qgb2YgZXh0ZW5zaW9ucyBzdXBwb3J0 ZWQgYnkgdGhlDQogICBzZXJ2ZXIuDQoNCg0KDQoNCg0KDQoNCkZpbmNoICAg ICAgICAgICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyOCwgMjAwNyAgICAg ICAgICAgICAgIFtQYWdlIDEyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgVGhl IFFVSUNLU1RBUlQgU01UUCBzZXJ2aWNlIGV4dGVuc2lvbiAgICBGZWJydWFy eSAyMDA3DQoNCg0KICAgU3ludGF4Og0KDQogICAgICAgIHFobG8tbG9uZy1u byAgPSAgKCAgICAiNTIxLSIgICBkb21haW4gWyBTUCBlaGxvLWdyZWV0IF0g Q1JMRg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgKiggIjUyMS0iICAg ZWhsby1saW5lICAgICAgICAgICAgICAgIENSTEYgKQ0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIjUyMSIgU1AgZWhsby1saW5lICAgICAgICAg ICAgICAgIENSTEYgICApDQoNCiAgIElmIHRoZSBzZXJ2ZXIgcmVzcG9uZHMg dG8gUUhMTyB3aXRoIGEgNTIwIG9yIDUyMSBjb2RlLCBpdCBTSE9VTEQNCiAg IHJlamVjdCBzdWJzZXF1ZW50IGNvbW1hbmRzIG90aGVyIHRoYW4gTk9PUCwg UUhMTywgb3IgUVVJVCB3aXRoICI1MDMNCiAgIEJhZCBzZXF1ZW5jZSBvZiBj b21tYW5kcyIgcmVzcG9uc2VzLiAgSWYgdGhlIHNlcnZlciBzdXBwb3J0cw0K ICAgRU5IQU5DRURTVEFUVVNDT0RFUyBbUkZDMjAzNF0gW1JGQzM0NjNdLCB0 aGUgc3RhdHVzIGNvZGUgdG8gYmUNCiAgIHJldHVybmVkIFNIT1VMRCBiZSA1 LjUuMS4gIFRoZSBjbGllbnQgU0hPVUxEIHJlY292ZXIgZnJvbSB0aGlzIHN0 YXRlDQogICBieSBpc3N1aW5nIGEgUUhMTyBjb21tYW5kIGNvbnRhaW5pbmcg dGhlIGNvcnJlY3QgPHFobG8taWQ+Lg0KDQogICBUaGUgY2xpZW50IE1BWSBp c3N1ZSBjb21tYW5kcyBlYXJseSBhdCBhIFFVSUNLU1RBUlQgcG9pbnQgaWYg aXQgaGFzDQogICBwcmV2aW91c2x5IGNvbm5lY3RlZCB0byB0aGUgc2VydmVy IGFuZCB0aGUgc2VydmVyIGluY2x1ZGVkIFFVSUNLU1RBUlQNCiAgIFFITE89 PHFobG8taWQ+IGluIGl0cyBsaXN0IG9mIHN1cHBvcnRlZCBleHRlbnNpb25z IGF0IHRoYXQgcG9pbnQuDQogICBUaGUgY2xpZW50J3MgZmlyc3QgY29tbWFu ZCBhdCB0aGUgUVVJQ0tTVEFSVCBwb2ludCBNVVNUIGJlIHRoZSBmdWxsDQog ICBmb3JtIG9mIFFITE8uICBUaGUgY2xpZW50IE1VU1QgaGF2ZSByZW1lbWJl cmVkIHRoZSBkZXRhaWxzIG9mIHRoZQ0KICAgZXh0ZW5zaW9ucyB0aGF0IHRo ZSBjbGllbnQgaXMgaW50ZXJlc3RlZCBpbiBhbmQgd2hpY2ggYXJlIHN1cHBv cnRlZA0KICAgYnkgdGhlIHNlcnZlciBhdCB0aGF0IHBvaW50LCBpbmNsdWRp bmcgdGhlIDxxaGxvLWlkPi4gIFRoZSBjbGllbnQNCiAgIE1VU1QgTk9UIGNv bmZ1c2UgPHFobG8taWQ+cyBvYnRhaW5lZCBmcm9tIGRpZmZlcmVudCBRVUlD S1NUQVJUDQogICBwb2ludHMuICBUaGUgY2xpZW50IE1VU1QgTk9UIGFzc3Vt ZSB0aGF0IHRoZSBzZXJ2ZXIncyBjdXJyZW50DQogICA8cWhsby1pZD4gd2ls bCBiZSB0aGUgc2FtZSBhcyBvbiB0aGUgcHJldmlvdXMgY29ubmVjdGlvbiwg dGhlcmVmb3JlDQogICB0aGUgY2xpZW50IE1VU1QgYmUgcHJlcGFyZWQgZm9y IGl0cyBRSExPIGJlaW5nIHJlamVjdGVkLiAgTm90ZSB0aGF0DQogICB0aGlz IGltcGxpZXMgdGhhdCB0aGUgY2xpZW50IFNIT1VMRCBOT1QgcGlwZWxpbmUg YW4gZWFybHkgUUhMTw0KICAgY29tbWFuZCBhbmQgYSBRVExTIGNvbW1hbmQs IHNpbmNlIHRoZSBzZXJ2ZXIgY2Fubm90IHJlamVjdCB0aGUgUVRMUw0KICAg Y29tbWFuZCBleGNlcHQgYnkgY2xvc2luZyB0aGUgY29ubmVjdGlvbjsgaW5z dGVhZCBpdCBTSE9VTEQgdXNlDQogICBTVEFSVFRMUyBhcyBkZXNjcmliZWQg aW4gU2VjdGlvbiA5Lg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCkZpbmNoICAgICAgICAgICAgICAgICAgICBFeHBp cmVzIEF1Z3VzdCAyOCwgMjAwNyAgICAgICAgICAgICAgIFtQYWdlIDEzXQ0K DA0KSW50ZXJuZXQtRHJhZnQgICAgVGhlIFFVSUNLU1RBUlQgU01UUCBzZXJ2 aWNlIGV4dGVuc2lvbiAgICBGZWJydWFyeSAyMDA3DQoNCg0KOS4gIENoYW5n ZXMgdG8gdGhlIFNUQVJUVExTIGNvbW1hbmQNCg0KICAgVGhpcyBzZWN0aW9u IGRlc2NyaWJlcyBhbiBPUFRJT05BTCBjaGFuZ2UgdG8gdGhlIGJlaGF2aW91 ciBvZiB0aGUNCiAgIFNUQVJUVExTIGNvbW1hbmQgW1JGQzMyMDddIHdoaWNo IGlzIGluZGljYXRlZCBieSB0aGUgcHJlc2VuY2Ugb2YgdGhlDQogICBTVEFS VFRMUyBwYXJhbWV0ZXIgYWZ0ZXIgdGhlIFFVSUNLU1RBUlQga2V5d29yZCBp biB0aGUgbGlzdCBvZg0KICAgZXh0ZW5zaW9ucyBzdXBwb3J0ZWQgYnkgdGhl IHNlcnZlci4gIElmIHRoZSBzZXJ2ZXIgbGlzdHMgYm90aCB0aGUNCiAgIFFU TFMgYW5kIFFITE89PHFobG8taWQ+IHBhcmFtZXRlcnMsIHRoZW4gaXQgU0hP VUxEIGFsc28gbGlzdCB0aGUNCiAgIFNUQVJUVExTIHBhcmFtZXRlci4NCg0K ICAgVGhlIGFkdmFudGFnZXMgb2YgdGhlIFFUTFMgY29tbWFuZCBhcmUgdGhh dCBpdCBhbGxvd3MgdGhlIGNsaWVudCB0bw0KICAgaW5pdGlhdGUgYSBUTFMg aGFuZHNoYWtlIGZhc3RlciB3aXRob3V0IGdldHRpbmcgbXVkZGxlZCBieSBT TVRQDQogICByZXNwb25zZXMgZnJvbSB0aGUgc2VydmVyLCBhbmQgaXQgYWxs b3dzIHRoZSBjbGllbnQgdG8gcmVjZWl2ZSB0aGUNCiAgIGxpc3Qgb2YgZXh0 ZW5zaW9ucyBzdXBwb3J0ZWQgYnkgdGhlIHNlcnZlciBpbnNpZGUgVExTIHNv b25lci4gIFdoZW4NCiAgIHRoZSBjbGllbnQgdXNlcyB0aGUgUUhMTz08cWhs by1pZD4gZmVhdHVyZSB0byBpc3N1ZSBjb21tYW5kcyBlYXJseSwNCiAgIGl0 IGlzbid0IHBvc3NpYmxlIHRvIGF2b2lkIGludGVybGVhdmluZyBTTVRQIHJl c3BvbnNlcyB3aXRoIHRoZSBUTFMNCiAgIGhhbmRzaGFrZSwgYW5kIGl0IGlz IG5vIGxvbmdlciBuZWNlc3NhcnkgdG8gZ2V0IHRoZSBzZXJ2ZXIncyBsaXN0 IG9mDQogICBzdXBwb3J0ZWQgZXh0ZW5zaW9ucy4gIEZ1cnRoZXJtb3JlLCB0 aGUgUVRMUyBjb21tYW5kJ3MgbGFjayBvZiBlcnJvcg0KICAgcmVjb3Zlcnkg YmVjb21lcyBhIHByb2JsZW0uICBUaGVyZWZvcmUgZnVsbCBRVUlDS1NUQVJU IHVzZXMgYQ0KICAgcGlwZWxpbmVkIFNUQVJUVExTIGNvbW1hbmQuDQoNCiAg IElmIHRoZSBzZXJ2ZXIgc3VwcG9ydHMgUVVJQ0tTVEFSVCBTVEFSVFRMUywg dGhlbiB0aGUgY2xpZW50IE1BWSBzdGFydA0KICAgdGhlIFRMUyBoYW5kc2hh a2UgaW1tZWRpYXRlbHkgYWZ0ZXIgaXNzdWluZyB0aGUgU1RBUlRUTFMgY29t bWFuZCwNCiAgIHdpdGhvdXQgd2FpdGluZyBmb3IgdGhlIHNlcnZlcidzIHJl c3BvbnNlIHRvIFNUQVJUVExTLiAgSWYgdGhlIHNlcnZlcg0KICAgd2lzaGVz IHRvIHJlamVjdCB0aGUgU1RBUlRUTFMgY29tbWFuZCwgaXQgTVVTVCBkaXNj YXJkIGFueSBwaXBlbGluZWQNCiAgIFRMUyBjbGllbnQgaGVsbG8gYmVmb3Jl IGlzc3VpbmcgaXRzIHJlc3BvbnNlLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkZpbmNoICAgICAgICAg ICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyOCwgMjAwNyAgICAgICAgICAg ICAgIFtQYWdlIDE0XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgVGhlIFFVSUNL U1RBUlQgU01UUCBzZXJ2aWNlIGV4dGVuc2lvbiAgICBGZWJydWFyeSAyMDA3 DQoNCg0KMTAuICBCYWNrd2FyZHMgY29tcGF0aWJpbGl0eQ0KDQogICBJZiB0 aGUgZmlyc3QgY29tbWFuZCBpc3N1ZWQgYnkgdGhlIGNsaWVudCBpcyBFSExP LCB0aGVuIHRoZSBzZXJ2ZXINCiAgIE1VU1QgdHJlYXQgaXQgYXMgbm9ybWFs IGV4dGVuZGVkIFNNVFAgY29udmVyc2F0aW9uIGFzIHNwZWNpZmllZCBpbg0K ICAgW1JGQzI4MjFdLiAgSW4gdGhpcyBjYXNlIHRoZSBjbGllbnQgTVVTVCBk aXNyZWdhcmQgdGhlIGxpc3Qgb2YNCiAgIGV4dGVuc2lvbnMgcHJvdmlkZWQg aW4gdGhlIHNlcnZlcidzIGdyZWV0aW5nLiAgRm9yIGV4YW1wbGUsIGlmIHRo ZQ0KICAgc2VydmVyIGxpc3RzIFBJUEVMSU5JTkcgaW4gaXRzIGdyZWV0aW5n LCB0aGUgY2xpZW50IE1VU1QgTk9UIGFzc3VtZQ0KICAgdGhhdCBQSVBFTElO SU5HIHdpbGwgYmUgbGlzdGVkIGluIHRoZSBzZXJ2ZXIncyByZXNwb25zZSB0 byBFSExPLg0KDQogICBJZiB0aGUgZmlyc3QgY29tbWFuZCBpc3N1ZWQgYnkg dGhlIGNsaWVudCBpcyBub3QgUVRMUyBub3IgUUhMTyBub3INCiAgIEVITE8s IHRoZW4gdGhlIHNlcnZlciBNVVNUIHRyZWF0IGl0IGFzIGFuIHVuLWV4dGVu ZGVkIFNNVFANCiAgIGNvbnZlcnNhdGlvbiBhcyBzcGVjaWZpZWQgaW4gW1JG QzA4MjFdLg0KDQogICBJbiB0aGUgYWJvdmUgc2l0dWF0aW9ucywgdGhlIHNl cnZlciBNQVkgcmVxdWlyZSB0aGF0IHRoZSBjbGllbnQncw0KICAgZmlyc3Qg Y29tbWFuZCBpcyBpc3N1ZWQgYWZ0ZXIgdGhlIGNsaWVudCBoYXMgcmVjZWl2 ZWQgdGhlIGdyZWV0aW5nLg0KDQogICBBIGNsaWVudCB0aGF0IGlzc3VlcyBj b21tYW5kcyBlYXJseSAoYXMgZGVzY3JpYmVkIGluIHRoZSB0d28gcHJldmlv dXMNCiAgIHNlY3Rpb25zKSBNVVNUIGJlIHByZXBhcmVkIHRvIGRlYWwgd2l0 aCBlcnJvcnMgdGhhdCBpbmRpY2F0ZSB0aGUNCiAgIHNlcnZlciBubyBsb25n ZXIgc3VwcG9ydHMgUVVJQ0tTVEFSVCwgc3VjaCBhcyA1MFggb3IgNTVYIFNN VFANCiAgIHJlc3BvbnNlcyBbUkZDMjgyMV0sIG9yIDUuNS5YLCA1LjMuWCwg b3IgNS43LlggZW5oYW5jZWQgc3RhdHVzIGNvZGVzDQogICBbUkZDMzQ2M10u ICBJZiB0aGUgY2xpZW50IGlzc3VlZCBhIFFUTFMgb3IgcGlwZWxpbmVkIFNU QVJUVExTDQogICBjb21tYW5kLCBpdCBTSE9VTEQgZGlzY29ubmVjdCBhbmQg cmUtdHJ5IHVzaW5nIEVTTVRQIHdpdGhvdXQNCiAgIFFVSUNLU1RBUlQ7IG90 aGVyd2lzZSBpdCBNQVkgcmVjb3ZlciBieSBpc3N1aW5nIGFuIEVITE8gY29t bWFuZCBhbmQNCiAgIHJlLXRyeWluZy4NCg0KICAgU2ltaWxhcmx5LCBhIGNs aWVudCB0aGF0IGlzc3VlcyBjb21tYW5kcyBlYXJseSBNVVNUIGJlIHByZXBh cmVkIHRvDQogICBkZWFsIHdpdGggYSA0MjEgb3IgNC4zLjIgIlNlcnZpY2Ug bm90IGF2YWlsYWJsZSIgZXJyb3IuICBJbiB0aGlzDQogICBzaXR1YXRpb24g dGhlIGNsaWVudCBTSE9VTEQgZGlzY29ubmVjdCBhbmQgcmUtdHJ5IHNvbWUg dGltZSBsYXRlci4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQpGaW5jaCAgICAgICAgICAgICAgICAgICAgRXhwaXJl cyBBdWd1c3QgMjgsIDIwMDcgICAgICAgICAgICAgICBbUGFnZSAxNV0NCgwN CkludGVybmV0LURyYWZ0ICAgIFRoZSBRVUlDS1NUQVJUIFNNVFAgc2Vydmlj ZSBleHRlbnNpb24gICAgRmVicnVhcnkgMjAwNw0KDQoNCjExLiAgSUFOQSBD b25zaWRlcmF0aW9ucw0KDQogICBUaGlzIG1lbW8gZGVmaW5lcyBhIG5ldyBT TVRQIHNlcnZpY2UgZXh0ZW5zaW9uIGtleXdvcmQsICJRVUlDS1NUQVJUIg0K ICAgaW4gU2VjdGlvbiAzLiAgRm91ciBwYXJhbWV0ZXJzIGFyZSBpbml0aWFs bHkgZGVmaW5lZCBmb3IgdGhlIGtleXdvcmQuDQogICBGdXJ0aGVyIHBhcmFt ZXRlcnMgTUFZIGJlIGRlZmluZWQgYnkgZnV0dXJlIHNwZWNpZmljYXRpb25z IGFuZCBNVVNUDQogICBjb25mb3JtIHRvIHRoZSA8ZXNtdHAtcGFyYW0+IHN5 bnRheDsgcGFyYW1ldGVyIGtleXdvcmRzIHN0YXJ0aW5nIHdpdGgNCiAgIFgg YXJlIGZvciBQcml2YXRlIFVzZSwgYW5kIG90aGVyIHBhcmFtZXRlciBrZXl3 b3JkcyBTSE9VTEQgYmUNCiAgIGFsbG9jYXRlZCBhY2NvcmRpbmcgdG8gdGhl IFNwZWNpZmljYXRpb24gUmVxdWlyZWQgcG9saWN5IFtSRkMyNDM0XS4NCg0K ICAgSUFOQSBtYWludGFpbnMgYSByZWdpc3RyeSBvZiAiV0lUSCBwcm90b2Nv bCB0eXBlcyIgZm9yIHVzZSBpbiB0aGUNCiAgICJ3aXRoIiBjbGF1c2Ugb2Yg dGhlIFJlY2VpdmVkIGhlYWRlciB0cmFjZSBmaWVsZHMgaW4gYW4gSW50ZXJu ZXQNCiAgIG1lc3NhZ2UuICBNb3N0IG9mIHRoZSBjb250ZW50cyBvZiB0aGlz IHJlZ2lzdHJ5IGFyZSBzZXQgb3V0IGluDQogICBbUkZDMzg0OF0uICBUaGlz IHNwZWNpZmljYXRpb24gdXBkYXRlcyB0aGUgcmVnaXN0cnkgYXMgZm9sbG93 czoNCg0KICAgbyAgVGhlIG5ldyBrZXl3b3JkICJRU01UUCIgaW5kaWNhdGVz IHRoYXQgdGhlIGNsaWVudCB1c2VkIHRoZQ0KICAgICAgUVVJQ0tTVEFSVCBl eHRlbnNpb24sIHRoYXQgaXMsIGl0IHVzZWQgdGhlIFFITE8gY29tbWFuZCB0 byBzdGFydA0KICAgICAgdGhlIFNNVFAgc2Vzc2lvbiBpbnN0ZWFkIG9mIEVI TE8uDQoNCiAgIG8gIFRoZSBuZXcga2V5d29yZCAiUVNNVFBBIiBpbmRpY2F0 ZXMgdGhhdCB0aGUgY2xpZW50IHVzZWQgUVVJQ0tTVEFSVA0KICAgICAgd2l0 aCB0aGUgU01UUCBBVVRIIFtSRkMyNTU0XSBleHRlbnNpb24sIGFuZCB0aGF0 IGl0IGF1dGhlbnRpY2F0ZWQNCiAgICAgIHN1Y2Nlc3NmdWxseS4NCg0KICAg byAgVGhlIG5ldyBrZXl3b3JkICJRU01UUFMiIGluZGljYXRlcyB0aGF0IHRo ZSBjbGllbnQgdXNlZA0KICAgICAgUVVJQ0tTVEFSVCwgYW5kIHRoYXQgaXQg c3VjY2Vzc2Z1bGx5IGNvbXBsZXRlZCBUTFMgbmVnb3RpYXRpb24gdG8NCiAg ICAgIHByb3ZpZGUgYSBzdHJvbmcgdHJhbnNwb3J0IGVuY3J5cHRpb24gbGF5 ZXIgYnkgdXNpbmcgdGhlIFFUTFMgb3INCiAgICAgIFNUQVJUVExTIGNvbW1h bmRzLg0KDQogICBvICBUaGUgbmV3IGtleXdvcmQgIlFTTVRQU0EiIGluZGlj YXRlcyB0aGF0IHRoZSBjbGllbnQgdXNlZA0KICAgICAgUVVJQ0tTVEFSVCBh bmQgYm90aCBUTFMgYW5kIEFVVEggd2VyZSBzdWNjZXNzZnVsbHkgbmVnb3Rp YXRlZCAodGhlDQogICAgICBjb21iaW5hdGlvbiBvZiBRU01UUFMgYW5kIFFT TVRQQSkuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQpGaW5jaCAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3Qg MjgsIDIwMDcgICAgICAgICAgICAgICBbUGFnZSAxNl0NCgwNCkludGVybmV0 LURyYWZ0ICAgIFRoZSBRVUlDS1NUQVJUIFNNVFAgc2VydmljZSBleHRlbnNp b24gICAgRmVicnVhcnkgMjAwNw0KDQoNCjEyLiAgU2VjdXJpdHkgY29uc2lk ZXJhdGlvbnMNCg0KICAgTGlrZSB0aGUgRUhMTyBjb21tYW5kLCB0aGUgUUhM TyBjb21tYW5kIGluY2x1ZGVzIGEgY2xpZW50IGhvc3QgbmFtZQ0KICAgcGFy YW1ldGVyIGZvciBsb2dnaW5nIGFuZCB0cmFjaW5nIHB1cnBvc2VzLiAgVGhp cyBjYW4gdXNlZnVsIHRvDQogICBkaXN0aW5ndWlzaCBkaWZmZXJlbnQgY2xp ZW50cyBiZWhpbmQgYSBOQVQsIGZvciBleGFtcGxlLiAgSG93ZXZlcg0KICAg Y2xpZW50cyBjb21tb25seSBzdGF0ZSBhbiBpbmNvcnJlY3QgaG9zdCBuYW1l LCBzbyBpdCBTSE9VTEQgTk9UIGJlDQogICByZWxpZWQgb24uICBTTVRQIHNl cnZlcnMgU0hPVUxEIHVzZSBhbGwgYXZhaWxhYmxlIGNsaWVudCBpZGVudGlm aWVycw0KICAgZm9yIGxvZ2dpbmcgYW5kIHRyYWNpbmcsIHN1Y2ggYXMgaXRz IElQIGFkZHJlc3MsIHJldmVyc2UgRE5TLCBUTFMNCiAgIGNlcnRpZmljYXRl LCBhbmQgU01UUCBBVVRIIGNyZWRlbnRpYWxzLg0KDQogICBJdCBpcyBpbmNy ZWFzaW5nbHkgcG9wdWxhciBmb3IgU01UUCBzZXJ2ZXJzIChlc3BlY2lhbGx5 IE1YIGhvc3RzKSB0bw0KICAgdXNlIGhldXJpc3RpY3MgYmFzZWQgb24gcHJv dG9jb2wgY29uZm9ybWFuY2UgdG8gaWRlbnRpZnkgYWJ1c2l2ZQ0KICAgY2xp ZW50cyBhbmQgcmVqZWN0IGVtYWlsIGZyb20gdGhlbS4gIEZvciBleGFtcGxl LCB0aGUgc2VydmVyIGNhbg0KICAgZGVsYXkgaXRzIGdyZWV0aW5nIGFuZCBz ZWUgaWYgdGhlIGNsaWVudCB3YWl0cyB0byByZWNlaXZlIGl0IGJlZm9yZQ0K ICAgaXNzdWluZyBjb21tYW5kcy4gIFRoaXMgaGV1cmlzdGljIGNhbiBzdGls bCBiZSBhcHBsaWVkIGluIHRoZQ0KICAgcHJlc2VuY2Ugb2YgZnVsbCBzdXBw b3J0IGZvciBRVUlDS1NUQVJULCBieSBjaGVja2luZyB0aGF0IHRoZQ0KICAg Y2xpZW50J3MgZWFybHkgZmlyc3QgY29tbWFuZCBpcyBub3QgUUhMTyBiZWZv cmUgZGVjaWRpbmcgdGhhdCBpdCBpcw0KICAgYWJ1c2l2ZS4NCg0KICAgVGhl IGZ1bGwgUVVJQ0tTVEFSVCBwcm90b2NvbCByZXF1aXJlcyB0aGUgY2xpZW50 IHRvIGRlbW9uc3RyYXRlIHRoYXQNCiAgIGl0IGhhcyBwcmV2aW91c2x5IGNv bW11bmljYXRlZCB3aXRoIHRoZSBzZXJ2ZXIsIGJ5IGVjaG9pbmcgdGhlDQog ICA8cWhsby1pZD4uICBUaGlzIGNhbiBiZSBmYWtlZCBieSBhYnVzaXZlIGNs aWVudHMgaWYgdGhlIDxxaGxvLWlkPiBpcw0KICAgdG9vIGVhc3kgdG8gZ3Vl c3MuICBUaGUgc2VydmVyIGNhbiBkZWZlbmQgaXRzZWxmIGFnYWluc3QgcHVt cC1hbmQtDQogICBkdW1wIGFidXNlIGJ5IG1ha2luZyB0aGUgPHFobG8taWQ+ IGRlcGVuZCBvbiBtb3JlIHRoYW4ganVzdCB0aGUgbGlzdA0KICAgb2Ygc3Vw cG9ydGVkIGV4dGVuc2lvbnMgYW5kIHRoZWlyIHBhcmFtZXRlcnM6IGZvciBl eGFtcGxlIGl0IG1pZ2h0DQogICB1c2UgYSBkaWdlc3Qgb2YgdGhlIGxpc3Qs IHRoZSBzZXJ2ZXIgYW5kIGNsaWVudCBJUCBhZGRyZXNzZXMsIGFuZCBhDQog ICBzZWNyZXQuDQoNCiAgIE9mIGNvdXJzZSwgc2luY2UgUVVJQ0tTVEFSVCBp cyBtb3N0IHVzZWZ1bCBmb3IgaW50ZXJhY3RpdmUgbWVzc2FnZQ0KICAgc3Vi bWlzc2lvbiwgYW5kIGhpZ2ggbGF0ZW5jeSBpcyBub3Qgc3VjaCBhIHByb2Js ZW0gZm9yIGF1dG9tYXRlZA0KICAgbWVzc2FnZSByZWxheSwgTVggaG9zdHMg Y2FuIHNpbXBseSBlbGVjdCBub3QgdG8gc3VwcG9ydCBRVUlDS1NUQVJULg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkZpbmNo ICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyOCwgMjAwNyAg ICAgICAgICAgICAgIFtQYWdlIDE3XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAg VGhlIFFVSUNLU1RBUlQgU01UUCBzZXJ2aWNlIGV4dGVuc2lvbiAgICBGZWJy dWFyeSAyMDA3DQoNCg0KMTMuICBSZWZlcmVuY2VzDQoNCjEzLjEuICBOb3Jt YXRpdmUgcmVmZXJlbmNlcw0KDQogICBbUkZDMDgyMV0gIFBvc3RlbCwgSi4s ICJTaW1wbGUgTWFpbCBUcmFuc2ZlciBQcm90b2NvbCIsIFNURCAxMCwNCiAg ICAgICAgICAgICAgUkZDIDgyMSwgQXVndXN0IDE5ODIuDQoNCiAgIFtSRkMy MDM0XSAgRnJlZWQsIE4uLCAiU01UUCBTZXJ2aWNlIEV4dGVuc2lvbiBmb3Ig UmV0dXJuaW5nIEVuaGFuY2VkDQogICAgICAgICAgICAgIEVycm9yIENvZGVz IiwgUkZDIDIwMzQsIE9jdG9iZXIgMTk5Ni4NCg0KICAgW1JGQzIxMTldICBC cmFkbmVyLCBTLiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5k aWNhdGUNCiAgICAgICAgICAgICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwgQkNQ IDE0LCBSRkMgMjExOSwgTWFyY2ggMTk5Ny4NCg0KICAgW1JGQzI0MzRdICBO YXJ0ZW4sIFQuIGFuZCBILiBBbHZlc3RyYW5kLCAiR3VpZGVsaW5lcyBmb3Ig V3JpdGluZyBhbg0KICAgICAgICAgICAgICBJQU5BIENvbnNpZGVyYXRpb25z IFNlY3Rpb24gaW4gUkZDcyIsIEJDUCAyNiwgUkZDIDI0MzQsDQogICAgICAg ICAgICAgIE9jdG9iZXIgMTk5OC4NCg0KICAgW1JGQzI1NTRdICBNeWVycywg Si4sICJTTVRQIFNlcnZpY2UgRXh0ZW5zaW9uIGZvciBBdXRoZW50aWNhdGlv biIsDQogICAgICAgICAgICAgIFJGQyAyNTU0LCBNYXJjaCAxOTk5Lg0KDQog ICBbUkZDMjgyMV0gIEtsZW5zaW4sIEouLCAiU2ltcGxlIE1haWwgVHJhbnNm ZXIgUHJvdG9jb2wiLCBSRkMgMjgyMSwNCiAgICAgICAgICAgICAgQXByaWwg MjAwMS4NCg0KICAgW1JGQzI5MjBdICBGcmVlZCwgTi4sICJTTVRQIFNlcnZp Y2UgRXh0ZW5zaW9uIGZvciBDb21tYW5kDQogICAgICAgICAgICAgIFBpcGVs aW5pbmciLCBTVEQgNjAsIFJGQyAyOTIwLCBTZXB0ZW1iZXIgMjAwMC4NCg0K ICAgW1JGQzMyMDddICBIb2ZmbWFuLCBQLiwgIlNNVFAgU2VydmljZSBFeHRl bnNpb24gZm9yIFNlY3VyZSBTTVRQIG92ZXINCiAgICAgICAgICAgICAgVHJh bnNwb3J0IExheWVyIFNlY3VyaXR5IiwgUkZDIDMyMDcsIEZlYnJ1YXJ5IDIw MDIuDQoNCiAgIFtSRkMzNDYzXSAgVmF1ZHJldWlsLCBHLiwgIkVuaGFuY2Vk IE1haWwgU3lzdGVtIFN0YXR1cyBDb2RlcyIsDQogICAgICAgICAgICAgIFJG QyAzNDYzLCBKYW51YXJ5IDIwMDMuDQoNCiAgIFtSRkMzODQ4XSAgTmV3bWFu LCBDLiwgIkVTTVRQIGFuZCBMTVRQIFRyYW5zbWlzc2lvbiBUeXBlcw0KICAg ICAgICAgICAgICBSZWdpc3RyYXRpb24iLCBSRkMgMzg0OCwgSnVseSAyMDA0 Lg0KDQogICBbUkZDNDIzNF0gIENyb2NrZXIsIEQuLCBFZC4gYW5kIFAuIE92 ZXJlbGwsICJBdWdtZW50ZWQgQk5GIGZvciBTeW50YXgNCiAgICAgICAgICAg ICAgU3BlY2lmaWNhdGlvbnM6IEFCTkYiLCBSRkMgNDIzNCwgT2N0b2JlciAy MDA1Lg0KDQoxMy4yLiAgSW5mb3JtYXRpdmUgcmVmZXJlbmNlcw0KDQogICBb UkZDMDc5M10gIFBvc3RlbCwgSi4sICJUcmFuc21pc3Npb24gQ29udHJvbCBQ cm90b2NvbCIsIFNURCA3LA0KICAgICAgICAgICAgICBSRkMgNzkzLCBTZXB0 ZW1iZXIgMTk4MS4NCg0KICAgW1JGQzE4NzBdICBLbGVuc2luLCBKLiwgRnJl ZWQsIE4uLCBhbmQgSy4gTW9vcmUsICJTTVRQIFNlcnZpY2UNCiAgICAgICAg ICAgICAgRXh0ZW5zaW9uIGZvciBNZXNzYWdlIFNpemUgRGVjbGFyYXRpb24i LCBTVEQgMTAsIFJGQyAxODcwLA0KICAgICAgICAgICAgICBOb3ZlbWJlciAx OTk1Lg0KDQogICBbUkZDNDM0Nl0gIERpZXJrcywgVC4gYW5kIEUuIFJlc2Nv cmxhLCAiVGhlIFRyYW5zcG9ydCBMYXllciBTZWN1cml0eQ0KDQoNCg0KRmlu Y2ggICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDI4LCAyMDA3 ICAgICAgICAgICAgICAgW1BhZ2UgMThdDQoMDQpJbnRlcm5ldC1EcmFmdCAg ICBUaGUgUVVJQ0tTVEFSVCBTTVRQIHNlcnZpY2UgZXh0ZW5zaW9uICAgIEZl YnJ1YXJ5IDIwMDcNCg0KDQogICAgICAgICAgICAgIChUTFMpIFByb3RvY29s IFZlcnNpb24gMS4xIiwgUkZDIDQzNDYsIEFwcmlsIDIwMDYuDQoNCiAgIFtS RkM0NDA5XSAgR2VsbGVucywgUi4gYW5kIEouIEtsZW5zaW4sICJNZXNzYWdl IFN1Ym1pc3Npb24gZm9yIE1haWwiLA0KICAgICAgICAgICAgICBSRkMgNDQw OSwgQXByaWwgMjAwNi4NCg0KICAgW1JGQzQ0MjJdICBNZWxuaWtvdiwgQS4g YW5kIEsuIFplaWxlbmdhLCAiU2ltcGxlIEF1dGhlbnRpY2F0aW9uIGFuZA0K ICAgICAgICAgICAgICBTZWN1cml0eSBMYXllciAoU0FTTCkiLCBSRkMgNDQy MiwgSnVuZSAyMDA2Lg0KDQogICBbUkZDNDQ2OF0gIE5ld21hbiwgQy4sICJN ZXNzYWdlIFN1Ym1pc3Npb24gQlVSTCBFeHRlbnNpb24iLCBSRkMgNDQ2OCwN CiAgICAgICAgICAgICAgTWF5IDIwMDYuDQoNCiAgIFtSRkM0NjE2XSAgWmVp bGVuZ2EsIEsuLCAiVGhlIFBMQUlOIFNpbXBsZSBBdXRoZW50aWNhdGlvbiBh bmQNCiAgICAgICAgICAgICAgU2VjdXJpdHkgTGF5ZXIgKFNBU0wpIE1lY2hh bmlzbSIsIFJGQyA0NjE2LCBBdWd1c3QgMjAwNi4NCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQpGaW5jaCAgICAgICAgICAgICAgICAgICAgRXhw aXJlcyBBdWd1c3QgMjgsIDIwMDcgICAgICAgICAgICAgICBbUGFnZSAxOV0N CgwNCkludGVybmV0LURyYWZ0ICAgIFRoZSBRVUlDS1NUQVJUIFNNVFAgc2Vy dmljZSBleHRlbnNpb24gICAgRmVicnVhcnkgMjAwNw0KDQoNCkFwcGVuZGl4 IEEuICBFeGFtcGxlIHJvdW5kIHRyaXAgc3VtbWFyaWVzDQoNCiAgIEluIHRo ZSBmb2xsb3dpbmcgZXhhbXBsZXMsIGEgbGluZSBwcmVmaXhlZCB3aXRoIEM6 IGluZGljYXRlcyB0aGUNCiAgIHN0YXJ0IG9mIGEgcGFja2V0IGZyb20gdGhl IGNsaWVudCB0byB0aGUgc2VydmVyLCBhbmQgUzogaW5kaWNhdGVzIG9uZQ0K ICAgZnJvbSB0aGUgc2VydmVyIHRvIHRoZSBjbGllbnQuICBTdWJzZXF1ZW50 IGxpbmVzIHdpdGhvdXQgYSBwcmVmaXggYXJlDQogICBwaXBlbGluZWQgaW50 byB0aGUgc2FtZSBwYWNrZXQuICBUaGUgQzogb3IgUzogbWF5IGJlIGZvbGxv d2VkIGJ5IGENCiAgIHByb3RvY29sIG5hbWUgLSBUQ1AsIFNNVFAgb3IgVExT IC0gd2hpY2ggaW5kaWNhdGVzIGEgY2hhbmdlIGluIHRoZQ0KICAgdG9wLW1v c3QgcHJvdG9jb2wgYWN0aXZlIGluIHRoZSBjb25uZWN0aW9uLiAgVGhlIHJl c3Qgb2YgdGhlIGxpbmUNCiAgIGRlc2NyaWJlcyBhIHByb3RvY29sIGVsZW1l bnQuDQoNCiAgIFRoZSBmb2xsb3dpbmcgZmlndXJlIG91dGxpbmVzIHRoZSBz ZXF1ZW5jZSBvZiBwYWNrZXRzIGF0IHRoZSBzdGFydCBvZg0KICAgYSBub24t UVVJQ0tTVEFSVCBtZXNzYWdlIHN1Ym1pc3Npb24gW1JGQzQ0MDldLCBpbmNs dWRpbmcgdGhlIFRDUA0KICAgaGFuZHNoYWtlIFtSRkMwNzkzXSwgc3RhcnRp bmcgRVNNVFAgW1JGQzI4MjFdLCBzZWN1cmluZyBpdCB1c2luZw0KICAgU1RB UlRUTFMgW1JGQzMyMDddIFtSRkM0MzQ2XSwgYXV0aGVudGljYXRpbmcgW1JG QzI1NTRdIFtSRkM0NDIyXQ0KICAgW1JGQzQ2MTZdLCBhbmQgc3RhcnRpbmcg dG8gc2VuZCB0aGUgbWVzc2FnZSB1c2luZyBwaXBlbGluaW5nDQogICBbUkZD MjkyMF0uICBUaGUgTUFJTCBjb21tYW5kIGFwcGVhcnMgaW4gdGhlIDl0aCBw YWNrZXQgZnJvbSB0aGUNCiAgIGNsaWVudCwgYW5kIHBpcGVsaW5pbmcgaXMg bm90IHBvc3NpYmxlIGJlZm9yZSB0aGlzIHBvaW50Lg0KDQogICAgICAgIEM6 IFRDUCAgU1lODQogICAgICAgIFM6ICAgICAgU1lOL0FDSw0KICAgICAgICBD OiAgICAgIEFDSw0KICAgICAgICBTOiBTTVRQIDxncmVldGluZz4NCiAgICAg ICAgQzogICAgICBFSExPIDxkb21haW4+DQogICAgICAgIFM6ICAgICAgPGVo bG8tb2stcnNwPg0KICAgICAgICBDOiAgICAgIFNUQVJUVExTDQogICAgICAg IFM6ICAgICAgMjIwIE9LDQogICAgICAgIEM6IFRMUyAgY2xpZW50IGhlbGxv DQogICAgICAgIFM6ICAgICAgc2VydmVyIGhlbGxvLCBjZXJ0aWZpY2F0ZSwg ZXRjLg0KICAgICAgICBDOiAgICAgIGtleSBleGNoYW5nZSwgY2hhbmdlIGNp cGhlciwgZmluaXNoIGhhbmRzaGFrZQ0KICAgICAgICBTOiAgICAgIGNoYW5n ZSBjaXBoZXIsIGZpbmlzaCBoYW5kc2hha2UNCiAgICAgICAgQzogU01UUCBF SExPIDxkb21haW4+DQogICAgICAgIFM6ICAgICAgPGVobG8tb2stcnNwPg0K ICAgICAgICBDOiAgICAgIEFVVEggUExBSU4gPGNyZWRzPg0KICAgICAgICBT OiAgICAgIDIzNSBPSw0KICAgICAgICBDOiAgICAgIE1BSUwgRlJPTTo8Li4u Pg0KICAgICAgICAgICAgICAgIFJDUFQgVE86PC4uLj4NCiAgICAgICAgICAg ICAgICAuLi4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpGaW5jaCAg ICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjgsIDIwMDcgICAg ICAgICAgICAgICBbUGFnZSAyMF0NCgwNCkludGVybmV0LURyYWZ0ICAgIFRo ZSBRVUlDS1NUQVJUIFNNVFAgc2VydmljZSBleHRlbnNpb24gICAgRmVicnVh cnkgMjAwNw0KDQoNCiAgIFRoZSBmb2xsb3dpbmcgc2hvd3MgdGhlIHVzZSBv ZiBhIHBpcGVsaW5lZCBRSExPIGNvbW1hbmQsIGJ1dCBubyBvdGhlcg0KICAg UVVJQ0tTVEFSVCBmZWF0dXJlcy4gIChJdCBpcyBub3QgdmVyeSByZWFsaXN0 aWMuKSAgVGhlIE1BSUwgY29tbWFuZA0KICAgaXMgaW4gdGhlIGNsaWVudCdz IDh0aCBwYWNrZXQuDQoNCiAgICAgICAgQzogVENQICBTWU4NCiAgICAgICAg UzogICAgICBTWU4vQUNLDQogICAgICAgIEM6ICAgICAgQUNLDQogICAgICAg IFM6IFNNVFAgPHFzbXRwLWdyZWV0Pg0KICAgICAgICBDOiAgICAgIFFITE8g PGRvbWFpbj4NCiAgICAgICAgICAgICAgICBTVEFSVFRMUw0KICAgICAgICBT OiAgICAgIDIyMCBPSw0KICAgICAgICAgICAgICAgIDIyMCBPSw0KICAgICAg ICBDOiBUTFMgIGNsaWVudCBoZWxsbw0KICAgICAgICBTOiAgICAgIHNlcnZl ciBoZWxsbywgY2VydGlmaWNhdGUsIGV0Yy4NCiAgICAgICAgQzogICAgICBr ZXkgZXhjaGFuZ2UsIGNoYW5nZSBjaXBoZXIsIGZpbmlzaCBoYW5kc2hha2UN CiAgICAgICAgUzogICAgICBjaGFuZ2UgY2lwaGVyLCBmaW5pc2ggaGFuZHNo YWtlDQogICAgICAgIEM6IFNNVFAgRUhMTyA8ZG9tYWluPg0KICAgICAgICBT OiAgICAgIDxlaGxvLW9rLXJzcD4NCiAgICAgICAgQzogICAgICBBVVRIIFBM QUlOIDxjcmVkcz4NCiAgICAgICAgUzogICAgICAyMzUgT0sNCiAgICAgICAg QzogICAgICBNQUlMIEZST006PC4uLj4NCiAgICAgICAgICAgICAgICBSQ1BU IFRPOjwuLi4+DQogICAgICAgICAgICAgICAgLi4uDQoNCiAgIFRoZSBmb2xs b3dpbmcgc2hvd3MgdGhlIHVzZSBvZiB0aGUgUVRMUyBhbmQgUUhMTyBjb21t YW5kcywgdG8NCiAgIGlsbHVzdHJhdGUgYSBiYXNpYyBRVUlDS1NUQVJUIGNv bm5lY3Rpb24uICBUaGUgTUFJTCBjb21tYW5kIGlzIGluIHRoZQ0KICAgY2xp ZW50J3MgNnRoIHBhY2tldC4NCg0KICAgICAgICBDOiBUQ1AgIFNZTg0KICAg ICAgICBTOiAgICAgIFNZTi9BQ0sNCiAgICAgICAgQzogICAgICBBQ0sNCiAg ICAgICAgUzogU01UUCA8cXNtdHAtZ3JlZXQ+DQogICAgICAgIEM6ICAgICAg UVRMUw0KICAgICAgICAgICBUTFMgIGNsaWVudCBoZWxsbw0KICAgICAgICBT OiAgICAgIHNlcnZlciBoZWxsbywgY2VydGlmaWNhdGUsIGV0Yy4NCiAgICAg ICAgQzogICAgICBrZXkgZXhjaGFuZ2UsIGNoYW5nZSBjaXBoZXIsIGZpbmlz aCBoYW5kc2hha2UNCiAgICAgICAgUzogICAgICBjaGFuZ2UgY2lwaGVyLCBm aW5pc2ggaGFuZHNoYWtlDQogICAgICAgICAgIFNNVFAgPHFzbXRwLWdyZWV0 Pg0KICAgICAgICBDOiAgICAgIFFITE8gPGRvbWFpbj4NCiAgICAgICAgICAg ICAgICBBVVRIIFBMQUlOIDxjcmVkcz4NCiAgICAgICAgUzogICAgICAyMjAg T0sNCiAgICAgICAgICAgICAgICAyMzUgT0sNCiAgICAgICAgQzogICAgICBN QUlMIEZST006PC4uLj4NCiAgICAgICAgICAgICAgICBSQ1BUIFRPOjwuLi4+ DQogICAgICAgICAgICAgICAgLi4uDQoNCg0KDQoNCg0KDQpGaW5jaCAgICAg ICAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjgsIDIwMDcgICAgICAg ICAgICAgICBbUGFnZSAyMV0NCgwNCkludGVybmV0LURyYWZ0ICAgIFRoZSBR VUlDS1NUQVJUIFNNVFAgc2VydmljZSBleHRlbnNpb24gICAgRmVicnVhcnkg MjAwNw0KDQoNCiAgIE5vdGUgdGhhdCB0aGUgY2xpZW50IG9taXR0ZWQgdGhl IFFITE8gYXQgdGhlIHN0YXJ0IG9mIHRoZSBwcmV2aW91cw0KICAgY29ubmVj dGlvbi4gIFRoaXMgc2ltcGxpZmljYXRpb24gYXZvaWRzIHRoZSBmb2xsb3dp bmcgc2l0dWF0aW9uIHdoZXJlDQogICBpdCBoYXMgdG8gc3dpdGNoIGJhY2sg YW5kIGZvcnRoIGJldHdlZW4gU01UUCBhbmQgVExTIGF0IHRoZSBzdGFydCBv Zg0KICAgdGhlIFRMUyBoYW5kc2hha2UuDQoNCiAgICAgICAgICAgICAgICAu Li4NCiAgICAgICAgUzogU01UUCA8cXNtdHAtZ3JlZXQ+DQogICAgICAgIEM6 ICAgICAgUUhMTyA8ZG9tYWluPg0KICAgICAgICAgICAgICAgIFFUTFMNCiAg ICAgICAgICAgVExTICBjbGllbnQgaGVsbG8NCiAgICAgICAgUzogU01UUCAy MjAgT0sNCiAgICAgICAgICAgVExTICBzZXJ2ZXIgaGVsbG8sIGNlcnRpZmlj YXRlLCBldGMuDQogICAgICAgICAgICAgICAgLi4uDQoNCiAgIFdpdGggcGlw ZWxpbmVkIEFVVEgsIHRoZSBNQUlMIGNvbW1hbmQgaXMgaW4gdGhlIGNsaWVu dCdzIDV0aCBwYWNrZXQuDQoNCiAgICAgICAgQzogVENQICBTWU4NCiAgICAg ICAgUzogICAgICBTWU4vQUNLDQogICAgICAgIEM6ICAgICAgQUNLDQogICAg ICAgIFM6IFNNVFAgPHFzbXRwLWdyZWV0Pg0KICAgICAgICBDOiAgICAgIFFU TFMNCiAgICAgICAgICAgVExTICBjbGllbnQgaGVsbG8NCiAgICAgICAgUzog ICAgICBzZXJ2ZXIgaGVsbG8sIGNlcnRpZmljYXRlLCBldGMuDQogICAgICAg IEM6ICAgICAga2V5IGV4Y2hhbmdlLCBjaGFuZ2UgY2lwaGVyLCBmaW5pc2gg aGFuZHNoYWtlDQogICAgICAgIFM6ICAgICAgY2hhbmdlIGNpcGhlciwgZmlu aXNoIGhhbmRzaGFrZQ0KICAgICAgICAgICBTTVRQIDxxc210cC1ncmVldD4N CiAgICAgICAgQzogICAgICBRSExPIDxkb21haW4+DQogICAgICAgICAgICAg ICAgQVVUSCBQTEFJTiA8Y3JlZHM+DQogICAgICAgICAgICAgICAgTUFJTCBG Uk9NOjwuLi4+DQogICAgICAgICAgICAgICAgUkNQVCBUTzo8Li4uPg0KICAg ICAgICAgICAgICAgIC4uLg0KICAgICAgICBTOiAgICAgIDIyMCBPSw0KICAg ICAgICAgICAgICAgIDIzNSBPSw0KICAgICAgICAgICAgICAgIDI1MCBPSw0K ICAgICAgICAgICAgICAgIDI1MCBPSw0KICAgICAgICAgICAgICAgIC4uLg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KRmluY2ggICAgICAgICAg ICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDI4LCAyMDA3ICAgICAgICAgICAg ICAgW1BhZ2UgMjJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICBUaGUgUVVJQ0tT VEFSVCBTTVRQIHNlcnZpY2UgZXh0ZW5zaW9uICAgIEZlYnJ1YXJ5IDIwMDcN Cg0KDQogICBUaGUgZm9sbG93aW5nIHNob3dzIHRoZSB1c2Ugb2YgUVRMUyB3 aXRoIGEgVExTIHNlc3Npb24gY2FjaGUgaGl0IGFuZA0KICAgdXNlIG9mIHRo ZSBmdWxsIFFITE8gY29tbWFuZCBhZnRlciBUTFMgaXMgc3RhcnRlZC4gIFRo aXMgZm9ybSBpcw0KICAgc2ltcGxlciB0aGFuIHBpcGVsaW5lZCBTVEFSVFRM UyAoYXMgc2hvd24gYmVsb3cpIGJ1dCBzbGlnaHRseSBsZXNzDQogICBlZmZp Y2llbnQuICBUaGUgTUFJTCBjb29tYW5kIGlzIGluIHRoZSBjbGllbnQncyA0 dGggcGFja2V0Lg0KDQogICAgICAgIEM6IFRDUCAgU1lODQogICAgICAgIFM6 ICAgICAgU1lOL0FDSw0KICAgICAgICBDOiAgICAgIEFDSw0KICAgICAgICBT OiBTTVRQIDxxc210cC1ncmVldD4NCiAgICAgICAgQzogICAgICBRVExTDQog ICAgICAgICAgIFRMUyAgY2xpZW50IGhlbGxvDQogICAgICAgIFM6ICAgICAg c2VydmVyIGhlbGxvLCBjaGFuZ2UgY2lwaGVyLCBmaW5pc2ggaGFuZHNoYWtl DQogICAgICAgIEM6ICAgICAgY2hhbmdlIGNpcGhlciwgZmluaXNoIGhhbmRz aGFrZQ0KICAgICAgICAgICBTTVRQIFFITE8gPGRvbWFpbj4gPHFobG8taWQ+ DQogICAgICAgICAgICAgICAgQVVUSCBQTEFJTiA8Y3JlZHM+DQogICAgICAg ICAgICAgICAgTUFJTCBGUk9NOjwuLi4+DQogICAgICAgICAgICAgICAgUkNQ VCBUTzo8Li4uPg0KICAgICAgICAgICAgICAgIC4uLg0KICAgICAgICBTOiBT TVRQIDxxc210cC1ncmVldD4NCiAgICAgICAgICAgICAgICAyMjAgT0sNCiAg ICAgICAgICAgICAgICAyMzUgT0sNCiAgICAgICAgICAgICAgICAyNTAgT0sN CiAgICAgICAgICAgICAgICAyNTAgT0sNCiAgICAgICAgICAgICAgICAuLi4N Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCkZpbmNoICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEF1 Z3VzdCAyOCwgMjAwNyAgICAgICAgICAgICAgIFtQYWdlIDIzXQ0KDA0KSW50 ZXJuZXQtRHJhZnQgICAgVGhlIFFVSUNLU1RBUlQgU01UUCBzZXJ2aWNlIGV4 dGVuc2lvbiAgICBGZWJydWFyeSAyMDA3DQoNCg0KICAgVGhlIGZvbGxvd2lu ZyBzaG93cyBhIHN1Y2Nlc3NmdWwgZnVsbCBRVUlDS1NUQVJUIGNvbm5lY3Rp b24uICBUaGUNCiAgIE1BSUwgY29tbWFuZCBpcyBpbiB0aGUgY2xpZW50J3Mg NHRoIHBhY2tldC4NCg0KICAgICAgICBDOiBUQ1AgIFNZTg0KICAgICAgICBT OiAgICAgIFNZTi9BQ0sNCiAgICAgICAgQzogICAgICBBQ0sNCiAgICAgICAg ICAgU01UUCBRSExPIDxkb21haW4+IDxxaGxvLWlkPg0KICAgICAgICAgICAg ICAgIFNUQVJUVExTDQogICAgICAgICAgIFRMUyAgY2xpZW50IGhlbGxvDQog ICAgICAgIFM6IFNNVFAgPHFzbXRwLWdyZWV0Pg0KICAgICAgICAgICAgICAg IDIyMCBPSw0KICAgICAgICAgICAgICAgIDIyMCBPSw0KICAgICAgICAgICBU TFMgIHNlcnZlciBoZWxsbywgY2VydGlmaWNhdGUsIGV0Yy4NCiAgICAgICAg QzogICAgICBrZXkgZXhjaGFuZ2UsIGNoYW5nZSBjaXBoZXIsIGZpbmlzaCBo YW5kc2hha2UNCiAgICAgICAgUzogICAgICBjaGFuZ2UgY2lwaGVyLCBmaW5p c2ggaGFuZHNoYWtlDQogICAgICAgIEM6IFNNVFAgUUhMTyA8ZG9tYWluPiA8 cWhsby1pZD4NCiAgICAgICAgICAgICAgICBBVVRIIFBMQUlOIDxjcmVkcz4N CiAgICAgICAgICAgICAgICBNQUlMIEZST006PC4uLj4NCiAgICAgICAgICAg ICAgICBSQ1BUIFRPOjwuLi4+DQogICAgICAgICAgICAgICAgLi4uDQogICAg ICAgIFM6ICAgICAgMjIwIE9LDQogICAgICAgICAgICAgICAgMjM1IE9LDQog ICAgICAgICAgICAgICAgMjUwIE9LDQogICAgICAgICAgICAgICAgMjUwIE9L DQogICAgICAgICAgICAgICAgLi4uDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KRmluY2ggICAgICAgICAg ICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDI4LCAyMDA3ICAgICAgICAgICAg ICAgW1BhZ2UgMjRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICBUaGUgUVVJQ0tT VEFSVCBTTVRQIHNlcnZpY2UgZXh0ZW5zaW9uICAgIEZlYnJ1YXJ5IDIwMDcN Cg0KDQogICBJZiB0aGUgUVVJQ0tTVEFSVCBoYW5kc2hha2UgZmFpbHMsIHRo ZSBzZXJ2ZXIgcmVqZWN0cyB0aGUgaW5pdGlhbA0KICAgcGlwZWxpbmVkIGNv bW1hbmRzIGFuZCBkaXNjYXJkcyB0aGUgZmlyc3QgVExTIGNsaWVudCBoZWxs bywgYW5kIHRoZQ0KICAgY2xpZW50IGZhbGxzIGJhY2sgdG8gYmFzaWMgUVVJ Q0tTVEFSVC4gIFRoZSBNQUlMIGNvbW1hbmQgaXMgaW4gdGhlDQogICBjbGll bnQncyA1dGggcGFja2V0LCB0aGUgc2FtZSBhcyBiYXNpYyBRVUlDS1NUQVJU IHdpdGhvdXQgdGhlIGZhaWxlZA0KICAgaGFuZHNoYWtlLg0KDQogICAgICAg IEM6IFRDUCAgU1lODQogICAgICAgIFM6ICAgICAgU1lOL0FDSw0KICAgICAg ICBDOiAgICAgIEFDSw0KICAgICAgICAgICBTTVRQIFFITE8gPGRvbWFpbj4g PHFobG8taWQ+DQogICAgICAgICAgICAgICAgU1RBUlRUTFMNCiAgICAgICAg ICAgVExTICBjbGllbnQgaGVsbG8NCiAgICAgICAgUzogU01UUCA8cXNtdHAt Z3JlZXQ+DQogICAgICAgICAgICAgICAgNTIwIGJhZCBRSExPIElEDQogICAg ICAgICAgICAgICAgNTAzIGJhZCBzZXF1ZW5jZSBvZiBjb21tYW5kcw0KICAg ICAgICBDOiAgICAgIFFITE8gPGRvbWFpbj4gPHFobG8taWQ+DQogICAgICAg ICAgICAgICAgUVRMUw0KICAgICAgICAgICBUTFMgIGNsaWVudCBoZWxsbw0K ICAgICAgICBTOiBTTVRQIDIyMCBPSw0KICAgICAgICAgICBUTFMgIHNlcnZl ciBoZWxsbywgY2VydGlmaWNhdGUsIGV0Yy4NCiAgICAgICAgQzogICAgICBr ZXkgZXhjaGFuZ2UsIGNoYW5nZSBjaXBoZXIsIGZpbmlzaCBoYW5kc2hha2UN CiAgICAgICAgUzogICAgICBjaGFuZ2UgY2lwaGVyLCBmaW5pc2ggaGFuZHNo YWtlDQogICAgICAgICAgICAgICAgPHFzbXRwLWdyZWV0Pg0KICAgICAgICBD OiAgICAgIFFITE8gPGRvbWFpbj4NCiAgICAgICAgICAgICAgICBBVVRIIFBM QUlOIDxjcmVkcz4NCiAgICAgICAgICAgICAgICBNQUlMIEZST006PC4uLj4N CiAgICAgICAgICAgICAgICBSQ1BUIFRPOjwuLi4+DQogICAgICAgICAgICAg ICAgLi4uDQogICAgICAgIFM6ICAgICAgMjIwIE9LDQogICAgICAgICAgICAg ICAgMjM1IE9LDQogICAgICAgICAgICAgICAgMjUwIE9LDQogICAgICAgICAg ICAgICAgMjUwIE9LDQogICAgICAgICAgICAgICAgLi4uDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpGaW5jaCAgICAgICAgICAgICAg ICAgICAgRXhwaXJlcyBBdWd1c3QgMjgsIDIwMDcgICAgICAgICAgICAgICBb UGFnZSAyNV0NCgwNCkludGVybmV0LURyYWZ0ICAgIFRoZSBRVUlDS1NUQVJU IFNNVFAgc2VydmljZSBleHRlbnNpb24gICAgRmVicnVhcnkgMjAwNw0KDQoN CiAgIFRoZSBmb2xsb3dpbmcgc2hvd3MgYSBzdWNjZXNzZnVsIGZ1bGwgUVVJ Q0tTVEFSVCBjb25uZWN0aW9uIHdpdGggYQ0KICAgVExTIHNlc3Npb24gY2Fj aGUgaGl0LiAgVGhlIE1BSUwgY29tbWFuZCBpcyBpbiB0aGUgY2xpZW50J3Mg M3JkDQogICBwYWNrZXQuDQoNCiAgICAgICAgQzogVENQICBTWU4NCiAgICAg ICAgUzogICAgICBTWU4vQUNLDQogICAgICAgIEM6ICAgICAgQUNLDQogICAg ICAgICAgIFNNVFAgUUhMTyA8ZG9tYWluPiA8cWhsby1pZD4NCiAgICAgICAg ICAgICAgICBTVEFSVFRMUw0KICAgICAgICAgICBUTFMgIGNsaWVudCBoZWxs bw0KICAgICAgICBTOiBTTVRQIDxxc210cC1ncmVldD4NCiAgICAgICAgICAg ICAgICAyMjAgT0sNCiAgICAgICAgICAgICAgICAyMjAgT0sNCiAgICAgICAg ICAgVExTICBzZXJ2ZXIgaGVsbG8sIGNoYW5nZSBjaXBoZXIsIGZpbmlzaCBo YW5kc2hha2UNCiAgICAgICAgQzogICAgICBjaGFuZ2UgY2lwaGVyLCBmaW5p c2ggaGFuZHNoYWtlDQogICAgICAgICAgIFNNVFAgUUhMTyA8ZG9tYWluPiA8 cWhsby1pZD4NCiAgICAgICAgICAgICAgICBBVVRIIFBMQUlOIDxjcmVkcz4N CiAgICAgICAgICAgICAgICBNQUlMIEZST006PC4uLj4NCiAgICAgICAgICAg ICAgICBSQ1BUIFRPOjwuLi4+DQogICAgICAgICAgICAgICAgLi4uDQogICAg ICAgIFM6ICAgICAgMjIwIE9LDQogICAgICAgICAgICAgICAgMjM1IE9LDQog ICAgICAgICAgICAgICAgMjUwIE9LDQogICAgICAgICAgICAgICAgMjUwIE9L DQogICAgICAgICAgICAgICAgLi4uDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KRmluY2ggICAgICAgICAg ICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDI4LCAyMDA3ICAgICAgICAgICAg ICAgW1BhZ2UgMjZdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICBUaGUgUVVJQ0tT VEFSVCBTTVRQIHNlcnZpY2UgZXh0ZW5zaW9uICAgIEZlYnJ1YXJ5IDIwMDcN Cg0KDQpBdXRob3IncyBBZGRyZXNzDQoNCiAgIFRvbnkgRmluY2gNCiAgIFVu aXZlcnNpdHkgb2YgQ2FtYnJpZGdlIENvbXB1dGluZyBTZXJ2aWNlDQogICBO ZXcgTXVzZXVtcyBTaXRlDQogICBQZW1icm9rZSBTdHJlZXQNCiAgIENhbWJy aWRnZSAgQ0IyIDNRSA0KICAgRU5HTEFORA0KDQogICBQaG9uZTogKzQ0IDc5 NyAwNDAgMTQyNg0KICAgRW1haWw6IGRvdEBkb3RhdC5hdA0KICAgVVJJOiAg IGh0dHA6Ly9kb3RhdC5hdC8NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCkZpbmNoICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEF1Z3Vz dCAyOCwgMjAwNyAgICAgICAgICAgICAgIFtQYWdlIDI3XQ0KDA0KSW50ZXJu ZXQtRHJhZnQgICAgVGhlIFFVSUNLU1RBUlQgU01UUCBzZXJ2aWNlIGV4dGVu c2lvbiAgICBGZWJydWFyeSAyMDA3DQoNCg0KRnVsbCBDb3B5cmlnaHQgU3Rh dGVtZW50DQoNCiAgIENvcHlyaWdodCAoQykgVGhlIElFVEYgVHJ1c3QgKDIw MDcpLg0KDQogICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gdGhlIHJp Z2h0cywgbGljZW5zZXMgYW5kIHJlc3RyaWN0aW9ucw0KICAgY29udGFpbmVk IGluIEJDUCA3OCwgYW5kIGV4Y2VwdCBhcyBzZXQgZm9ydGggdGhlcmVpbiwg dGhlIGF1dGhvcnMNCiAgIHJldGFpbiBhbGwgdGhlaXIgcmlnaHRzLg0KDQog ICBUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVk IGhlcmVpbiBhcmUgcHJvdmlkZWQgb24gYW4NCiAgICJBUyBJUyIgYmFzaXMg YW5kIFRIRSBDT05UUklCVVRPUiwgVEhFIE9SR0FOSVpBVElPTiBIRS9TSEUg UkVQUkVTRU5UUw0KICAgT1IgSVMgU1BPTlNPUkVEIEJZIChJRiBBTlkpLCBU SEUgSU5URVJORVQgU09DSUVUWSwgVEhFIElFVEYgVFJVU1QgQU5EDQogICBU SEUgSU5URVJORVQgRU5HSU5FRVJJTkcgVEFTSyBGT1JDRSBESVNDTEFJTSBB TEwgV0FSUkFOVElFUywgRVhQUkVTUw0KICAgT1IgSU1QTElFRCwgSU5DTFVE SU5HIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUg VVNFIE9GDQogICBUSEUgSU5GT1JNQVRJT04gSEVSRUlOIFdJTEwgTk9UIElO RlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5ZIElNUExJRUQNCiAgIFdBUlJBTlRJ RVMgT0YgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9SIEEgUEFSVElD VUxBUiBQVVJQT1NFLg0KDQoNCkludGVsbGVjdHVhbCBQcm9wZXJ0eQ0KDQog ICBUaGUgSUVURiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcgdGhlIHZh bGlkaXR5IG9yIHNjb3BlIG9mIGFueQ0KICAgSW50ZWxsZWN0dWFsIFByb3Bl cnR5IFJpZ2h0cyBvciBvdGhlciByaWdodHMgdGhhdCBtaWdodCBiZSBjbGFp bWVkIHRvDQogICBwZXJ0YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBvciB1 c2Ugb2YgdGhlIHRlY2hub2xvZ3kgZGVzY3JpYmVkIGluDQogICB0aGlzIGRv Y3VtZW50IG9yIHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vuc2UgdW5k ZXIgc3VjaCByaWdodHMNCiAgIG1pZ2h0IG9yIG1pZ2h0IG5vdCBiZSBhdmFp bGFibGU7IG5vciBkb2VzIGl0IHJlcHJlc2VudCB0aGF0IGl0IGhhcw0KICAg bWFkZSBhbnkgaW5kZXBlbmRlbnQgZWZmb3J0IHRvIGlkZW50aWZ5IGFueSBz dWNoIHJpZ2h0cy4gIEluZm9ybWF0aW9uDQogICBvbiB0aGUgcHJvY2VkdXJl cyB3aXRoIHJlc3BlY3QgdG8gcmlnaHRzIGluIFJGQyBkb2N1bWVudHMgY2Fu IGJlDQogICBmb3VuZCBpbiBCQ1AgNzggYW5kIEJDUCA3OS4NCg0KICAgQ29w aWVzIG9mIElQUiBkaXNjbG9zdXJlcyBtYWRlIHRvIHRoZSBJRVRGIFNlY3Jl dGFyaWF0IGFuZCBhbnkNCiAgIGFzc3VyYW5jZXMgb2YgbGljZW5zZXMgdG8g YmUgbWFkZSBhdmFpbGFibGUsIG9yIHRoZSByZXN1bHQgb2YgYW4NCiAgIGF0 dGVtcHQgbWFkZSB0byBvYnRhaW4gYSBnZW5lcmFsIGxpY2Vuc2Ugb3IgcGVy bWlzc2lvbiBmb3IgdGhlIHVzZSBvZg0KICAgc3VjaCBwcm9wcmlldGFyeSBy aWdodHMgYnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRoaXMNCiAgIHNw ZWNpZmljYXRpb24gY2FuIGJlIG9idGFpbmVkIGZyb20gdGhlIElFVEYgb24t bGluZSBJUFIgcmVwb3NpdG9yeSBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9y Zy9pcHIuDQoNCiAgIFRoZSBJRVRGIGludml0ZXMgYW55IGludGVyZXN0ZWQg cGFydHkgdG8gYnJpbmcgdG8gaXRzIGF0dGVudGlvbiBhbnkNCiAgIGNvcHly aWdodHMsIHBhdGVudHMgb3IgcGF0ZW50IGFwcGxpY2F0aW9ucywgb3Igb3Ro ZXIgcHJvcHJpZXRhcnkNCiAgIHJpZ2h0cyB0aGF0IG1heSBjb3ZlciB0ZWNo bm9sb2d5IHRoYXQgbWF5IGJlIHJlcXVpcmVkIHRvIGltcGxlbWVudA0KICAg dGhpcyBzdGFuZGFyZC4gIFBsZWFzZSBhZGRyZXNzIHRoZSBpbmZvcm1hdGlv biB0byB0aGUgSUVURiBhdA0KICAgaWV0Zi1pcHJAaWV0Zi5vcmcuDQoNCg0K QWNrbm93bGVkZ21lbnQNCg0KICAgRnVuZGluZyBmb3IgdGhlIFJGQyBFZGl0 b3IgZnVuY3Rpb24gaXMgcHJvdmlkZWQgYnkgdGhlIElFVEYNCiAgIEFkbWlu aXN0cmF0aXZlIFN1cHBvcnQgQWN0aXZpdHkgKElBU0EpLg0KDQoNCg0KDQoN CkZpbmNoICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyOCwg MjAwNyAgICAgICAgICAgICAgIFtQYWdlIDI4XQ0KDA0K --1870869256-1411204027-1173373085=:8816 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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --1870869256-1411204027-1173373085=:8816-- From lemonade-bounces@ietf.org Thu Mar 08 17:18:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPPcQ-0003c8-Ca; Thu, 08 Mar 2007 15:53:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPPYt-0006tU-KG; Thu, 08 Mar 2007 15:50:07 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPPYs-0007ca-WE; Thu, 08 Mar 2007 15:50:07 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id D671926F24; Thu, 8 Mar 2007 20:50:05 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HPPYq-0007JF-KU; Thu, 08 Mar 2007 15:50:04 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 08 Mar 2007 15:50:04 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-imap-sieve-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 : Support for Sieve in Internet Message Access Protocol (IMAP4) Author(s) : B. Leiba Filename : draft-ietf-lemonade-imap-sieve-02.txt Pages : 23 Date : 2007-3-8 Sieve defines an email filtering language that can, in principle, plug into any point in the processing of an email message. As defined in the base specification, it plugs into mail delivery. This document defines how Sieve can plug into points in the IMAP protocol where messages are created or changed, adding the option of user- defined or installation-defined filtering (or, with Sieve extensions, features such as notifications). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-imap-sieve-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-imap-sieve-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-imap-sieve-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: <2007-3-8133447.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-imap-sieve-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-imap-sieve-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-8133447.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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --NextPart-- From lemonade-bounces@ietf.org Thu Mar 08 17:33:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPPm9-0000TE-MH; Thu, 08 Mar 2007 16:03:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPPZr-0007xY-Aa; Thu, 08 Mar 2007 15:51:07 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HPPZo-00026g-0Q; Thu, 08 Mar 2007 15:51:07 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 5005517733; Thu, 8 Mar 2007 20:50:04 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HPPYq-0007I4-1y; Thu, 08 Mar 2007 15:50:04 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 08 Mar 2007 15:50:04 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-deployments-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 : Deployment Considerations for lemonade-compliant Mobile Email Author(s) : R. Gellens Filename : draft-ietf-lemonade-deployments-06.txt Pages : 12 Date : 2007-3-8 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-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-deployments-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-deployments-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: <2007-3-8125938.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-deployments-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-deployments-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-8125938.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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --NextPart-- From lemonade-bounces@ietf.org Fri Mar 09 04:20:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPbH5-0007DI-1x; Fri, 09 Mar 2007 04:20:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPSN2-0008SK-1X; Thu, 08 Mar 2007 18:50:04 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPSN0-0003C6-KV; Thu, 08 Mar 2007 18:50:04 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 9334232A83; Thu, 8 Mar 2007 23:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HPSN0-0000Kj-E0; Thu, 08 Mar 2007 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 08 Mar 2007 18:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-streaming-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 : Streaming Multimedia Messaging Attachments Author(s) : N. Cook Filename : draft-ietf-lemonade-streaming-01.txt Pages : 29 Date : 2007-3-8 This document describes a method for streaming multimedia attachments received by a resource constrained and/or mobile device from an IMAP server. It allows such clients, which often have limits in storage space and bandwidth, to play video and audio e-mail content. The document describes a profile for making use of the IMAP URLAUTH extension (RFC 4467), the Network Announcement SIP Media Service (RFC 4240), and the Media Server Control Markup Language (RFC 4722). The document also defines a new IMAP METADATA entry. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-streaming-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-streaming-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-streaming-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: <2007-3-8175914.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-streaming-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-streaming-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-8175914.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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --NextPart-- From lemonade-bounces@ietf.org Fri Mar 09 15:50:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPm38-0004s8-Er; Fri, 09 Mar 2007 15:50:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPm2r-0003Zu-34; Fri, 09 Mar 2007 15:50:35 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HPm2q-0008CN-Ng; Fri, 09 Mar 2007 15:50:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id A3AB82AD02; Fri, 9 Mar 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HPm2M-0003Lc-DY; Fri, 09 Mar 2007 15:50:02 -0500 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, 09 Mar 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-search-within-04.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, et al. Filename : draft-ietf-lemonade-search-within-04.txt Pages : 13 Date : 2007-3-9 This document describes the WITHIN extension to IMAP SEARCH. IMAP SEARCH returns messages whose internal date is within or outside a specified interval. The mechanism described here, OLDER and YOUNGER, differs from BEFORE and SINCE in that the client specifies an interval, rather than a date. We expect WITHIN to be most useful for persistent searches from mobile devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-search-within-04.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-04.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-04.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: <2007-3-9113111.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-search-within-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-search-within-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-9113111.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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --NextPart-- From lemonade-bounces@ietf.org Sun Mar 11 19:42:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQXgD-0008GF-9Q; Sun, 11 Mar 2007 19:42:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQXgB-0008G9-UL for lemonade@ietf.org; Sun, 11 Mar 2007 19:42:19 -0400 Received: from usremg02.bea.com ([66.248.192.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQXgA-0005ly-HE for lemonade@ietf.org; Sun, 11 Mar 2007 19:42:19 -0400 Received: from usremr01.bea.com (usremr01.bea.com [10.160.29.91]) by usremg02.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l2BNgG50027752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 11 Mar 2007 16:42:17 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by usremr01.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l2BNfwmJ020187 for ; Sun, 11 Mar 2007 15:42:15 -0800 Received: from 172.24.28.185 ([172.24.28.185]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Sun, 11 Mar 2007 23:42:14 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 09 Mar 2007 15:48:28 -0400 From: Eric Burger To: "lemonade@ietf.org" Message-ID: Thread-Topic: Scribes and Transcribes Thread-Index: AcdilKvH6kU3Gc6HEdubsQAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.2.21.161433 X-Spam-Score: 0.7 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [lemonade] Scribes and Transcribes 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 need volunteers. Two note takers, one for the Monday and one for the Thursday Prague sessions. Note taking is the easiest job: you only need to write down decisions. And, you get immortalized in the proceedings! Two Jabber scribes, one for the Monday and one for the Thursday Prague sessions. Jabber scribing is a bit more involved, but it guarantees you will pay attention to everything. Please respond to me off-list. _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sun Mar 11 19:42:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQXgL-0008OL-OH; Sun, 11 Mar 2007 19:42:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQXgI-0008II-ME for lemonade@ietf.org; Sun, 11 Mar 2007 19:42:26 -0400 Received: from usremg02.bea.com ([66.248.192.22]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HQXgC-0001BL-6y for lemonade@ietf.org; Sun, 11 Mar 2007 19:42:26 -0400 Received: from usremr02.bea.com (mailrelay.bea.com [10.160.29.92]) by usremg02.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l2BNgEwh027736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 11 Mar 2007 16:42:14 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by usremr02.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l2BNgCxF009208; Sun, 11 Mar 2007 15:42:12 -0800 Received: from 172.24.28.185 ([172.24.28.185]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Sun, 11 Mar 2007 23:42:12 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 09 Mar 2007 15:37:42 -0400 Subject: Re: [lemonade] Draft Agenda From: Eric Burger To: Alexey Melnikov Message-ID: Thread-Topic: [lemonade] Draft Agenda Thread-Index: AcdZmymJtjxIt4/FTwG2/z/DzUD4HQI+AExB In-Reply-To: <45E042BA.8040608@isode.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.2.21.151434 X-Spam-Score: 0.3 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f 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 How about this: Monday ====== Agenda Bashing (Chairs) (5 min) Quick Discussions: Convert (Ray) draft-ietf-lemonade-convert-05 (10 min) Quick Reconnect (Alexey) draft-ietf-lemonade-reconnect-client-03 (5 min) Notification Discussions (90 min): Notification Format (Chris) draft-ietf-lemonade-msgevent-01 Notifications Framework (Ray) draft-ietf-lemonade-notifications-03 Brief Overview of RFC 3842 (Rohan) SIP Notifications (Rohan) draft-mahy-sieve-notify-sip-00 Thursday ======== Agenda Bashing (5 min) SMTP Restart (Randy for Tony) draft-fanf-smtp-quickstart-00* (10 min) IMAP Sieve (Barry) draft-ietf-lemonade-imap-sieve-02 (10 min) Streaming (Eric) draft-ietf-lemonade-streaming-01 (10 min) Notifications Conclusion (chairs) (20 min) Profile-bis (Alexey) draft-ietf-lemonade-profile-bis-04 (20 min) Marketing (Eric) (10 min) Views (60 min) Updates & Next Steps (Chairs) (15 min) We will cover document status not needing discussion on the list. This includes: Compress Deployments IMAP URL SASL-IR Within * We missed the I-D submission deadline due to a technical error. You can find the document on the supplemental web site: On 2/24/07 5:50 AM, "Alexey Melnikov" wrote: > Eric Burger wrote: > >> Monday >> ====== >> Agenda Bashing (5 min) >> >> Quick Discussions: >> Convert (10 min) >> Deployments (10 min) >> >> Longer Discussions: >> Quick Reconnect (20 min) >> >> > I don't think we need that much time, as there are no open issues in the > document and it is already past WGLC. > >> Notifications (60 min) >> >> > Eric, do you want to expand on who is going to present this one. Are we > talking about IMAP NOTIFY extension, notification format, etc? > >> Thursday >> ======== >> Agenda Bashing (5 min) >> >> SMTP Restart (10 min) >> IMAP Sieve (10 min) >> Streaming (10 min) >> Notifications Conclusion (20 min) >> Profile-bis (20 min) >> Marketing (10 min) >> Views (60 min) >> Updates & Next Steps (15 min) >> >> >> We will cover document status not needing discussion on the list. This >> includes: >> Compress >> IMAP URL >> SASL-IR >> Within >> >> > The rest looks reasonable. > > _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Mar 12 07:20:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQia2-0000rP-54; Mon, 12 Mar 2007 07:20:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQia0-0000r2-Ka for lemonade@ietf.org; Mon, 12 Mar 2007 07:20:40 -0400 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HQiZz-0002sW-48 for lemonade@ietf.org; Mon, 12 Mar 2007 07:20:40 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 12 Mar 2007 11:20:17 +0000 Message-ID: <45F2914A.4010106@isode.com> Date: Sat, 10 Mar 2007 11:06:50 +0000 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 WG Content-Type: multipart/mixed; boundary="------------010609040101070503070105" X-Spam-Score: 0.3 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Subject: [lemonade] [Fwd: Conflicting Enhanced Status Codes between RFC 4468 and draft-siemborski-rfc2554bis] 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 --------------010609040101070503070105 Content-type: text/plain; charset="us-ascii" FYI. --------------010609040101070503070105 Content-type: message/rfc822; name="Conflicting Enhanced Status Codes between RFC 4468 and draft-siemborski-rfc2554bis" Content-transfer-encoding: 7bit Content-Disposition: inline; filename="Conflicting Enhanced Status Codes between RFC 4468 and draft-siemborski-rfc2554bis" X-Identity-Key: id1 X-Account-Key: account1 Message-ID: <45F2910C.2080008@isode.com> Date: Sat, 10 Mar 2007 11:05:48 +0000 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: ietf-smtp@imc.org CC: Chris Newman Subject: Conflicting Enhanced Status Codes between RFC 4468 and draft-siemborski-rfc2554bis MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Hi, Chris Newman just pointed out that there is a conflict between an Enhanced Status Code defined in RFC 4468 and draft-siemborski-rfc2554bis. RFC 4468 defines: X.7.8 Trust relationship required The submission server requires a configured trust relationship with a third-party server in order to access the message content. draft-siemborski-rfc2554bis-08.txt defines: 535 5.7.8 Authentication credentials invalid This response to the AUTH command indicates that the authentication failed due to invalid or insufficient authentication credentials. In this case, the client SHOULD ask the user to supply new credentials (such as by presenting a password dialog box). Use of 5.7.8 in draft-siemborski-rfc2554bis-08.txt is a new feature since RFC 2554. However, draft-siemborski-rfc2554bis was around for long time and there might be more implementations of its 5.7.8 than that from the RFC 4468. There are certainly fewer RFC 4468 implementations deployed at the moment. So, in order to decide whether draft-siemborski-rfc2554bis needs to be changed or whether rfc4468bis needs to be published, I would like to solicit comments from implementors of both extensions. Regards, Alexey --------------010609040101070503070105 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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --------------010609040101070503070105-- From lemonade-bounces@ietf.org Mon Mar 12 08:07:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQjJ6-0004Nx-BW; Mon, 12 Mar 2007 08:07:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQjJ4-0004NP-Rw for lemonade@ietf.org; Mon, 12 Mar 2007 08:07:14 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQjJ2-00007h-Cc for lemonade@ietf.org; Mon, 12 Mar 2007 08:07:14 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 12 Mar 2007 12:07:11 +0000 Message-ID: <45F5424B.6010205@isode.com> Date: Mon, 12 Mar 2007 12:06:35 +0000 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: Eric Burger Subject: Re: [lemonade] Draft Agenda References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Eric Burger wrote: >How about this: > >Monday >====== >Agenda Bashing (Chairs) (5 min) > >Quick Discussions: > Convert (Ray) draft-ietf-lemonade-convert-05 (10 min) > Quick Reconnect (Alexey) draft-ietf-lemonade-reconnect-client-03 (5 min) > >Notification Discussions (90 min): > Notification Format (Chris) draft-ietf-lemonade-msgevent-01 > Notifications Framework (Ray) draft-ietf-lemonade-notifications-03 > Brief Overview of RFC 3842 (Rohan) > SIP Notifications (Rohan) draft-mahy-sieve-notify-sip-00 > > >Thursday >======== >Agenda Bashing (5 min) > >SMTP Restart (Randy for Tony) draft-fanf-smtp-quickstart-00* (10 min) >IMAP Sieve (Barry) draft-ietf-lemonade-imap-sieve-02 (10 min) >Streaming (Eric) draft-ietf-lemonade-streaming-01 (10 min) >Notifications Conclusion (chairs) (20 min) >Profile-bis (Alexey) draft-ietf-lemonade-profile-bis-04 (20 min) >Marketing (Eric) (10 min) >Views (60 min) >Updates & Next Steps (Chairs) (15 min) > > >We will cover document status not needing discussion on the list. This >includes: >Compress >Deployments >IMAP URL >SASL-IR >Within > > This looks fine. Thanks. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Mar 12 08:54:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQk2N-0008Hu-Iw; Mon, 12 Mar 2007 08:54:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQk2M-0008Hm-LY for lemonade@ietf.org; Mon, 12 Mar 2007 08:54:02 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQk2E-00033N-FG for lemonade@ietf.org; Mon, 12 Mar 2007 08:54:02 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 12 Mar 2007 12:53:53 +0000 Message-ID: <45F54D3C.3070102@isode.com> Date: Mon, 12 Mar 2007 12:53:16 +0000 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: Eric Burger Subject: Re: [lemonade] Draft Agenda References: <45F5424B.6010205@isode.com> In-Reply-To: <45F5424B.6010205@isode.com> 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: d17f825e43c9aed4fd65b7edddddec89 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 Alexey Melnikov wrote: >> Thursday >> ======== > [...] >> Views (60 min) > I volunteer Arnt to talk to VFOLDER and Dave Cridland to talk about CONTEXT. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Mar 12 09:08:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQkGC-00023p-L1; Mon, 12 Mar 2007 09:08:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQkGB-00023h-IG for lemonade@ietf.org; Mon, 12 Mar 2007 09:08:19 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQkFv-0005Dd-GD for lemonade@ietf.org; Mon, 12 Mar 2007 09:08:19 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 170974AC22; Mon, 12 Mar 2007 14:08:00 +0100 (CET) Message-Id: Date: Mon, 12 Mar 2007 14:06:45 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Draft Agenda References: <45F5424B.6010205@isode.com> <45F54D3C.3070102@isode.com> In-Reply-To: <45F54D3C.3070102@isode.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: 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 Alexey Melnikov writes: > Alexey Melnikov wrote: > >>> Thursday >>> ======== > > [...] > >>> Views (60 min) > > I volunteer Arnt to talk to VFOLDER and Dave Cridland to talk about CONTEXT. I remind the esteemed WG members that we've already chosen. Not the choice I preferred and not made in a way I like, but we did choose. I'm not eager to go through all that again. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Mar 12 11:43:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQmgi-0001M7-Jl; Mon, 12 Mar 2007 11:43:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQmgh-0001KS-AW for lemonade@ietf.org; Mon, 12 Mar 2007 11:43:51 -0400 Received: from mta02.zimbra.com ([4.78.240.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQmgc-00005P-4F for lemonade@ietf.org; Mon, 12 Mar 2007 11:43:51 -0400 Received: from dogfood.zimbra.com (dogfood.liquidsys.com [66.92.25.198]) by mta02.zimbra.com (Postfix) with ESMTP id C0311810C45; Mon, 12 Mar 2007 07:37:34 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 3A7D910E682; Mon, 12 Mar 2007 08:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dSGGMvLn6B5; Mon, 12 Mar 2007 08:43:38 -0700 (PDT) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 7879E10E683; Mon, 12 Mar 2007 08:43:38 -0700 (PDT) Date: Mon, 12 Mar 2007 08:43:38 -0700 (PDT) From: Dan Karp To: Arnt Gulbrandsen Message-ID: <1575622101.9881173714218349.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: Subject: Re: [lemonade] Draft Agenda MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [67.112.123.102] X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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 > > I volunteer Arnt to talk to VFOLDER and Dave Cridland to talk about > > CONTEXT. > > I remind the esteemed WG members that we've already chosen. Not the > choice I preferred and not made in a way I like, but we did choose. > I'm not eager to go through all that again. For those of us playing along from home, which one got selected? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Mar 12 12:26:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQnLS-00085k-0s; Mon, 12 Mar 2007 12:25:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQnLR-0007xK-3z for lemonade@ietf.org; Mon, 12 Mar 2007 12:25:57 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQnLF-00061G-IH for lemonade@ietf.org; Mon, 12 Mar 2007 12:25:57 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 40F724AC1B; Mon, 12 Mar 2007 17:25:44 +0100 (CET) Message-Id: Date: Mon, 12 Mar 2007 17:24:30 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Draft Agenda References: <1575622101.9881173714218349.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: <1575622101.9881173714218349.JavaMail.root@dogfood.liquidsys.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: 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 Dan Karp answers me: >> I remind the esteemed WG members that we've already chosen. Not the >> choice I preferred and not made in a way I like, but we did choose. >> I'm not eager to go through all that again. > > For those of us playing along from home, which one got selected? CONTEXT. Profile-bis will require CONTEXT. VFOLDER will be published too (either as PS, I or E, we'll see when the time comes), but not mentioned in profile-bis. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Mar 16 06:28:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HS9fO-0004R2-57; Fri, 16 Mar 2007 06:28:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HS9fN-0004Qv-4V for lemonade@ietf.org; Fri, 16 Mar 2007 06:28:09 -0400 Received: from usremg02.bea.com ([66.248.192.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HS9fI-0002cH-Of for lemonade@ietf.org; Fri, 16 Mar 2007 06:28:09 -0400 Received: from usremr02.bea.com (mailrelay.bea.com [10.160.29.92]) by usremg02.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l2GAS2DH030950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 16 Mar 2007 03:28:02 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by usremr02.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l2GAS15K026390 for ; Fri, 16 Mar 2007 03:28:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 16 Mar 2007 03:28:00 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Presentations Thread-Index: AcdntcW0bNzAMNmqQQifgqkVDCJR0w== From: "Eric Burger" To: X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.2.21.151434 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [lemonade] Presentations 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="===============1310803824==" Errors-To: lemonade-bounces@ietf.org --===============1310803824== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgeW91IGhhdmUgYmVlbiB0YXBwZWQgdG8gZ2l2ZSBhIHByZXNlbnRhdGlvbiBpbiBQcmFndWUs IHBsZWFzZSBzZW5kIGl0IHRvIG1lIGJ5IFNhdHVyZGF5LiBUaGFua3MuIA0KDQotLQ0KU2VudCBm cm9tIG15IHdpcmVsZXNzIGUtbWFpbCBkZXZpY2UuIFNvcnJ5IGlmIHRlcnNlLiAgV2UgYWxsIG5l ZWQgbGVtb25hZGU6IHNlZSA8aHR0cDovL3d3dy5zdGFuZGFyZHN0cmFjay5jb20vaWV0Zi9sZW1v bmFkZT4gZm9yIHdoYXQgbGVtb25hZGUgaXMuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpOb3RpY2U6ICBUaGlz IGVtYWlsIG1lc3NhZ2UsIHRvZ2V0aGVyIHdpdGggYW55IGF0dGFjaG1lbnRzLCBtYXkgY29udGFp bgppbmZvcm1hdGlvbiAgb2YgIEJFQSBTeXN0ZW1zLCAgSW5jLiwgIGl0cyBzdWJzaWRpYXJpZXMg IGFuZCAgYWZmaWxpYXRlZAplbnRpdGllcywgIHRoYXQgbWF5IGJlIGNvbmZpZGVudGlhbCwgIHBy b3ByaWV0YXJ5LCAgY29weXJpZ2h0ZWQgIGFuZC9vcgpsZWdhbGx5IHByaXZpbGVnZWQsIGFuZCBp cyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwKb3IgZW50aXR5 IG5hbWVkIGluIHRoaXMgbWVzc2FnZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lw aWVudCwKYW5kIGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9yLCBwbGVhc2UgaW1t ZWRpYXRlbHkgcmV0dXJuIHRoaXMKYnkgZW1haWwgYW5kIHRoZW4gZGVsZXRlIGl0Lgo= --===============1310803824== 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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============1310803824==-- From lemonade-bounces@ietf.org Fri Mar 16 06:54:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSA4X-0000dv-Or; Fri, 16 Mar 2007 06:54:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSA4W-0000do-US for lemonade@ietf.org; Fri, 16 Mar 2007 06:54:08 -0400 Received: from usremg02.bea.com ([66.248.192.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSA4V-0005tE-5H for lemonade@ietf.org; Fri, 16 Mar 2007 06:54:08 -0400 Received: from usremr01.bea.com (usremr01.bea.com [10.160.29.91]) by usremg02.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l2GAs5rI015785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 16 Mar 2007 03:54:05 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by usremr01.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l2GAs3Fh007509 for ; Fri, 16 Mar 2007 03:54:04 -0700 Received: from 172.24.28.31 ([172.24.28.31]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Fri, 16 Mar 2007 10:54:03 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 16 Mar 2007 06:54:02 -0400 From: Eric Burger To: "lemonade@ietf.org" Message-ID: Thread-Topic: Note Takers Thread-Index: AcdnuWhPpt81vtOsEduaXAAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.2.21.161433 X-Spam-Score: 0.5 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [lemonade] Note Takers 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 We still need note takers for Monday and Thursday, and a Jabber Scribe for Thursday. Please volunteer before you are volunteered. Thanks. _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sun Mar 18 10:54:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSwmQ-0003Jf-II; Sun, 18 Mar 2007 10:54:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSwmP-0003JZ-L8; Sun, 18 Mar 2007 10:54:41 -0400 Received: from usremg01.bea.com ([66.248.192.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSwmL-0004GC-6D; Sun, 18 Mar 2007 10:54:41 -0400 Received: from usremr02.bea.com (usremr02.bea.com [10.160.29.92]) by usremg01.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l2IEsYea015519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 18 Mar 2007 07:54:35 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by usremr02.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l2IEsXxk028123; Sun, 18 Mar 2007 07:54:33 -0700 Received: from 172.24.28.133 ([172.24.28.133]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Sun, 18 Mar 2007 14:54:32 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Sun, 18 Mar 2007 15:54:30 +0100 From: Eric Burger To: Ted Hardie , Chris Newman Message-ID: Thread-Topic: Publication Request: Reconnect Client Thread-Index: AcdpbVTlkzUcs9VgEduECAAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.2.21.151434 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: "lemonade@ietf.org" , The IESG Subject: [lemonade] Publication Request: Reconnect Client 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 DOCUMENT: IMAP4 Extensions for Quick Mailbox Resynchronization Draft-ietf-lemonade-reconnect-client-03 (Standards Track) =20 (1.a) Document Shepherd: Eric Burger, eburger@bea.com , personally reviewed this document. This document is ready for publication. =20 (1.b) Work group review: The lemonade work group provided review of this document. There were a few comments by Randy Gellens on the WGLC of -02; the two changes are incorporated in -03. =20 (1.c) Further review required: This document does not need further specialized review, as it has received review by many members of the IMAP community. =20 (1.d.i) Document Shepherd Comfort Level: High (1.d.ii) Document Useful and Needed: Yes (1.d.iii) IPR Disclosures: None known =20 (1.e) WG Consensus: There was virtually no comment on this revision, mainly because there was substantial comment on the previous version that was addressed. This group is normally very vocal if there are problems. The only substantial comment was by a client implementer who said that the protocol would =B3do no harm.=B2 =20 (1.f) There are no members with objections or concerns. There are no threats of appeal or process issues. =20 (1.g) ID-nits: Check and verified with idnits 2.04.01 =20 (1.h) References: All references (normative and informative) are current RFCs, checked with rfc-what-i-mean (11/06) =20 (1.i) IANA Considerations: Yes, correct, consistent, and follows RFC 3501 rules; note that actual capability name will be given to IANA during AUTH48. =20 (1.j) ABNF: Passes Bill=B9s ABNF Parser =20 (1.k) Document Announcement: =20 Technical Summary =20 This document defines an IMAP4 extension, which gives an IMAP client the ability to quickly resynchronize any previously opened mailbox as part of the SELECT command, without the need for server-side state or additional client round-trips. This extension also introduces a new response that allows for a more compact representation for a list of expunged messages. =20 =20 Working Group Summary =20 There is consensus in the WG to publish this document. There are three client implementations and four server implementations by work group members. =20 =20 Document Quality =20 Virtually all members of the Lemonade WG have reviewed the document. =20 The document has been checked manually and using idnits 2.04.01, and passed both checks.=20 =20 Eric Burger shepherds this document, has reviewed this document, and believes that this version is ready for forwarding to the IESG for publication. _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Mar 19 07:40:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTGDv-0007DE-83; Mon, 19 Mar 2007 07:40:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTGDu-0007D7-0u for lemonade@ietf.org; Mon, 19 Mar 2007 07:40:22 -0400 Received: from usremg01.bea.com ([66.248.192.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTGDs-0001Ka-Jm for lemonade@ietf.org; Mon, 19 Mar 2007 07:40:22 -0400 Received: from usremr02.bea.com (usremr02.bea.com [10.160.29.92]) by usremg01.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l2JBeIn7014737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 19 Mar 2007 04:40:18 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by usremr02.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l2JBeHee001461 for ; Mon, 19 Mar 2007 04:40:17 -0700 Received: from 172.24.28.52 ([172.24.28.52]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Mon, 19 Mar 2007 11:40:16 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Mon, 19 Mar 2007 12:34:12 +0100 From: Eric Burger To: "lemonade@ietf.org" Message-ID: Thread-Topic: Document Status Thread-Index: AcdqGoQFwrFVSNYNEdu8xQAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.3.19.31933 X-Spam-Score: 0.5 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [lemonade] Document Status 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 To not take time in the meeting, here is an update on select documents. Published draft-melnikov-imap-search-ret-03 RFC 4731 draft-ietf-lemonade-profile-07 RFC 4550 draft-ietf-lemonade-urlauth-08 RFC 4467 draft-ietf-lemonade-burl-04 RFC 4468 draft-ietf-lemonade-catenate-05 RFC 4469 draft-ietf-lemonade-mms-mapping-06 RFC 4356 draft-ietf-lemonade-goals-05 RFC 4416 RFC Editor Queue draft-vaudreuil-futuredelivery RFC-EDITOR IESG draft-ietf-lemonade-search-within AD Write-Up draft-ietf-lemonade-deployments Jennings Discuss draft-ietf-lemonade-compress Jennings Discuss draft-ietf-lemonade-reconnect-client Publication Requested Notes draft-melnikov-imap-expunged In Reconnect Client _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Mar 19 11:45:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTK2Z-00062G-2Y; Mon, 19 Mar 2007 11:44:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTK2X-000626-Hx for lemonade@ietf.org; Mon, 19 Mar 2007 11:44:53 -0400 Received: from usremg01.bea.com ([66.248.192.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTK1z-0006dT-LN for lemonade@ietf.org; Mon, 19 Mar 2007 11:44:53 -0400 Received: from usremr01.bea.com (mailrelay.bea.com [10.160.29.91]) by usremg01.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l2JFiDjm032212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 19 Mar 2007 08:44:13 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by usremr01.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l2JFiBJd009268 for ; Mon, 19 Mar 2007 08:44:12 -0700 Received: from 172.24.30.170 ([172.24.30.170]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Mon, 19 Mar 2007 15:44:11 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Mon, 19 Mar 2007 16:05:50 +0100 From: Eric Burger To: "lemonade@ietf.org" Message-ID: Thread-Topic: Scribes and Transcribes for Thursday Thread-Index: AcdqOBSeU0g2D9YrEdu8xQAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.2.21.161433 X-Spam-Score: 0.5 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [lemonade] Scribes and Transcribes for Thursday 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 We still need a Jabber Scribe and Note Taker for Thursday's session. Thanks to Tony and Arnt for volunteering for today. _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Mar 20 04:09:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTZOS-0005cU-13; Tue, 20 Mar 2007 04:08:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTZOQ-0005cP-Gg for lemonade@ietf.org; Tue, 20 Mar 2007 04:08:30 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTZOO-0002EF-SU for lemonade@ietf.org; Tue, 20 Mar 2007 04:08:30 -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 l2K88G522767 for ; Tue, 20 Mar 2007 08:08:16 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 20 Mar 2007 04:08:01 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D0EF2B987@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed OMA liaison Thread-Index: AcdqxbGfYFGKfNSYQbO/FtRBtpvjnA== From: "Glenn Parsons" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 3f2cf88677bfbdeff30feb2c80e2257d Subject: [lemonade] Proposed OMA liaison 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="===============1655139086==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============1655139086== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76AC6.E0E406AF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C76AC6.E0E406AF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, Attached below is the proposed liaison text to OMA as I discussed in the LEMONADE meeting yesterday. Please send any comments by the end of this week. Cheers, Glenn. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D From: IETF LEMONADE Working Group To: OMA MWG MEM Sub Working Group Date: April 1, 2007 Title: Update on LEMONADE activity=09 Response contact: lemonade@ietf.org Purpose: For Action The IETF LEMONADE working group (WG) would like to update you on our progress. Of note is that we have several RFCs that have already been approved and published: RFC 4467 - IMAP URLAUTH RFC 4468 - IMAP BURL RFC 4469 - IMAP CATENATE RFC 4550 - LEMONADE Profile RFC 4551 - IMAP CONDSTORE RFC 4731 - IMAP ESEARCH In addition, the following documents are essentially complete and are complete and in the process of formal approval and publication: draft-vaudreuil-futuredelivery draft-ietf-lemonade-search-within =20 draft-ietf-lemonade-deployments =20 draft-ietf-lemonade-compress =20 draft-ietf-lemonade-reconnect-client =20 In addition, we are nearing completion on the rest of the documents in discussion in the WG. This includes CONVERT, notifications and finally LEMONADE Profile-bis. It is our intention that this work will conclude by June 2007. In the LEMONADE Notifications document (draft-ietf-lemonade-notifications) we have currently based 'out of band' notification on OMA EMN. However, in the development of the functionality we have the need to identify items (such as message subject, date, sender, etc.) that are not part of the EMN mechanism. As a result, we have described these as a different extended notification payload in addition to the base EMN payload. OMA MEM indicated that you were working with OMA BAC Push to validate our current approach and to extend EMN with these capabilities. We would appreciate a status on this activity. For the IMAP CONVERT protocol, the LEMONADE WG had agreed that the only 'Mandatory to Implement' conversion that will appear in the CONVERT protocol is HTML to TEXT. However, as we indicated previously the protocol itself can support any subset or even the entire OMA STI parameter suite. However, we do not believe that support of the full list of OMA STI parameters is appropriate. The LEMONADE profile will not specifify this list and OMA MEM indicated that you would further subset the full list of STI parameters to make it realistic for the OMA mobile enabler. We would appreciate a status on this activity. As we had previously indicated, LEMONADE has conducted a preliminary interoperability event. Note that from an IETF perspective, our interest is only to facilitate protocol maturity. Specifically, that is to prove the feasibility of the protocol (which we have done with our preliminary event) and to document multiple interworking implementations to prove maturity (which we will do later this year). At our preliminary event nine entities participated with four test LEMONADE servers and numerous clients. The group tested these implementations against the LEMONADE Profile (RFC 4550) and identified some clarifications that were needed to make the specifications clear. The specific issues of the interop event have been used to update our documents. We expect that we will have another event later this year based on the published Profile-bis. OMA MEM had indicated that the latter would be of interest to OMA IOP. =20 Finally, as you know, the LEMONADE WG is working on a set of extensions to IMAP and ESMTP to support mobile email. This set will be succinctly described in the LEMONADE profile (draft-ietf-lemonade-profile-bis). We understand that the OMA TS will normatively reference the LEMONADE profile for the MEM protocol. In order to help us understand your usage better, we would appreciate a presentation on the OMA MEM TS for LEMONADE. Would it be possible to have such a presentation at our next meeting? Up-to-date information on LEMONADE Internet-Drafts and RFCs can always be found at http://tools.ietf.org/wg/lemonade/=20 with additional information on our charter page http://www.ietf.org/html.charters/lemonade-charter.html=20 Finally, as information, the next meetings of the IETF LEMONADE WG are: - May ? - LEMONADE interim - TBD - July 22-27 - IETF 69 plenary - Chicago ------_=_NextPart_001_01C76AC6.E0E406AF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Proposed OMA liaison

Folks,

Attached below is the proposed liaison = text to OMA as I discussed in the LEMONADE meeting yesterday.

Please send any comments by the end of = this week.

Cheers,
Glenn.


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

From: IETF LEMONADE Working = Group
To: OMA MWG MEM Sub Working = Group
Date: April 1, 2007
Title: Update on LEMONADE = activity     
Response contact:  = lemonade@ietf.org
Purpose:  For Action


The IETF LEMONADE working group (WG) = would like to update you on our progress.  Of note is that we have = several RFCs that have already been approved and published:

RFC 4467 – IMAP = URLAUTH
RFC 4468 – IMAP = BURL
RFC 4469 – IMAP = CATENATE
RFC 4550 – LEMONADE = Profile
RFC 4551 – IMAP = CONDSTORE
RFC 4731 – IMAP = ESEARCH

In addition, the following documents = are essentially complete and are complete and in the process of formal = approval and publication:

       = draft-vaudreuil-futuredelivery
       = draft-ietf-lemonade-search-within  
       = draft-ietf-lemonade-deployments   
       = draft-ietf-lemonade-compress   
       = draft-ietf-lemonade-reconnect-client   

In addition, we are nearing completion = on the rest of the documents in discussion in the WG.  This = includes CONVERT, notifications and finally LEMONADE Profile-bis. It is = our intention that this work will conclude by June 2007.

In the LEMONADE Notifications document = (draft-ietf-lemonade-notifications) we have currently based ‘out = of band’ notification on OMA EMN.  However, in the = development of the functionality we have the need to identify items = (such as message subject, date, sender, etc.) that are not part of the = EMN mechanism.  As a result, we have described these as a different = extended notification payload in addition to the base EMN payload.  = OMA MEM indicated that you were working with OMA BAC Push to validate = our current approach and to extend EMN with these = capabilities.   We would appreciate a status on this = activity.

For the IMAP CONVERT protocol, the = LEMONADE WG had agreed that the only ‘Mandatory to = Implement’ conversion that will appear in the CONVERT protocol is = HTML to TEXT.  However, as we indicated previously the protocol = itself can support any subset or even the entire OMA STI parameter = suite.  However, we do not believe that support of the full list of = OMA STI parameters is appropriate.  The LEMONADE profile will not = specifify this list and OMA MEM indicated that you would further subset = the full list of STI parameters to make it realistic for the OMA mobile = enabler.   We would appreciate a status on this = activity.

As we had previously indicated, = LEMONADE has conducted a preliminary interoperability event.   = Note that from an IETF perspective, our interest is only to facilitate = protocol maturity.  Specifically, that is to prove the feasibility = of the protocol (which we have done with our preliminary event) and to = document multiple interworking implementations to prove maturity (which = we will do later this year).   At our preliminary event nine = entities participated with four test LEMONADE servers and numerous = clients.  The group tested these implementations against the = LEMONADE Profile (RFC 4550) and identified some clarifications that were = needed to make the specifications clear.  The specific issues of = the interop event have been used to update our documents.  We = expect that we will have another event later this year based on the = published Profile-bis.  OMA MEM had indicated that the latter would = be of interest to OMA IOP.   

Finally, as you know, the LEMONADE WG = is working on a set of extensions to IMAP and ESMTP to support mobile = email.  This set will be succinctly described in the LEMONADE = profile (draft-ietf-lemonade-profile-bis).  We understand that the = OMA TS will normatively reference the LEMONADE profile for the MEM = protocol.  In order to help us understand your usage better, we = would appreciate a presentation on the OMA MEM TS for LEMONADE.  = Would it be possible to have such a presentation at our next = meeting?

Up-to-date information on LEMONADE = Internet-Drafts and RFCs can always be found at http://tools.ietf.org/wg/lemonade/
with additional information on our = charter page http://www.ietf.org/html.charters/lemonade-charter.html

Finally, as information, the next = meetings of the IETF LEMONADE WG are:
- May ? – LEMONADE = interim – TBD
- July 22-27 – IETF 69 = plenary – Chicago



------_=_NextPart_001_01C76AC6.E0E406AF-- --===============1655139086== 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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============1655139086==-- From lemonade-bounces@ietf.org Tue Mar 20 08:45:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTdiq-0003PK-Mq; Tue, 20 Mar 2007 08:45:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTdip-0003PD-Bm for lemonade@ietf.org; Tue, 20 Mar 2007 08:45:51 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTdio-0001sJ-15 for lemonade@ietf.org; Tue, 20 Mar 2007 08:45:51 -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 l2KCjmS3017506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Mar 2007 05:45:48 -0700 Received: from [dhcp-3078.ietf68.org] (vpn-10-50-16-103.qualcomm.com [10.50.16.103]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l2KCjgdA020986; Tue, 20 Mar 2007 05:45:47 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D0EF2B987@zcarhxm0.corp.nortel.com> References: <085091CB2CA14E4B8B163FFC37C84E9D0EF2B987@zcarhxm0.corp.nortel.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Tue, 20 Mar 2007 05:44:42 -0700 To: "Glenn Parsons" , From: Randall Gellens Subject: Re: [lemonade] Proposed OMA liaison Mime-Version: 1.0 X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 1.3 (+) 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: , Content-Type: multipart/mixed; boundary="===============0782029081==" Errors-To: lemonade-bounces@ietf.org --===============0782029081== Content-Type: text/html; charset="us-ascii" Re: [lemonade] Proposed OMA liaison
At 4:08 AM -0400 3/20/07, Glenn Parsons wrote:

Finally, as you know, the LEMONADE WG is working on a set of extensions to IMAP and ESMTP to support mobile email.

This is potentially unclear, in that it might suggest that lemonade is working on a set of IMAP/SMP extensions in addition to what has been mentioned above.  I suggest changing this to:

Finally, as you know, the work of the LEMONADE WG is focused on a set of extensions to IMAP and ESMTP to support mobile email.
--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
The early bird catches the worm, but what does the early worm get?
                                                --Randall Gellens
--===============0782029081== 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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --===============0782029081==-- From lemonade-bounces@ietf.org Tue Mar 20 09:00:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTdwY-0002FG-GL; Tue, 20 Mar 2007 09:00:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTdwW-0002Eg-MS for lemonade@ietf.org; Tue, 20 Mar 2007 09:00:00 -0400 Received: from [2001:838:378:0:2a0:d2ff:fe1b:110f] (helo=turner.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTdwU-0005Gc-Va for lemonade@ietf.org; Tue, 20 Mar 2007 09:00:00 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 8E893498002; Tue, 20 Mar 2007 13:07:35 +0000 (GMT) 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 19024-05; Tue, 20 Mar 2007 13:07:29 +0000 (GMT) Received: from invsysm1 (unknown [IPv6:2001:df8:0:16:211:9ff:feae:f8a1]) by turner.dave.cridland.net (Postfix) with ESMTP id 1EF65498001; Tue, 20 Mar 2007 13:07:29 +0000 (GMT) Subject: Re: [lemonade] Proposed OMA liaison References: <085091CB2CA14E4B8B163FFC37C84E9D0EF2B987@zcarhxm0.corp.nortel.com> In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D0EF2B987@zcarhxm0.corp.nortel.com> MIME-Version: 1.0 Message-Id: <5360.1174395573.274364@invsysm1> Date: Tue, 20 Mar 2007 12:59:33 +0000 From: Dave Cridland To: Glenn Parsons Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: Debian amavisd-new at turner.dave.cridland.net X-Spam-Score: -2.8 (--) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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 Mar 20 08:08:01 2007, Glenn Parsons wrote: > In addition, the following documents are essentially complete and > are > complete and in the process of formal approval and publication: > > "essentially complete and in the process" - you have it twice completed. > were working with OMA BAC Push to validate our current approach and > to > extend EMN with these capabilities. We would appreciate a status > on > this activity. > > "a status report", perhaps? > Finally, as you know, the LEMONADE WG is working on a set of > extensions > to IMAP and ESMTP to support mobile email. This set will be > succinctly > described in the LEMONADE profile > (draft-ietf-lemonade-profile-bis). We Agree with Randy's suggestion for rewording. The set of extensions will be summarized in the profile, not described. > understand that the OMA TS will normatively reference the LEMONADE > profile for the MEM protocol. In order to help us understand your > usage > better, we would appreciate a presentation on the OMA MEM TS for > LEMONADE. Would it be possible to have such a presentation at our > next > meeting? > > Thursday? :-) 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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Mar 21 18:57:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU9jr-0001nb-Pp; Wed, 21 Mar 2007 18:57:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU9jp-0001il-TF for lemonade@ietf.org; Wed, 21 Mar 2007 18:57:01 -0400 Received: from usremg01.bea.com ([66.248.192.21]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HU9jY-00042C-Qg for lemonade@ietf.org; Wed, 21 Mar 2007 18:56:56 -0400 Received: from usremr02.bea.com (usremr02.bea.com [10.160.29.92]) by usremg01.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l2LMucWL011189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 21 Mar 2007 15:56:38 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by usremr02.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l2LMua56004659 for ; Wed, 21 Mar 2007 15:56:37 -0700 Received: from 172.24.29.102 ([172.24.29.102]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Wed, 21 Mar 2007 22:56:36 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Wed, 21 Mar 2007 23:56:33 +0100 From: Eric Burger To: "lemonade@ietf.org" Message-ID: Thread-Topic: WGLC streaming Thread-Index: AcdsDCuVagzuVtf/Eduf5gAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.3.21.140435 X-Spam-Score: 0.5 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [lemonade] WGLC streaming 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 the announcement for the Work Group Last Call on the Streaming Media draft: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-streaming-01.txt Work group last call ends March 8. _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Mar 21 19:39:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUAPC-0008HL-Ei; Wed, 21 Mar 2007 19:39:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUAPB-0008E7-0T for lemonade@ietf.org; Wed, 21 Mar 2007 19:39:45 -0400 Received: from usremg01.bea.com ([66.248.192.21]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HUAP9-00061K-GE for lemonade@ietf.org; Wed, 21 Mar 2007 19:39:44 -0400 Received: from usremr01.bea.com (mailrelay.bea.com [10.160.29.91]) by usremg01.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l2LNdf08008761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 21 Mar 2007 16:39:41 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by usremr01.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l2LNddgE015240 for ; Wed, 21 Mar 2007 16:39:40 -0700 Received: from 172.24.29.102 ([172.24.29.102]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Wed, 21 Mar 2007 23:39:39 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 22 Mar 2007 00:39:37 +0100 From: Eric Burger To: "lemonade@ietf.org" Message-ID: Thread-Topic: WGLC msgevent Thread-Index: AcdsEi/FbjcY5tgFEduf5gAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.2.21.161433 X-Spam-Score: 0.5 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [lemonade] WGLC msgevent 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 http://www.ietf.org/internet-drafts/draft-ietf-lemonade-msgevent-01.txt Work Group Last Call closes March 8. _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Mar 21 19:41:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUAR3-0000QD-0D; Wed, 21 Mar 2007 19:41:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUAR2-0000Q8-IA for lemonade@ietf.org; Wed, 21 Mar 2007 19:41:40 -0400 Received: from usremg01.bea.com ([66.248.192.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUAR1-00071H-3u for lemonade@ietf.org; Wed, 21 Mar 2007 19:41:40 -0400 Received: from usremr01.bea.com (mailrelay.bea.com [10.160.29.91]) by usremg01.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l2LNfb75010112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 21 Mar 2007 16:41:37 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by usremr01.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l2LNfZix015998 for ; Wed, 21 Mar 2007 16:41:36 -0700 Received: from 172.24.29.102 ([172.24.29.102]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Wed, 21 Mar 2007 23:41:35 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 22 Mar 2007 00:41:33 +0100 From: Eric Burger To: "lemonade@ietf.org" Message-ID: Thread-Topic: Expert Review: annotatemore (like WGLC) Thread-Index: AcdsEnTps3GatNgFEduf5gAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.2.21.161433 X-Spam-Score: 0.5 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [lemonade] Expert Review: annotatemore (like WGLC) 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 http://www.ietf.org/internet-drafts/draft-daboo-imap-annotatemore-11.txt Expert review requested; comments due by March 15. _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Mar 21 19:42:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUASE-00014R-9h; Wed, 21 Mar 2007 19:42:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUASD-00014M-Jg for lemonade@ietf.org; Wed, 21 Mar 2007 19:42:53 -0400 Received: from usremg01.bea.com ([66.248.192.21]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HUASC-0006Fc-2t for lemonade@ietf.org; Wed, 21 Mar 2007 19:42:53 -0400 Received: from usremr01.bea.com (mailrelay.bea.com [10.160.29.91]) by usremg01.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l2LNgogj010529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Mar 2007 16:42:50 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by usremr01.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l2LNglQg016098; Wed, 21 Mar 2007 16:42:48 -0700 Received: from 172.24.29.102 ([172.24.29.102]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Wed, 21 Mar 2007 23:42:47 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 22 Mar 2007 00:42:45 +0100 From: Eric Burger To: "lemonade@ietf.org" , Chris Newman Message-ID: Thread-Topic: Annotatemore Thread-Index: AcdsEp/T3n/i9NgFEduf5gAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.2.21.161433 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [lemonade] Annotatemore 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 My sleepy mistake. This one goes straight to the IESG. Chris: we think, in our expert opinion, it is ready. http://www.ietf.org/internet-drafts/draft-daboo-imap-annotatemore-11.txt _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Mar 21 19:44:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUATh-0002GJ-Ff; Wed, 21 Mar 2007 19:44:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUATf-0002GD-OK for lemonade@ietf.org; Wed, 21 Mar 2007 19:44:23 -0400 Received: from usremg02.bea.com ([66.248.192.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUATc-0007Rp-Jd for lemonade@ietf.org; Wed, 21 Mar 2007 19:44:23 -0400 Received: from usremr02.bea.com (mailrelay.bea.com [10.160.29.92]) by usremg02.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l2LNiIMo011354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 21 Mar 2007 16:44:19 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by usremr02.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l2LNiHGC022902 for ; Wed, 21 Mar 2007 16:44:17 -0700 Received: from 172.24.29.102 ([172.24.29.102]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Wed, 21 Mar 2007 23:44:17 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 22 Mar 2007 00:44:15 +0100 From: Eric Burger To: "lemonade@ietf.org" Message-ID: Thread-Topic: WGLC IMAP URL Thread-Index: AcdsEtV4E+WTG9gGEduf5gAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.2.21.151434 X-Spam-Score: 0.8 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [lemonade] WGLC IMAP URL 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 http://www.ietf.org/internet-drafts/draft-ietf-lemonade-rfc2192bis-04.txt Work Group Last Call ends March 15. _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Mar 21 19:53:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUAce-0003xo-Lp; Wed, 21 Mar 2007 19:53:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUAce-0003xj-9R for lemonade@ietf.org; Wed, 21 Mar 2007 19:53:40 -0400 Received: from usremg02.bea.com ([66.248.192.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUAcc-0000cv-Rc for lemonade@ietf.org; Wed, 21 Mar 2007 19:53:40 -0400 Received: from usremr02.bea.com (mailrelay.bea.com [10.160.29.92]) by usremg02.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l2LNrbii017236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 21 Mar 2007 16:53:37 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by usremr02.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l2LNrZJL026526 for ; Wed, 21 Mar 2007 16:53:35 -0700 Received: from 172.24.29.102 ([172.24.29.102]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Wed, 21 Mar 2007 23:53:35 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 22 Mar 2007 00:53:33 +0100 From: Eric Burger To: "lemonade@ietf.org" Message-ID: Thread-Topic: WGLC IMAP URL - update Thread-Index: AcdsFCIQYInw1dgHEduf5gAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.2.21.151434 X-Spam-Score: 0.5 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [lemonade] WGLC IMAP URL - update 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 http://www.ietf.org/internet-drafts/draft-ietf-lemonade-rfc2192bis-04.txt Work Group Last Call ends April 15. _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Mar 21 19:54:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUAcy-000439-0z; Wed, 21 Mar 2007 19:54:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUAcw-00042F-RD for lemonade@ietf.org; Wed, 21 Mar 2007 19:53:58 -0400 Received: from usremg02.bea.com ([66.248.192.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUAcv-0000uG-DA for lemonade@ietf.org; Wed, 21 Mar 2007 19:53:58 -0400 Received: from usremr02.bea.com (mailrelay.bea.com [10.160.29.92]) by usremg02.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l2LNrtI1017543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 21 Mar 2007 16:53:55 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by usremr02.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l2LNrr2c026767 for ; Wed, 21 Mar 2007 16:53:54 -0700 Received: from 172.24.29.102 ([172.24.29.102]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Wed, 21 Mar 2007 23:53:54 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 22 Mar 2007 00:53:52 +0100 From: Eric Burger To: "lemonade@ietf.org" Message-ID: Thread-Topic: WGLC msgevent - update Thread-Index: AcdsFC1ja630i9gHEduf5gAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.2.21.151434 X-Spam-Score: 0.5 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [lemonade] WGLC msgevent - update 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 http://www.ietf.org/internet-drafts/draft-ietf-lemonade-msgevent-01.txt Work Group Last Call closes April 8. _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Mar 21 19:54:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUAdB-00046q-Ed; Wed, 21 Mar 2007 19:54:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUAdA-00046e-Re for lemonade@ietf.org; Wed, 21 Mar 2007 19:54:12 -0400 Received: from usremg01.bea.com ([66.248.192.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUAd9-0000xs-DN for lemonade@ietf.org; Wed, 21 Mar 2007 19:54:12 -0400 Received: from usremr02.bea.com (usremr02.bea.com [10.160.29.92]) by usremg01.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l2LNs9pe019306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 21 Mar 2007 16:54:09 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by usremr02.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l2LNs7Rt026861 for ; Wed, 21 Mar 2007 16:54:08 -0700 Received: from 172.24.29.102 ([172.24.29.102]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Wed, 21 Mar 2007 23:54:07 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 22 Mar 2007 00:54:05 +0100 From: Eric Burger To: "lemonade@ietf.org" Message-ID: Thread-Topic: WGLC streaming - update Thread-Index: AcdsFDUjc3sY0tgHEduf5gAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.2.21.151434 X-Spam-Score: 0.5 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [lemonade] WGLC streaming - update 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 the announcement for the Work Group Last Call on the Streaming Media draft: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-streaming-01.txt Work group last call ends April 8. _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Mar 21 19:55:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUAdo-0004NH-4r; Wed, 21 Mar 2007 19:54:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUAdm-0004IS-K4 for lemonade@ietf.org; Wed, 21 Mar 2007 19:54:50 -0400 Received: from usremg01.bea.com ([66.248.192.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUAdl-00016n-79 for lemonade@ietf.org; Wed, 21 Mar 2007 19:54:50 -0400 Received: from usremr02.bea.com (usremr02.bea.com [10.160.29.92]) by usremg01.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l2LNsls9019512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 21 Mar 2007 16:54:47 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by usremr02.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l2LNsj7c026926 for ; Wed, 21 Mar 2007 16:54:46 -0700 Received: from 172.24.29.102 ([172.24.29.102]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Wed, 21 Mar 2007 23:54:45 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 22 Mar 2007 00:54:42 +0100 From: Eric Burger To: "lemonade@ietf.org" Message-ID: Thread-Topic: Sleepy Chair Thread-Index: AcdsFEsxifybJtgHEduf5gAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.2.21.151434 X-Spam-Score: 0.5 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [lemonade] Sleepy Chair 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 Ignore the negative two weeks for WGLC's. Dates really were for April. See you later this morning :-( _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Mar 22 05:04:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUJDv-0000Nv-5W; Thu, 22 Mar 2007 05:04:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUJDs-0000M0-2K for lemonade@ietf.org; Thu, 22 Mar 2007 05:04:40 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUJDq-0005ck-Mp for lemonade@ietf.org; Thu, 22 Mar 2007 05:04:40 -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 l2M94bOV031018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 22 Mar 2007 02:04:38 -0700 Received: from [130.129.20.116] (vpn-10-50-16-10.qualcomm.com [10.50.16.10]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l2M94ZFb029195 for ; Thu, 22 Mar 2007 02:04:36 -0700 Mime-Version: 1.0 Message-Id: Date: Thu, 22 Mar 2007 10:04:34 +0100 To: lemonade@ietf.org From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [lemonade] New Area Advisor 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 For those who were not able to join us in Prague, I would like to introduce Chris Newman to the working group. Chris is taking over as Applications Area Director, and he will be the new Area Advisor for this group. I will be available to Chris as a resource as we go forward, but from this point on. he is the point of contact for any AD questions or actions. Please accept my thanks for all the hard work that the group has already done, and I look forward to participating in our future work from the floor. best regards, Ted Hardie _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sat Mar 24 11:52:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HV8Ws-0004iq-9r; Sat, 24 Mar 2007 11:51:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HV8Wq-0004ha-U7 for lemonade@ietf.org; Sat, 24 Mar 2007 11:51:40 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HV8Wm-0001vb-Fa for lemonade@ietf.org; Sat, 24 Mar 2007 11:51:40 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2OFpMIS017386 for ; Sat, 24 Mar 2007 08:51:31 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2OFpLaT025191 for ; Sat, 24 Mar 2007 08:51:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Date: Sat, 24 Mar 2007 08:51:27 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC msgevent - update Thread-Index: AcdsFC1ja630i9gHEduf5gAWy4mm/wBBcBtwAESWqBc= From: "Eric Burger" To: x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [lemonade] Postponing WGLC msgevent 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 Greg is absolutely correct. Last of the late-night WGLC shrapnel. This document is NOT ready for WGLC. We will wait for the next revision of the document. Get the other reviews done! -- Sent from my wireless e-mail device. Sorry if terse. We all need lemonade: see for what lemonade is. -----Original Message----- From: Vaudreuil, Greg M (Greg) To: Eric Burger; lemonade@ietf.org Sent: Sat Mar 24 06:57:33 2007 Subject: RE: [lemonade] WGLC msgevent - update >From the unsent notes, I recorded that this document was going to be edited (possibly into two drafts) by Randy to incorporate a number of additional events from the notify draft. Greg V. -----Original Message----- From: Eric Burger [mailto:eburger@bea.com] Sent: Wednesday, March 21, 2007 7:54 PM To: lemonade@ietf.org Subject: [lemonade] WGLC msgevent - update http://www.ietf.org/internet-drafts/draft-ietf-lemonade-msgevent-01.txt Work Group Last Call closes April 8. _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Mar 26 08:34:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVoOf-0007ct-Hg; Mon, 26 Mar 2007 08:34:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVoOd-0007cl-VU for lemonade@ietf.org; Mon, 26 Mar 2007 08:33:59 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVoOc-0006l4-KQ for lemonade@ietf.org; Mon, 26 Mar 2007 08:33:59 -0400 Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2QCXv1g012252 for ; Mon, 26 Mar 2007 12:33:58 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JFI00H01G1T7S00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for lemonade@ietf.org; Mon, 26 Mar 2007 06:33:57 -0600 (MDT) Received: from [192.168.150.60] ([129.150.156.5]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JFI00442G8GHK40@mail-amer.sun.com>; Mon, 26 Mar 2007 06:33:57 -0600 (MDT) Date: Mon, 26 Mar 2007 12:34:21 +0000 From: Chris Newman Subject: Re: [lemonade] WGLC msgevent - update In-reply-to: To: Eric Burger , lemonade@ietf.org Message-id: <12905F6CB6821AB0BB13A136@[192.168.150.60]> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 draft-gulbrandsen-imap-notify-03.txt is an application of msgevents, but introduced new events. This raises issues with the msgevent document. For more details, see the Prague WG meeting minutes and/or jabber log. I would like to thank the new volunteer editor: Randall Gellens who will address these issues. - Chris Eric Burger wrote on 3/22/07 0:53 +0100: > http://www.ietf.org/internet-drafts/draft-ietf-lemonade-msgevent-01.txt > > Work Group Last Call closes April 8. > > _______________________________________________________________________ > Notice: This email message, together with any attachments, may contain > information of BEA Systems, Inc., its subsidiaries and affiliated > entities, that may be confidential, proprietary, copyrighted and/or > legally privileged, and is intended solely for the use of the individual > or entity named in this message. If you are not the intended recipient, > and have received this message in error, please immediately return this > by email and then delete it. > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade > Supplemental Web Site: > http://www.standardstrack.com/ietf/lemonade > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Mar 26 08:55:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVojX-0002Up-UR; Mon, 26 Mar 2007 08:55:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVojW-0002Uk-0f for lemonade@ietf.org; Mon, 26 Mar 2007 08:55:34 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVojU-0001Mw-NT for lemonade@ietf.org; Mon, 26 Mar 2007 08:55:34 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 26 Mar 2007 13:55:17 +0100 Message-ID: <4606D91D.3000408@isode.com> Date: Sun, 25 Mar 2007 21:18:37 +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" Subject: Re: [lemonade] WGLC msgevent References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 Eric Burger wrote: >http://www.ietf.org/internet-drafts/draft-ietf-lemonade-msgevent-01.txt > >Work Group Last Call closes March 8. > > The document needs to add 3 new events (mailbox create, delete and rename), as discussed in Prague. (And the text in the appendix should be adjusted as the result). Dave suggested that subscription change can be added as well, but I am frankly unsure about its utility. Otherwise I think the document is well written and is ready for publication. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Mar 27 08:06:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWAR1-0004qN-Kc; Tue, 27 Mar 2007 08:05:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWAR0-0004qH-CU for lemonade@ietf.org; Tue, 27 Mar 2007 08:05:54 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWAQy-00058Q-Po for lemonade@ietf.org; Tue, 27 Mar 2007 08:05:54 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 27 Mar 2007 13:05:47 +0100 Message-ID: <4608EF81.5050401@isode.com> Date: Tue, 27 Mar 2007 11:18:41 +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: neil.cook@noware.co.uk Subject: Re: [lemonade] WGLC streaming References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb 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 Eric Burger wrote: >This is the announcement for the Work Group Last Call on the Streaming Media >draft: >http://www.ietf.org/internet-drafts/draft-ietf-lemonade-streaming-01.txt > >Work group last call ends April 8. The document is in a pretty good shape. However examples contain several minor bugs and there are also some issues with IANA registrations as well as with Normative References. My detailed comments are below: 1). Almost all IMAP examples use trailing '\' to specify line continuations (and the examples don't use them consistently). This is unusual for IMAP and not specified in the conventions. I suggest just removing them. 2). In Section 2.2: The first example: > C: a122 UID FETCH 24356 BODY[1.2.MIME] > S: * 26 FETCH (BODY[1.2.MIME] {127} > S: Content-Transfer-Encoding: base64 > S: Content-Type: video/mpeg; > S: UID 24356 FLAGS (\Seen)) Should be: C: a122 UID FETCH 24356 BODY[1.2.MIME] S: * 26 FETCH (BODY[1.2.MIME] {62} S: Content-Transfer-Encoding: base64 S: Content-Type: video/mpeg; S: UID 24356 FLAGS (\Seen)) (i.e. an extra space before "UID" and change "{127}" to "{62}" The second example: > C: a122 UID FETCH 24359 BODY[1.2.MIME] typo: BODY[1.3.MIME] > S: * 26 FETCH (BODY[1.3.MIME] {127} {62} > S: Content-Transfer-Encoding: base64 > S: Content-Type: audio/G729; > S: UID 24359 FLAGS (\Seen)) Insert extra space before the "UID" 3). In section 2.3 > Clients SHOULD parse the value of mediaServers, (using either the > value.priv or value.shared: whichever is available and/or > appropriate), and contact a media server using one of the supplied > values. No particular preference order is implied by the ordering, I would prefer is the order specified by the server is the preferred order. > and it is left to the client implementor to decide the algorithm to > use when selecting the media server(s) to contact, and the selection > of alternates under failure conditions. 4). In section 2.5: > Similarly, the message may well be encoded with a content transfer > encoding such as base 64. typo: base-64 (and at least one more occurrence later in the same section) > Similarly, the message may well be encoded with a content transfer > encoding such as base 64. However, RFC 4240 does not include a > method for communicating content transfer encoding to the media > server as part of the announcement service, nor does the URLFETCH > command include a mechanism for retrieving message parts without > encoding (c.f. the BINARY [17] extension to IMAP). Would it be better if IMAP URL is extended to allow for binary content fetching? 5). In section 2.6 C: INVITE sip:annc@ms2.example.net; \ play=imap://joe@example.com/INBOX/;uid=24356/;section=1.2;\ expire=2006-12-19T16:39:\57-08:00;urlauth=anonymous:\ internal:238234982398239898a9898998798b987s87920; \ content-type=video/mpeg; \ content-transfer-encoding=base64 SIP/2.0 A curiosity question: does the content of the play parameter has to be surrounded by '"'? Content-Type: application/sdp Content-Length: 481 Here an in all other examples: extra empty line needed after the Content-Length line? 6). In Section 2.8: > If the media server is not configured as an authorized user of the > IMAP server, it MUST authenticate to the IMAP server using the LOGIN > command, with the username of "anonymous". > I believe this advice is out of date. draft-ietf-lemonade-rfc2192bis-04.txt recommends using SASL ANONYMOUS. > However, in this case, if > > the URL supplied in the 'play' parameter of the SIP INVITE specifies > an authorization of 'authuser', then the media server SHOULD NOT > attempt to contact the IMAP server, but SHOULD instead immediately > return a response code of 404 to the client with a reason phrase of > 'Not authorized to access resource' reason. > 7). Flow diagrams in section 2.9 don't show IMAP responses. This might be Ok. 8). In section 3: > This document proposes the use of URLAUTH "pawn tickets" to grant > access to message parts. The goal is for the media server to stream > these parts. INote that f one uses an anonymous pawn ticket, that > typo: Note that if one ... 9). In section 5: > media-servers = ms-tuple *(";" ms-tuple) > > host = astring > > If you mean the RFC 3501 "astring" here, then I don't think this is what you actually want, as it allows for IMAP literals and quoted strings. I suggest you use "host" non-terminal from RFC 3986. But if you follow this suggestion, be aware that "host" requires that IP addresses be enclosed in '[]'. If you don't want that, you need to find more suitable productions in RFC 3986. > port = nstring > > This is not what you want either, as this allows for "NIL", literal and quoted strings. I think you want to use the "port" non-terminal from RFC 3986. > ms-tuple = host ":" port (":" "authuser") > I think this should be: ms-tuple = host ":" port [":" "authuser"] as the last component is optional. Also note that section 2.3 says: For example, the client could discover a tuple of a media server address and an IMAP username, which allowed the client to generate a URL which was secure in that it could *only* be accessed by a specific (presumably trusted) media server. which seems to suggest that the optional part is a username. So you either need to fix the text in Section 2.3 or the ABNF. 10). There is no "IANA Considerations" section. One should be added and contain text about a METADATA annotation registration, as well as the registration of new SIP, etc. parameters. 11). In section 7: I believe the following 2 references are Informative, so they should be moved to a new section: > [13] Newman, C., "Message Submission BURL Extension", RFC 4468, > May 2006. > > [...] > [17] Nereberg, L., "IMAP4 Binary Content Extension", RFC 3516, > Apr 2003. > Also, I would like to suggest that the reference to RFC 2192 be updated to point to 2192bis. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Mar 27 08:21:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWAfT-0002md-Qw; Tue, 27 Mar 2007 08:20:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWAfS-0002mY-Os for lemonade@ietf.org; Tue, 27 Mar 2007 08:20:50 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWAfM-0007ZI-W4 for lemonade@ietf.org; Tue, 27 Mar 2007 08:20:50 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2RCKQks030636 for ; Tue, 27 Mar 2007 15:20:43 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Mar 2007 15:20:40 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Mar 2007 15:20:40 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] WGLC IMAP URL - update; comments Date: Tue, 27 Mar 2007 15:18:59 +0300 Message-ID: <4C38DC11F6B4FF4FAEA73E30DB5AA1573FDF7B@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] WGLC IMAP URL - update; comments thread-index: AcdsFCIQYInw1dgHEduf5gAWy4mm/wEQJJMQ References: From: To: X-OriginalArrivalTime: 27 Mar 2007 12:20:40.0151 (UTC) FILETIME=[5531A670:01C7706A] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070327152043-6A750BB0-3C508A49/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 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, here are some comments for -04: 1. Possible typo in "3. IMAP userinfo component" -> iuserinfo? Or, does = it mean userinfo of [URI-GEN]? 2. Clarification needed for section 3.1: in medias res. Assuming a top-down reading order, the terms "enc-user" and "iuserinfo" = have not been mentioned yet so the reader will have no clue what these = terms mean. I scrolled back up to section 2, but there are no such = things either. It might also be that there is something missing under = "3. IMAP userinfo component" because that section seems to be empty = (only a heading without text). Reading the ABNF clears this up, but ABNF = is at the end of the document. Perphaps moving the first paragraph of = section 3.2 to section 3? 3. Unclear reference in section 3.2 first paragraph: "The userinfo = component [URI-GEN] of an IMAP URI ..." [URI-GEN] is not the userinfo component, but [URI-GEN] does have a = userinfo component - could this be somehow captured? Suggest removing = [URI-GEN]. 4. Typo in section 3.2 first paragraph: "may contains" -> "may contain" 5. Caps use in section 3.2 first paragraph: "an IMAP user Name" 6. Is this really needed: "(Note that the "enc-user" also defines a = mailbox naming scope as described in section 3.1)" I mean if you keep = this paragrapsh here, it should not be needed because You should have = read that part already... Then again, if You moved it up to section 3, = then it should be either re-worded to cover all other sub-sections as = well. 7. Clarification needed in section 3.2 paragraph 1: "They are used in = the "LOGIN" or "AUTHENTICATE" commands after making the connection to = the IMAP server." What exactly does "They" refer to? 8. Extra "for" in section 3.2 paragraph 2: "in order to provide for = interoperability with" 9. Clarification needed in section 3.2 paragraph 3: Shouldn't this be = moved in from of the previous paragraph? That talks about what happens = when there no user name, so it would seem logical to use the user name = first, and then if there no user name, use anonymous instead. 10. Clarification needed in section 3.2 paragraph 5: "If no user name is = specified, one SHOULD be obtained from the mechanism or requested from = the user as appropriate." Iis this really a SHOULD? When AUTH is used I would not expect anonymous = to be used, therefore the user MUST have a user name. The next paragraph = seems to give some more info on this, but not really: it looks like a = client is allowed to send anonymous AUTH. 11. Clarification needed in section 3.2 paragraph 6: "This allows a URL = which grants read-write access to authorized users, and read-only = anonymous access to other users." What exactly does "this" refer to? 12. Wording change in section 3.2 paragraph 8: "care must be taken when = resolving a URL which requires or requests any sort of authentication" = Wouldn't there be an easier way to say this? 13. Wording change suggestion in section 3.2 paragraph 8: "If authentication credentials are supplied to the wrong server, it may = compromise the security of the user's account. The program resolving the = URL should make sure it meets at least one of the following criteria in = this case:" -> "Supplying authentication credentials to the wrong server may compromise = the security of the user's account, therefore the program resolving the = URI should meet at least one of the following criterias:" Note that I replaced URL with URI - do we want to do this for the rest = of the document? 14. Clarification needed in section 3.2 paragraph 9: "Note that user = entry of the URL may or may not count as a trusted source, depending on = the experience level of the user and site policy." How can the "experience level of the user" govern whether the source is = trusted? Sounds awfully wrong - things should be secure in any case. How does one calculate the "experience level of the user" and what = counts as a "safe" level? I thought bullet (3) would cover the user's mistakes. 15. Typo in section 3.2 paragraph 9: "SASL mechaninism" -> "SASL = mechanism" 16. Wording chage suggestion in section 3.2 paragraph 9: "An authentication mechanism is used which will not reveal information = to the server which could be used to compromise future connections." -> "Use an authentication mechanism with the server that does not reveal = any information that could be used to compromise future connections." 17. Section 3.2 paragraph 10. I do not think that such authentication = should be allowed. Why not force anonymous instead? Well, at least this = is hinted in the next paragraph with saying: "If a URL does not contain = a user name or authentication mechanism, then only an anonymous = connection may be re-used.", so which one is it? Allow omitting user = name or force anonymous? I would prefer the latter. Also, there is a bunch of line breaks after this paragraph - something = missing, or accidental insertion? 18. Question regarding section 3.2 last paragraph: the paragraph is = fine, but seeing the work in EAI group should we add some UTF8 = considerations here? Actually, make this comment general. I found = section 8 later on. Should section 8 be reference earlier (to avoid such = questions)? 19. Wording change suggestion in 3.3 paragraph 1: "An obvious limitation of using the same field for both purposes is that = the URL can only be resolved by the mailbox owner." -> "An obvious limitation of using the same field for both purposes is that = the URL can be resolved only by the mailbox owner." 20. Wording change suggesting in section 5, last paragraph: "If it is not present, the contents of the mailbox SHOULD be presented = by the program interpreting the URL." -> "If it is not present, all contents of the mailbox SHOULD be presented = by the program interpreting the URL." 21. Question about this requirement in section 6.1.1.2 paragraph 1: = "MUST be unpredictable" How can I verify that the random string that I have generated in = unpredictable? 22. Question for section 6.1.1.2 and 6.1.1.5. Can these strings include spaces and other "fun stuff" that might break = an IMAP URI? I read no restriction here. Similarly, any considerations = for UTF-8 here (I mean 128bit means something else using US-ASCII and = UTF8)? I would expect at least a statement that the limitations = described in [URLAUTH] apply here as well, no additional restrictions. 23. Clarification needed in section 6.1.2 paragraph 4. What is = "submit+", what is a "access identifier prefix" and what is a "userid" - = these have not been mentioned before, and these are not in the ABNF = either. Same question for "user+", "authuser" in the following paragraphs. 24. Re-location proposal for section 6.1.2 last paragraph: shouldn't = this be in section 6.1.1.5? 25. General comment to section 6: an example or two would be nice. 26. Question on section 7.2 paragraph 1. Why is it a "SHOULD NOT"? I = mean what is the exception for? Wouldn't a "MUST NOT" be better? 27. "Funny" line breaks in section 10.1 28. The last page seems to be blank. I understand quite a few of these might look as knit-picking, but I = would like to make sure that the document will be easy to consume for = the beginners as well. Thank You. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 =20 >-----Original Message----- >From: ext Eric Burger [mailto:eburger@bea.com]=20 >Sent: 22 March, 2007 01:54 >To: lemonade@ietf.org >Subject: [lemonade] WGLC IMAP URL - update > >http://www.ietf.org/internet-drafts/draft-ietf-lemonade-rfc2192 >bis-04.txt > >Work Group Last Call ends April 15. > >_______________________________________________________________________ >Notice: This email message, together with any attachments,=20 >may contain information of BEA Systems, Inc., its=20 >subsidiaries and affiliated entities, that may be=20 >confidential, proprietary, copyrighted and/or legally=20 >privileged, and is intended solely for the use of the=20 >individual or entity named in this message. If you are not the=20 >intended recipient, and have received this message in error,=20 >please immediately return this by email and then delete it. > >_______________________________________________ >lemonade mailing list >lemonade@ietf.org >https://www1.ietf.org/mailman/listinfo/lemonade >Supplemental Web Site: >http://www.standardstrack.com/ietf/lemonade > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Mar 27 11:07:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWDGZ-0006Tc-LS; Tue, 27 Mar 2007 11:07:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWDGY-0006TW-PY for lemonade@ietf.org; Tue, 27 Mar 2007 11:07:18 -0400 Received: from [2001:838:378:0:2a0:d2ff:fe1b:110f] (helo=turner.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWDGW-0001B1-J5 for lemonade@ietf.org; Tue, 27 Mar 2007 11:07:18 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 7FEA1498012; Tue, 27 Mar 2007 16:07: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 28686-07; Tue, 27 Mar 2007 16:06:57 +0100 (BST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:838:378:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id B2C1D498011; Tue, 27 Mar 2007 16:06:57 +0100 (BST) Subject: Re: [lemonade] WGLC streaming References: <4608EF81.5050401@isode.com> In-Reply-To: <4608EF81.5050401@isode.com> MIME-Version: 1.0 Message-Id: <6000.1175008017.686117@peirce.dave.cridland.net> Date: Tue, 27 Mar 2007 16:06:57 +0000 From: Dave Cridland To: Neil Cook Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: Debian amavisd-new at turner.dave.cridland.net X-Spam-Score: -2.8 (--) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 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 I've skimmed the document, too. On Tue Mar 27 11:18:41 2007, Alexey Melnikov wrote: > Eric Burger wrote: > >> This is the announcement for the Work Group Last Call on the >> Streaming Media >> draft: >> http://www.ietf.org/internet-drafts/draft-ietf-lemonade-streaming-01.txt >> >> Work group last call ends April 8. > > The document is in a pretty good shape. However examples contain > several minor bugs and there are also some issues with IANA > registrations as well as with Normative References. My detailed > comments are below: > > 1). Almost all IMAP examples use trailing '\' to specify line > continuations (and the examples don't use them consistently). This > is > unusual for IMAP and not specified in the conventions. I suggest > just > removing them. > > Yes, this would be good. > 2). In Section 2.2: > > > > > > The first example: > >> C: a122 UID FETCH 24356 BODY[1.2.MIME] >> S: * 26 FETCH (BODY[1.2.MIME] {127} >> S: Content-Transfer-Encoding: base64 >> S: Content-Type: video/mpeg; >> S: UID 24356 FLAGS (\Seen)) > > Should be: > > C: a122 UID FETCH 24356 BODY[1.2.MIME] > S: * 26 FETCH (BODY[1.2.MIME] {62} > S: Content-Transfer-Encoding: base64 > S: Content-Type: video/mpeg; > S: UID 24356 FLAGS (\Seen)) > > (i.e. an extra space before "UID" and change "{127}" to "{62}" > > Actually, no... It *should* be using BODYSTRUCTURE to find the media type - by the time you know that section 1.2 (or 1.2.MIME) exists, you already know the media type of the part, and its encoding. > 3). In section 2.3 > >> Clients SHOULD parse the value of mediaServers, (using either >> the >> value.priv or value.shared: whichever is available and/or >> appropriate), and contact a media server using one of the >> supplied >> values. No particular preference order is implied by the >> ordering, > > I would prefer is the order specified by the server is the > preferred order. > > I'm not sure it matters overmuch. It might be that the client can identify which server is closest better than the server. It really depends upon what we mean by "preferred". >> Similarly, the message may well be encoded with a content >> transfer >> encoding such as base 64. However, RFC 4240 does not include a >> method for communicating content transfer encoding to the media >> server as part of the announcement service, nor does the >> URLFETCH >> command include a mechanism for retrieving message parts without >> encoding (c.f. the BINARY [17] extension to IMAP). > > Would it be better if IMAP URL is extended to allow for binary > content > fetching? > > I think that might well be neater, although it depends on which extension requires more work. > 7). Flow diagrams in section 2.9 don't show IMAP responses. This > might > be Ok. > > I think it'd be clearer if they were there. (Again, this is FETCH BODY[MIME], rather than FETCH BODYSTRUCTURE). > 9). In section 5: > I think this should be: > > ms-tuple = host ":" port [":" "authuser"] > > as the last component is optional. > > I'm concerned with IPv6 behaviour with this production. I'm also thinking that perhaps a URI form would be more suitable, as it allows for more expansion capability. Assuming, that is, that these media services have URIs to them. > 10). There is no "IANA Considerations" section. One should be added > and > contain text about a METADATA annotation registration, as well as > the > registration of new SIP, etc. parameters. > > The Metadata annotation registration is in 2.3, but yes, it needs to be moved. Further comments - and please note that the majority of the SIP stuff goes shooting over my head: In the Security Considerations section, there seems to be a sudden lack of references. In particular, sips, SIP, RFC4240, RFC4722, and S/MIME all lack references (although they're in the Normative References section). The IMAP base specification, and URLAUTH, also has recommendations concerning encryption layers in conjunction with authorized URLs - you may find it better to simply include the security considerations in both RFC3501 and URLAUTH by reference. Typically, you'd do this with this text replacing the first two paragraphs: "This document proposes the use of URLAUTH [URLAUTH] "pawn tickets", received over IMAP [IMAP], and transmitted over SIP [SIP], possibly within the MSCML payload of IVR [RFC4722]. As such, the security considerations in all these documents apply to this specification. In summary, as the authorized URLs may grant access to data, implementors of this specification need to consider the following:" Or something similar, anyway. Section 4: The Great DRM Can Of Worms: If I were a lawyer, then aside from the fact I'd never read a technical document, I'd be concerned with the phrase "[...] also implicitly gives the creator [of the URLAUTH authorized URL] the right to pass that reference on to any third party it desires." This phrase implies that the document authors believe that transmission of media via email grants the recipient rights to redistribution, which is probably not the view of most people, DRM-fans or not. Without delving into the precise legal terminology required, I'd say that the use of URLAUTH in this specification is believed to be persuant with, and used only for, the execution of those rights to be expected when media is sent via traditional internet messaging, and causes no duplication of media content which is not essentially provided by the action of sending the message; that is, the use of the content for downloading and viewing, which *is* implicitly granted by the sender of the message, in as much as the sender has the right to grant such rights. I might also state that any DRM required needs to be implemented within the media type, and moreover to take into account that the use of this specification requires a third party to access the media content in order to provide efficient private streaming. I'm very much against implementing DRM checks in URLAUTH, which would require me to maintain a somehow perfect list of media types which require DRM checks, and presumably open my employer to DRM related lawsuits should I fail to comply. As a final comment, I believe this specification needs careful review by a suitable working group (or groups) within the SIP community - could I suggest that the Chairs, or Secretary, arrange this with the RAI review team, or RAI ADs? 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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Mar 27 11:24:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWDXQ-0006uA-9L; Tue, 27 Mar 2007 11:24:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWDXP-0006u2-Is for lemonade@ietf.org; Tue, 27 Mar 2007 11:24:43 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWDXO-0004Z4-6A for lemonade@ietf.org; Tue, 27 Mar 2007 11:24:43 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 27 Mar 2007 16:24:28 +0100 Message-ID: <46093703.2000207@isode.com> Date: Tue, 27 Mar 2007 16:23:47 +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] WGLC streaming References: <4608EF81.5050401@isode.com> <6000.1175008017.686117@peirce.dave.cridland.net> In-Reply-To: <6000.1175008017.686117@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: 8b431ad66d60be2d47c7bfeb879db82c Cc: 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: >> 2). In Section 2.2: >> >> The first example: >> >>> C: a122 UID FETCH 24356 BODY[1.2.MIME] >>> S: * 26 FETCH (BODY[1.2.MIME] {127} >>> S: Content-Transfer-Encoding: base64 >>> S: Content-Type: video/mpeg; >>> S: UID 24356 FLAGS (\Seen)) >> >> Should be: >> >> C: a122 UID FETCH 24356 BODY[1.2.MIME] >> S: * 26 FETCH (BODY[1.2.MIME] {62} >> S: Content-Transfer-Encoding: base64 >> S: Content-Type: video/mpeg; >> S: UID 24356 FLAGS (\Seen)) >> >> (i.e. an extra space before "UID" and change "{127}" to "{62}" > > Actually, no... It *should* be using BODYSTRUCTURE to find the media > type - by the time you know that section 1.2 (or 1.2.MIME) exists, you > already know the media type of the part, and its encoding. I thought about this too. But at least the current example needs to be fixed. [...] >> 9). In section 5: > >> I think this should be: >> >> ms-tuple = host ":" port [":" "authuser"] >> >> as the last component is optional. > > I'm concerned with IPv6 behaviour with this production. Good point. > I'm also thinking that perhaps a URI form would be more suitable, as > it allows for more expansion capability. Assuming, that is, that these > media services have URIs to them. That would be fine with me, however this would require some changes to how ms-tuples are delimited. Also this would mean that the username is explicit, which might be a good thing anyway _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Mar 27 11:43:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWDop-0006dO-Vw; Tue, 27 Mar 2007 11:42:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWDoo-0006dH-GH for lemonade@ietf.org; Tue, 27 Mar 2007 11:42:42 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWDon-00006j-3b for lemonade@ietf.org; Tue, 27 Mar 2007 11:42:42 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l2RFgO9o016583 for ; Tue, 27 Mar 2007 10:42:40 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.10]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Mar 2007 10:42:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [lemonade] WGLC streaming Comments Date: Tue, 27 Mar 2007 10:42:14 -0500 Message-ID: <89017B166CB7E140BA80577FF744AE19924EAE@ILEXC2U01.ndc.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC streaming - update thread-index: AcdsFDUjc3sY0tgHEduf5gAWy4mm/wBQjzvw From: "Vaudreuil, Greg M \(Greg\)" To: X-OriginalArrivalTime: 27 Mar 2007 15:42:36.0097 (UTC) FILETIME=[8ADC4B10:01C77086] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 Resending... The policy filter ate my message. Greg V. 2nd paragraph of section 1. SIP does not stream media! Meda can be streamed using RTP or RTSP. SIP invites such. Wordsmithing needed text following figure 1. Bullet 0 should make it clear how the client knows whether there is a media server and whether the media can be streamed. Maybe just a forward pointer to section 2.3x General comment. I'm not comfortable with the amount of "go fish" in the protocol. The server is not required to support both IVR and NETANN protocols, so the client is instructed to first try one, and if it fails, then try the other protocol. Further, the client given a choice of separate audio and video media servers (for example) may have to play go fish across the set. It would be better to specify at some useful level (top-level content-type would be sufficient for my needs) the capabilities of the media server in the IMAP metadata, and to require the superset IVR service. Is the idea that media server vendors don't want to implement IVR to be LEMONADE compliant? They already have a bunch of work to support IMAP and the expanded SIP headers (and corresponding CTE processing).=20 Content-transfer-encoding. I should be more up-to-date on IMAP binary... I don't have a version in my cache and this is an airplane message. But could we not simplify things by requiring the media server to always use a binary fetch and requring the IMAP server to strip the CTE to binary? Saves a SIP extension and teaching media servers about CTE. IMAP server already has to do binary for LEMONADE... My memory suggests we required the ability for the server to unwrap CTE's for client-server BW savings. Section 3. =20 Why should a client trust a particular media server? "Bad news, your lab results show you are....." The client authenticates to the submission server, so there is some reasonable expectation that the server is authorized to see message content. There does not seem to be any equivalent for the media server. Maybe there is more trust if you found the media server identity in METADATA from the IMAP server? I don't know if this needs a fix, but it needs a mention in section 3. Section 4. This discussion seems to be limited to Forward-Lock DRM. Crypto-based DRM may use separate solutions that are between the media server and the client, where the client provides necessary gunk to unlock the blob fetched by the media server. Such solutions don't require any extension to URLAUTH. Greg V. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Mar 27 12:33:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWEbk-0007sq-NH; Tue, 27 Mar 2007 12:33:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWEbj-0007sJ-NR for lemonade@ietf.org; Tue, 27 Mar 2007 12:33:15 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWEbh-00038t-8Q for lemonade@ietf.org; Tue, 27 Mar 2007 12:33:15 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2RGW6jC029823 for ; Tue, 27 Mar 2007 09:33:12 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2RGW6XH004995 for ; Tue, 27 Mar 2007 09:33:12 -0700 Received: from 172.24.30.73 ([172.24.30.73]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Tue, 27 Mar 2007 16:31:29 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Tue, 27 Mar 2007 12:28:07 -0400 From: Eric Burger To: "lemonade@ietf.org" Message-ID: Thread-Topic: Interim Meeting Thread-Index: AcdwjOabJTIVVNyAEdutGwAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.5 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [lemonade] Interim Meeting 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 discussed at IETF 68, we will have an interim meeting between now and IETF 69 in Chicago. The proposal is to have it the week of 14 May 2007 in Toronto, Ontario. Just as a surprise, we will NOT have it at the Nortel facility, but at the BEA facility, which is right at the airport. We will have live Jabber chat, a voice conference bridge, and iChat available. As always, physically being there is not required. Please RSVP on the following queries. The expectation is the meetings will start at noon Eastern (local) Time on the first day and end around noon on the second day. We may move that either way a few hours, depending on if there is a preponderance of people coming from Europe (starting at 1pm or 2pm opens up a ton of flight options) or the West Coast (starting at 10am works, as they may have to come out the night before). Query #1: Presence [ ] I will attend in person [ ] I will participate electronically [ ] I will not participate [ ] Other (please explain to Eric or Glenn, e.g., in person 16th only) ____________________ Query #2: Dates Rank order: 1, 2, 3 or X=cannot do at all [ ] Tuesday 15 May - Wednesday 16 May [ ] Wednesday 16 May - Thursday 17 May [ ] Thursday 17 May - Friday 18 May [ ] Nothing works for me Query #3: Start Times Rank order: 1, 2, 3, 4 [ ] Noon ET [ ] 2pm ET [ ] 3pm ET [ ] 10am ET [ ] I don't care Thanks! Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Mar 28 05:52:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWUpE-0002ik-7T; Wed, 28 Mar 2007 05:52:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWUpB-0002iT-VA for lemonade@ietf.org; Wed, 28 Mar 2007 05:52:13 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWUp5-0002pG-5v for lemonade@ietf.org; Wed, 28 Mar 2007 05:52:13 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2S9pkUe031468 for ; Wed, 28 Mar 2007 12:52:04 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Mar 2007 12:51:51 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Mar 2007 12:51:50 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] WGLC streaming - update; comments Date: Wed, 28 Mar 2007 12:50:10 +0300 Message-ID: <4C38DC11F6B4FF4FAEA73E30DB5AA1573FE64D@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] WGLC streaming - update; comments thread-index: AcdsFDUjc3sY0tgHEduf5gAWy4mm/wE9vwEw References: From: To: X-OriginalArrivalTime: 28 Mar 2007 09:51:50.0962 (UTC) FILETIME=[B5654920:01C7711E] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070328125204-77D07BB0-030CC811/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 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, here are some additional comments to this draft: 1. Title. Would it be OK to remove "Messaging" from the title? One might = think MMS here. 2. Conventions: "The key words "MUST", "MUST NOT", "SHOULD", "SHOULD = NOT", and "MAY" in this document are to be interpreted as defined in RFC = 2119 [8]." Interestingly the list of these key words seems to vary from draft to = draft (take a look at draft-ietf-lemonade-rfc2192bis-04). Isn't there a = consolidated list that could be in every draft? 3. Section 1, paragraph one: "Email clients on resource and/or network = constrained devices, such a mobile phones, may have difficulties in = retrieving and/or storing large attachments received in a message. For = example, on a poor network link, the latency required to download the = entire attachment may not be acceptable to the user." Typo: "such a" -> "such as" I am not sure how streaming helps network contstrained devices since = streaming might be more network-demanding in some cases than a slow = fetch. I thought the whole reason of doing streaming was: not to = download and store stream-able attachments at all. I've seen streaming = on slow networks, and I can tell that I would rather wait longer to = retrieve it slowly in the background without streaming. Looking at the = phone and waiting for new frames to be drawn is just: bad. Even today, = in my office where there is gigabits of bandwidth I still have to wait = for some streams for pre-load more than half of the movies (not because = there is a network limit, not because there is a client limit, but = because there are limitations on the server.) Therefore, I suggest = removing any hints about doing this because there is not enough = bandwidth. 4. Section 1, paragraph two: "Streaming the media to the device = addresses both the latency issue, since the client can start playing the = media immediately..." Who are we kidding here? There is no way to start playing without = receiving data first. (Unless of course we play something else than what = the user has asked for.) 5. Typo in Section 1, paragraph two: "A tradeoff" -> "A trade-off" 6. Section 1, paragrapth two: "A tradeoff is that the media cannot be = viewed/played when the device is offline." Unless of course it has been downloaded already (e.g. he user has viewed = is once already so it's cached locally). 7. Wording change suggestion in Section 2.1, paragraph two: "in order to accommodate the passing of a content transfer encoding = parameter." -> "in order to accommodate passing a content transfer encoding parameter." 8. Question regarding Figure 1: Shouldn't all arrows be double-headed? 9. Bullet 6. below figure 1: "The media server or the client terminates the SIP session." SIP session? I thought it would be RTP, MSRP, but SIP? SIP is not a = transport protocol. Paragraph 1 in 2.4 says RTP. 10. Section 2.2 paragraph 1: "will be attempted" -> "is required"? I = mean the next paragraph talks about it that way. 11. Section 2.2 paragraph 2: ";EXPIRE=3D" Isn't there a = "nicer" way to do this? This requires "funny" calculations on the = client: current time (what if it's not valid?), current time zone (what = if it's not valid), daylight saving setting (what if it's not valid)? A = period (like: 1 hour period from now on) or an access count (like: 1 = access attempt only) would be more comfy. 12. Section 2.2 paragraph 3: "the use of anonymous URLAUTH authorized = URLs" shouldn't we disable anonymous access completely? It's an = attachment in my email after all, which might very well contain strictly = confidential info. I suspect that streaming will not be used when the = smallest chance to leak info exists. 13. Section 2.2 paragraph 4: "SHOULD be 'authuser'" authuser being what? = There is no info about this (not in syntax either). Also, I think that = this should be a MUST and forbid anonymous access. 14. Extra space in section 2.3 paragraph 3: "pawn- ticket" 15. Wording change suggestion in 2.3 paragraph 3: "For example, the client could discover a tuple of a media server = address and an IMAP username, which allowed the client to generate a URL = which was secure in that it could *only* be accessed by a specific = (presumably trusted) media server." -> "For example, the client could discover a tuple of a media server = address and an IMAP username, which allows the client to generate a = secure URL that could *only* be accessed by a specific (presumably = trusted) media server." 16. Same as comment #1 for the IANA registration in section 2.3: = "Description: Defined in Streaming Multimedia Messaging Attachments" : = remove the word "Messaging" - foe some it might mean MMS. 17. Typo (?) in 2.3 last paragraph: "left to the client implementor to = decide" isn't is "implementer"? 18. Wording change suggestion in 2.4 paragraph 3: "then if the client supports it," -> "but the client supports it," 19. Wording change suggestion in 2.5 paragraph 4: "Similarly, the message may well be encoded with a content transfer = encoding such as base 64" -> "Similarly, the message may be encoded with a content transfer encoding = such as BASE64 [BASE64]" 20. Word missing in 2.5 second last paragraph: "If the receives a 200 OK = response" 21. 2.5 last paragraph: 404 does not seem to be sufficient - a single status code covering all = possible errors is not very useful. Is there any way to indicate to the = client what very wrong (really)? 22. Wording change suggesion in 2.6 paragraph 1: "it is felt worthwhile to give some examples " -> "it is worth giving some examples" 23. Wording change suggestion in 2.6 paragraph 2: "In the below example" -> "In the example below" 24. Section 2.6, paragraph 3: "The client and server now know from the = SDP advertised by both client and server that communication must be = using the subset of audio codecs supported by both client and server (in the example SDP, it is = clear that the server does not support any video codecs)." I think they knew this without having to perform any communication - = what they gain here is that they will both know the smallest common set. 25. Section 2.6 paragraph 4: " request" What is it? (No = previous mentioning if this, at least a reference would be nice). 26. Wording change suggestion 2.7 paragraph 2: "establish" -> = "discover". 27. Question on 2.7 paragraph 2: "must generate a SIP INFO request " = shouldn't this be a MUST (upper-case)? 28. Question on 2.7 paragraph 4: shoudn't "playcollect" be always = ""? 29. Wording change suggestion in 2.7 paragraph 12: "The following gives an example dialog between" -> "The following example shows a dialog between" 30. Question on Section 2.8 paragraph 2: Could we change that "SHOULD" = to a "MUST"? Or, how will the IMAP server know the client policy? Same = question for "SHOULD NOT"->"MUST NOT" in the next paragraph. 31. Typos in Section 3 paragraph 1: "INote that f one" -> "Note that = one" 32. Typo (?) in section 3 paragraph 2: "implementors" -> "implementers"? = I am not sure. I did not review any of the examples. Thanks for fixing. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 =20 >-----Original Message----- >From: ext Eric Burger [mailto:eburger@bea.com]=20 >Sent: 22 March, 2007 01:54 >To: lemonade@ietf.org >Subject: [lemonade] WGLC streaming - update > >This is the announcement for the Work Group Last Call on the=20 >Streaming Media >draft: >http://www.ietf.org/internet-drafts/draft-ietf-lemonade-streami >ng-01.txt > >Work group last call ends April 8. > >_______________________________________________________________________ >Notice: This email message, together with any attachments,=20 >may contain information of BEA Systems, Inc., its=20 >subsidiaries and affiliated entities, that may be=20 >confidential, proprietary, copyrighted and/or legally=20 >privileged, and is intended solely for the use of the=20 >individual or entity named in this message. If you are not the=20 >intended recipient, and have received this message in error,=20 >please immediately return this by email and then delete it. > >_______________________________________________ >lemonade mailing list >lemonade@ietf.org >https://www1.ietf.org/mailman/listinfo/lemonade >Supplemental Web Site: >http://www.standardstrack.com/ietf/lemonade > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Mar 28 06:57:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWVpU-0003gs-0t; Wed, 28 Mar 2007 06:56:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWVpS-0003gn-P7 for lemonade@ietf.org; Wed, 28 Mar 2007 06:56:34 -0400 Received: from [2001:838:378:0:2a0:d2ff:fe1b:110f] (helo=turner.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWVpR-0006zL-0N for lemonade@ietf.org; Wed, 28 Mar 2007 06:56:34 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 1F85E498012; Wed, 28 Mar 2007 11:56:26 +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 10450-03; Wed, 28 Mar 2007 11:56:19 +0100 (BST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:838:378:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id AE1A4498011; Wed, 28 Mar 2007 11:56:19 +0100 (BST) Subject: RE: [lemonade] WGLC streaming - update; comments References: <4C38DC11F6B4FF4FAEA73E30DB5AA1573FE64D@esebe199.NOE.Nokia.com> In-Reply-To: <4C38DC11F6B4FF4FAEA73E30DB5AA1573FE64D@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Message-Id: <29159.1175079379.528182@peirce.dave.cridland.net> Date: Wed, 28 Mar 2007 11:56:19 +0000 From: Dave Cridland To: "Zoltan.Ordogh@nokia.com" Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: Debian amavisd-new at turner.dave.cridland.net X-Spam-Score: -2.4 (--) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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. On Wed Mar 28 10:50:10 2007, Zoltan.Ordogh@nokia.com wrote: > Hi all, > here are some additional comments to this draft: > 1. Title. Would it be OK to remove "Messaging" from the title? One > might think MMS here. > > Interesting point - maybe replace "Messaging" with "Internet Mail", perhaps? > 2. Conventions: "The key words "MUST", "MUST NOT", "SHOULD", > "SHOULD NOT", and "MAY" in this document are to be interpreted as > defined in RFC 2119 [8]." > Interestingly the list of these key words seems to vary from draft > to draft (take a look at draft-ietf-lemonade-rfc2192bis-04). Isn't > there a consolidated list that could be in every draft? > > Yes, the correct boilerplate phrase is listed in RFC2119 itself. > 11. Section 2.2 paragraph 2: ";EXPIRE=" Isn't there a > "nicer" way to do this? This requires "funny" calculations on the > client: current time (what if it's not valid?), current time zone > (what if it's not valid), daylight saving setting (what if it's not > valid)? A period (like: 1 hour period from now on) or an access > count (like: 1 access attempt only) would be more comfy. > > This is stipulated by URLAUTH, rather than this specification. > 12. Section 2.2 paragraph 3: "the use of anonymous URLAUTH > authorized URLs" shouldn't we disable anonymous access completely? > It's an attachment in my email after all, which might very well > contain strictly confidential info. I suspect that streaming will > not be used when the smallest chance to leak info exists. > > The general idea is that this allows arbitrary media servers to be used - how likely or desirable this is is a matter of opinion, but the mechanism exists. It doesn't grant "everyone" access, though, only "anyone" - that is, the specific entities that are given the anonymous URLAUTH authorized URLs. > 13. Section 2.2 paragraph 4: "SHOULD be 'authuser'" authuser being > what? There is no info about this (not in syntax either). Part of URLAUTH. > 30. Question on Section 2.8 paragraph 2: Could we change that > "SHOULD" to a "MUST"? Or, how will the IMAP server know the client > policy? Same question for "SHOULD NOT"->"MUST NOT" in the next > paragraph. > > That seems reasonable, but I suspect there's text in either URLAUTH or BURL which can be duplicated for both cases. 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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Mar 28 12:47:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWbIl-0002EO-95; Wed, 28 Mar 2007 12:47:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWbIk-0002EE-6D for lemonade@ietf.org; Wed, 28 Mar 2007 12:47:10 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWbIi-0007Kt-OI for lemonade@ietf.org; Wed, 28 Mar 2007 12:47:10 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 28 Mar 2007 17:46:48 +0100 Message-ID: <460A7A38.5000304@isode.com> Date: Wed, 28 Mar 2007 15:22:48 +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: Lemonade WG 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 Subject: [lemonade] Open Issues with IMAP CONVERT 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, I've done some work on updating the CONVERT draft. I found more issues that need to be discussed. Some of the major issues are listed below: 1). Do we want to allow for conversion of non-leaf bodyparts? E.g. multipart/related to application/pdf? I am slightly in favor of allowing this, even though I don't think that any server should be required to perform such conversions. On a related note: should we allow to convert to non-leaf bodyparts? 2). draft -05 currently allows for default conversion (i.e. "just convert to any media type, you know best"). I don't think this should be allowed and I suggest removing this feature from ABNF. Somewhat related to this: is the server allowed to convert to image/png instead of image/jpeg when .STRICT suffix to CONVERT is not specified? (I don't think this should be allowed) 3). There is one big issue surrounding INFORMATIONLOSS. I will publish an updated draft shortly, but it will not tackle this issue. I will try to address the issue in the subsequent revision. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Mar 29 03:31:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWp5z-0004RF-JD; Thu, 29 Mar 2007 03:30:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWp5x-0004R9-ON for lemonade@ietf.org; Thu, 29 Mar 2007 03:30:53 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWp5v-0002fD-5D for lemonade@ietf.org; Thu, 29 Mar 2007 03:30:53 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2T7UXvh018057; Thu, 29 Mar 2007 10:30:49 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Mar 2007 10:30:38 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Mar 2007 10:30:38 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Open Issues with IMAP CONVERT Date: Thu, 29 Mar 2007 10:28:57 +0300 Message-ID: <4C38DC11F6B4FF4FAEA73E30DB5AA1573FED5D@esebe199.NOE.Nokia.com> In-Reply-To: <460A7A38.5000304@isode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Open Issues with IMAP CONVERT thread-index: AcdxWVDd6gUWyr+pQLiBjBKFmwwQoQAeL7Tw References: <460A7A38.5000304@isode.com> From: To: , X-OriginalArrivalTime: 29 Mar 2007 07:30:38.0300 (UTC) FILETIME=[25B569C0:01C771D4] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) 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 Alexei, >1). Do we want to allow for conversion of non-leaf bodyparts? E.g.=20 >multipart/related to application/pdf? > > I am slightly in favor of allowing this, even though I don't=20 >think that any server should be required to perform such conversions. > >On a related note: should we allow to convert to non-leaf bodyparts? Support++ >2). draft -05 currently allows for default conversion (i.e.=20 >"just convert to any media type, you know best"). >I don't think this should be allowed and I suggest removing=20 >this feature from ABNF. OMA has a requirement for the server making the decision (based on some capability information about the client) and I think this is our "hook" to do that. Removing it would complicate our lives in OMA. I would like to ask You to re-consider this proposal. >Somewhat related to this: is the server allowed to convert to=20 >image/png instead of image/jpeg when .STRICT suffix to CONVERT=20 >is not specified? (I don't think this should be allowed) I don't think it should be allowed. In fact, I think STRICT should be removed and if the server cannot fulfill the convert then it should fail the request. I think mosts client would add it there anyway because they want exactly what they asked for - and nothing else. If clients don't want to convert to some specific type, they will let the server decide the best conversion. >3). There is one big issue surrounding INFORMATIONLOSS. I will=20 >publish an updated draft shortly, but it will not tackle this=20 >issue. I will try to address the issue in the subsequent revision. Could You elaborate this, please? Thank You. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Mar 29 08:23:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWteV-0001D8-7N; Thu, 29 Mar 2007 08:22:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWcXN-0000kg-MA for lemonade@ietf.org; Wed, 28 Mar 2007 14:06:21 -0400 Received: from serendipity.palo-alto.ca.us ([66.92.2.87] helo=mail.serendipity.cx) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWcXG-0005Gw-UB for lemonade@ietf.org; Wed, 28 Mar 2007 14:06:21 -0400 Received: from serendipity.palo-alto.ca.us (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with SMTP id 6B590601D8B1; Wed, 28 Mar 2007 11:06:48 -0700 (PDT) Date: Wed, 28 Mar 2007 18:06:19 -0000 To: "Alexey Melnikov" , "Barry Leiba" From: "Aaron Stone" X-Mailer: TWIG 2.8.2 Message-ID: In-Reply-To: <460A7F10.9000407@isode.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-Mailman-Approved-At: Thu, 29 Mar 2007 08:22:49 -0400 Cc: Lemonade WG , ietf-mta-filters@imc.org Subject: [lemonade] Re: Comments on draft-ietf-lemonade-imap-sieve-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 On Wed, Mar 28, 2007, Alexey Melnikov said: [snip everything else] > Other comments: > > I suggest you add the following requirement: 'IMAP Sieve interpreters > SHOULD support Sieve "environment" test"'. And I would be Ok with it > being a MUST. +1. I think that IMAP Sieve should probably require a fairly good profile of Sieve extensions, particularly those which allow the script to be smart about the context it is running in. Aaron _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Mar 29 09:56:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWv6y-0000TS-JO; Thu, 29 Mar 2007 09:56:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWv6x-0000TN-Ov for lemonade@ietf.org; Thu, 29 Mar 2007 09:56:19 -0400 Received: from noware.co.uk ([82.153.134.193] helo=mail.noware.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWv6u-0000iW-Cd for lemonade@ietf.org; Thu, 29 Mar 2007 09:56:19 -0400 Received: by mail.noware.co.uk (Postfix, from userid 1008) id ABFD537B3; Thu, 29 Mar 2007 14:51:31 +0100 (BST) X-CMAE-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=q3I4JV4IPExTGtmpY94A:9 a=vo77Arhgfe6cCD5PvQ0A:7 a=uINbAkE3OyO3NsnWD9yN98DXbEwA:4 Received: from [172.22.1.156] (unknown [72.5.239.5]) by mail.noware.co.uk (Postfix) with ESMTP id EEB0536EC; Thu, 29 Mar 2007 14:51:26 +0100 (BST) In-Reply-To: <4608EF81.5050401@isode.com> References: <4608EF81.5050401@isode.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <19EF7922-B37F-41DB-98AF-3F8F22FD06CE@noware.co.uk> Content-Transfer-Encoding: 7bit From: Neil Cook Subject: Re: [lemonade] WGLC streaming Date: Thu, 29 Mar 2007 14:55:52 +0100 To: Alexey Melnikov X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 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 Alexey, thanks for the comments, I was getting worried nobody has read it, and I knew it needed thorough review. Responses below: Neil. On 27 Mar 2007, at 11:18, Alexey Melnikov wrote: > Eric Burger wrote: > >> This is the announcement for the Work Group Last Call on the >> Streaming Media >> draft: >> http://www.ietf.org/internet-drafts/draft-ietf-lemonade- >> streaming-01.txt >> >> Work group last call ends April 8. > > The document is in a pretty good shape. However examples contain > several minor bugs and there are also some issues with IANA > registrations as well as with Normative References. My detailed > comments are below: > > 1). Almost all IMAP examples use trailing '\' to specify line > continuations (and the examples don't use them consistently). This is > unusual for IMAP and not specified in the conventions. I suggest just > removing them. Ok. > 2). In Section 2.2: > > The first example: > >> C: a122 UID FETCH 24356 BODY[1.2.MIME] >> S: * 26 FETCH (BODY[1.2.MIME] {127} >> S: Content-Transfer-Encoding: base64 >> S: Content-Type: video/mpeg; >> S: UID 24356 FLAGS (\Seen)) > > Should be: > > C: a122 UID FETCH 24356 BODY[1.2.MIME] > S: * 26 FETCH (BODY[1.2.MIME] {62} > S: Content-Transfer-Encoding: base64 > S: Content-Type: video/mpeg; > S: UID 24356 FLAGS (\Seen)) > > (i.e. an extra space before "UID" and change "{127}" to "{62}" ok. > The second example: > >> C: a122 UID FETCH 24359 BODY[1.2.MIME] > > typo: BODY[1.3.MIME] > >> S: * 26 FETCH (BODY[1.3.MIME] {127} > > {62} > >> S: Content-Transfer-Encoding: base64 >> S: Content-Type: audio/G729; >> S: UID 24359 FLAGS (\Seen)) > > Insert extra space before the "UID" > Ok > 3). In section 2.3 > >> Clients SHOULD parse the value of mediaServers, (using either the >> value.priv or value.shared: whichever is available and/or >> appropriate), and contact a media server using one of the supplied >> values. No particular preference order is implied by the >> ordering, > > I would prefer is the order specified by the server is the > preferred order. > As Dave mentioned, the client may know better. Perhaps I should that that the server lists the preferred order, but the client may choose to ignore the order if it knows better. >> and it is left to the client implementor to decide the >> algorithm to >> use when selecting the media server(s) to contact, and the >> selection >> of alternates under failure conditions. > > 4). In section 2.5: > >> Similarly, the message may well be encoded with a content transfer >> encoding such as base 64. > > typo: base-64 > > (and at least one more occurrence later in the same section) > ok >> Similarly, the message may well be encoded with a content transfer >> encoding such as base 64. However, RFC 4240 does not include a >> method for communicating content transfer encoding to the media >> server as part of the announcement service, nor does the URLFETCH >> command include a mechanism for retrieving message parts without >> encoding (c.f. the BINARY [17] extension to IMAP). > > Would it be better if IMAP URL is extended to allow for binary content > fetching? Well this is a tricky one. I would actually prefer it if it was, because it means I wouldn't have to extend both netann and mscml with c-t-e parameters. What is the likelihood of getting IMAP URL modified to allow binary fetches? > 5). In section 2.6 > > C: INVITE sip:annc@ms2.example.net; \ > play=imap://joe@example.com/INBOX/;uid=24356/;section=1.2;\ > expire=2006-12-19T16:39:\57-08:00;urlauth=anonymous:\ > internal:238234982398239898a9898998798b987s87920; \ > content-type=video/mpeg; \ > content-transfer-encoding=base64 SIP/2.0 > > A curiosity question: does the content of the play parameter has to be > surrounded by '"'? > RFC 4240 says not. > Content-Type: application/sdp > Content-Length: 481 > > Here an in all other examples: extra empty line needed after the > Content-Length line? > Yes, there should be - that is a formatting bug. > 6). In Section 2.8: > >> If the media server is not configured as an authorized user of the >> IMAP server, it MUST authenticate to the IMAP server using the >> LOGIN >> command, with the username of "anonymous". >> > I believe this advice is out of date. > draft-ietf-lemonade-rfc2192bis-04.txt recommends using SASL ANONYMOUS. Ok, I'll look that up and confirm. > >> However, in this case, if >> >> the URL supplied in the 'play' parameter of the SIP INVITE >> specifies >> an authorization of 'authuser', then the media server SHOULD NOT >> attempt to contact the IMAP server, but SHOULD instead immediately >> return a response code of 404 to the client with a reason phrase of >> 'Not authorized to access resource' reason. >> > 7). Flow diagrams in section 2.9 don't show IMAP responses. This might > be Ok. > I tried to leave out non-essential responses in the flow diagrams. If anyone has any strong objection that that, please let me know. They are really just to show overall flow, not show every protocol exchange. > 8). In section 3: > >> This document proposes the use of URLAUTH "pawn tickets" to grant >> access to message parts. The goal is for the media server to >> stream >> these parts. INote that f one uses an anonymous pawn ticket, that >> > typo: Note that if one ... > Ok. > 9). In section 5: > >> media-servers = ms-tuple *(";" ms-tuple) >> >> host = astring >> > If you mean the RFC 3501 "astring" here, then I don't think this is > what > you actually want, as it allows for IMAP literals and quoted strings. > I suggest you use "host" non-terminal from RFC 3986. But if you follow > this suggestion, be aware that "host" requires that IP addresses be > enclosed in '[]'. > If you don't want that, you need to find more suitable productions in > RFC 3986. Yes, host from RFC 3986 looks good. However, looks like only IPv6 addresses need to be enclosed in []. BTW, what is the form for including ABNF definitions from other RFCs? Do I just copy the whole set of definitions out, or can I reference them in a standard way? > >> port = nstring >> > This is not what you want either, as this allows for "NIL", literal > and > quoted strings. I think you want to use the "port" non-terminal > from RFC > 3986. Yep. > >> ms-tuple = host ":" port (":" "authuser") >> > I think this should be: > > ms-tuple = host ":" port [":" "authuser"] > > as the last component is optional. Yes, that is what I meant. > Also note that section 2.3 says: > > For example, the client could > discover a tuple of a media server address and an IMAP username, > which allowed the client to generate a URL which was secure in that > it could *only* be accessed by a specific (presumably trusted) media > server. > > which seems to suggest that the optional part is a username. > So you either need to fix the text in Section 2.3 or the ABNF. The text is wrong. > 10). There is no "IANA Considerations" section. One should be added > and > contain text about a METADATA annotation registration, as well as the > registration of new SIP, etc. parameters. Yes, I'll move the METADATA annotation stuff into a separate IANA Considerations section. > 11). In section 7: > > I believe the following 2 references are Informative, so they > should be > moved to a new section: > >> [13] Newman, C., "Message Submission BURL Extension", RFC 4468, >> May 2006. >> > [...] > >> [17] Nereberg, L., "IMAP4 Binary Content Extension", RFC 3516, >> Apr 2003. >> > Also, I would like to suggest that the reference to RFC 2192 be > updated > to point to 2192bis. > Agreed. I will create an Informative References section. Neil. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Mar 29 10:18:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWvSX-0007SY-4X; Thu, 29 Mar 2007 10:18:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWvSV-0007SS-Td for lemonade@ietf.org; Thu, 29 Mar 2007 10:18:35 -0400 Received: from noware.co.uk ([82.153.134.193] helo=mail.noware.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWvST-0003Vq-Jj for lemonade@ietf.org; Thu, 29 Mar 2007 10:18:35 -0400 Received: by mail.noware.co.uk (Postfix, from userid 1008) id EDBF737B3; Thu, 29 Mar 2007 15:14:01 +0100 (BST) X-CMAE-Analysis: v=1.0 c=1 a=bBXDOl28C-QFJZP-ht4A:9 a=a_nLTnRBc4dGwhuxFmsA:7 a=OJ4kc3J5c87NYaAtXPnd8QxzPt8A:4 Received: from [172.22.1.156] (unknown [72.5.239.5]) by mail.noware.co.uk (Postfix) with ESMTP id E808636EC; Thu, 29 Mar 2007 15:13:58 +0100 (BST) In-Reply-To: <6000.1175008017.686117@peirce.dave.cridland.net> References: <4608EF81.5050401@isode.com> <6000.1175008017.686117@peirce.dave.cridland.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <35A5A4A1-D3ED-41EE-A521-1C3C95AA885A@noware.co.uk> Content-Transfer-Encoding: 7bit From: Neil Cook Subject: Re: [lemonade] WGLC streaming Date: Thu, 29 Mar 2007 15:18:26 +0100 To: Dave Cridland X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 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, >> Should be: >> C: a122 UID FETCH 24356 BODY[1.2.MIME] >> S: * 26 FETCH (BODY[1.2.MIME] {62} >> S: Content-Transfer-Encoding: base64 >> S: Content-Type: video/mpeg; >> S: UID 24356 FLAGS (\Seen)) >> (i.e. an extra space before "UID" and change "{127}" to "{62}" > Actually, no... It *should* be using BODYSTRUCTURE to find the > media type - by the time you know that section 1.2 (or 1.2.MIME) > exists, you already know the media type of the part, and its encoding. Actually the reason I used BODY there was more for clarity, to show the MIME information for that particular bodypart. BODYSTRUCTURE shows the media type for all the bodyparts, and so is less clear. >> 3). In section 2.3 >>> Clients SHOULD parse the value of mediaServers, (using either the >>> value.priv or value.shared: whichever is available and/or >>> appropriate), and contact a media server using one of the >>> supplied >>> values. No particular preference order is implied by the >>> ordering, >> I would prefer is the order specified by the server is the >> preferred order. > I'm not sure it matters overmuch. It might be that the client can > identify which server is closest better than the server. It really > depends upon what we mean by "preferred". > >>> Similarly, the message may well be encoded with a content >>> transfer >>> encoding such as base 64. However, RFC 4240 does not include a >>> method for communicating content transfer encoding to the media >>> server as part of the announcement service, nor does the URLFETCH >>> command include a mechanism for retrieving message parts without >>> encoding (c.f. the BINARY [17] extension to IMAP). >> Would it be better if IMAP URL is extended to allow for binary >> content >> fetching? > I think that might well be neater, although it depends on which > extension requires more work. > >> 7). Flow diagrams in section 2.9 don't show IMAP responses. This >> might >> be Ok. > I think it'd be clearer if they were there. (Again, this is FETCH > BODY[MIME], rather than FETCH BODYSTRUCTURE). I'd be okay with adding the IMAP responses if folks think it would make it clearer. Again, the FETCH BODY[MIME] is just to match with the previous example. I don't think this document is going to be used as a guide to writing IMAP clients, or how to retrieve body structure. >> 9). In section 5: > > >> I think this should be: >> ms-tuple = host ":" port [":" "authuser"] >> as the last component is optional. > I'm concerned with IPv6 behaviour with this production. I'm also > thinking that perhaps a URI form would be more suitable, as it > allows for more expansion capability. Assuming, that is, that these > media services have URIs to them. Well using the "host" ABNF from RFC 3986 would cover the various forms of IPv6 etc. >> 10). There is no "IANA Considerations" section. One should be >> added and >> contain text about a METADATA annotation registration, as well as the >> registration of new SIP, etc. parameters. > The Metadata annotation registration is in 2.3, but yes, it needs > to be moved. > > Further comments - and please note that the majority of the SIP > stuff goes shooting over my head: > > In the Security Considerations section, there seems to be a sudden > lack of references. In particular, sips, SIP, RFC4240, RFC4722, and > S/MIME all lack references (although they're in the Normative > References section). I have been in somewhat of a quandry about that. Do I reference *everytime* I mention another standard? I got the feeling that by the end of the doc, if various protocols have been referenced enough, they probably don't need any more, but I'd be happy to be corrected on that. Obviously any in that section which haven't been referenced before should be referenced. > The IMAP base specification, and URLAUTH, also has recommendations > concerning encryption layers in conjunction with authorized URLs - > you may find it better to simply include the security > considerations in both RFC3501 and URLAUTH by reference. Typically, > you'd do this with this text replacing the first two paragraphs: > > "This document proposes the use of URLAUTH [URLAUTH] "pawn > tickets", received over IMAP [IMAP], and transmitted over SIP > [SIP], possibly within the MSCML payload of IVR [RFC4722]. As such, > the security considerations in all these documents apply to this > specification. > > In summary, as the authorized URLs may grant access to data, > implementors of this specification need to consider the following: > Or something similar, anyway. That's a good idea. I'll try and wordsmith something similar to that. > Section 4: The Great DRM Can Of Worms: > > If I were a lawyer, then aside from the fact I'd never read a > technical document, I'd be concerned with the phrase "[...] also > implicitly gives the creator [of the URLAUTH authorized URL] the > right to pass that reference on to any third party it desires." > This phrase implies that the document authors believe that > transmission of media via email grants the recipient rights to > redistribution, which is probably not the view of most people, DRM- > fans or not. > > Without delving into the precise legal terminology required, I'd > say that the use of URLAUTH in this specification is believed to be > persuant with, and used only for, the execution of those rights to > be expected when media is sent via traditional internet messaging, > and causes no duplication of media content which is not essentially > provided by the action of sending the message; that is, the use of > the content for downloading and viewing, which *is* implicitly > granted by the sender of the message, in as much as the sender has > the right to grant such rights. > > I might also state that any DRM required needs to be implemented > within the media type, and moreover to take into account that the > use of this specification requires a third party to access the > media content in order to provide efficient private streaming. > > I'm very much against implementing DRM checks in URLAUTH, which > would require me to maintain a somehow perfect list of media types > which require DRM checks, and presumably open my employer to DRM > related lawsuits should I fail to comply. I took the DRM text mostly from Eric (buck passing ahoy :). I agree with your sentiments, in that we shouldn't be implying anything about the intent of DRM (or lack of it), only explaining what are the implications for DRM of this mechanism. > As a final comment, I believe this specification needs careful > review by a suitable working group (or groups) within the SIP > community - could I suggest that the Chairs, or Secretary, arrange > this with the RAI review team, or RAI ADs? Completely agree that someone from the SIP community needs to review. Ideally the folks who reviewed MSCML and NetAnn. Neil. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Mar 29 10:33:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWvgG-0000Tj-Jw; Thu, 29 Mar 2007 10:32:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWvgE-0000Of-VF for lemonade@ietf.org; Thu, 29 Mar 2007 10:32:46 -0400 Received: from noware.co.uk ([82.153.134.193] helo=mail.noware.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWvgD-0005uC-DZ for lemonade@ietf.org; Thu, 29 Mar 2007 10:32:46 -0400 Received: by mail.noware.co.uk (Postfix, from userid 1008) id 406D237B3; Thu, 29 Mar 2007 15:28:13 +0100 (BST) X-CMAE-Analysis: v=1.0 c=1 a=OD9Mg-I015kQG1NGsR4A:9 a=yNG0pvlLCX7LmqWwjBAA:7 a=j4yB6rfBXHU8-8DxvDgUvjEe4M8A:4 Received: from [172.22.1.156] (unknown [72.5.239.5]) by mail.noware.co.uk (Postfix) with ESMTP id DB37F36EC; Thu, 29 Mar 2007 15:28:10 +0100 (BST) In-Reply-To: <89017B166CB7E140BA80577FF744AE19924EAE@ILEXC2U01.ndc.lucent.com> References: <89017B166CB7E140BA80577FF744AE19924EAE@ILEXC2U01.ndc.lucent.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1FDC71D9-061C-4A5D-906C-C19BDAE3466E@noware.co.uk> Content-Transfer-Encoding: 7bit From: Neil Cook Subject: Re: [lemonade] WGLC streaming Comments Date: Thu, 29 Mar 2007 15:32:38 +0100 To: "Vaudreuil, Greg M (Greg)" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 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 On 27 Mar 2007, at 16:42, Vaudreuil, Greg M (Greg) wrote: > Resending... The policy filter ate my message. > > Greg V. > > > 2nd paragraph of section 1. SIP does not stream media! Meda can be > streamed using RTP or RTSP. SIP invites such. Wordsmithing needed Agreed! > text following figure 1. > > Bullet 0 should make it clear how the client knows whether there is a > media server and whether the media can be streamed. Maybe just a > forward pointer to section 2.3x Ok. > General comment. I'm not comfortable with the amount of "go fish" in > the protocol. The server is not required to support both IVR and > NETANN > protocols, so the client is instructed to first try one, and if it > fails, then try the other protocol. Further, the client given a > choice > of separate audio and video media servers (for example) may have to > play > go fish across the set. It would be better to specify at some useful > level (top-level content-type would be sufficient for my needs) the > capabilities of the media server in the IMAP metadata, and to require > the superset IVR service. Is the idea that media server vendors > don't want to implement IVR to be LEMONADE compliant? They already > have > a bunch of work to support IMAP and the expanded SIP headers (and > corresponding CTE processing). Hmm, I wouldn't like to specify the capabilities of a particular media server in the metadata, as that information could quickly go out of date, e.g. a media server could be upgraded to support new media types and the IMAP server would not necessarily (imo almost certainly not) be updated with that new information. The issue is not that media server vendors wouldn't want to implement IVR to be LEMONADE compliant, the issue is more about how to discover, without "fishing" as you put it, the capabilities of a set of LEMONADE compliant media servers from a LEMONADE compliant IMAP server. I would assert that static configuration is bad, in fact potentially worse than fishing. In my experience, although the document gives the example of an audio- only media server as an example to show how negotiation could be done, in practice all the media servers I have worked with in the recent past actually support a wide range of audio and video codecs. > Content-transfer-encoding. I should be more up-to-date on IMAP > binary... I don't have a version in my cache and this is an airplane > message. But could we not simplify things by requiring the media > server > to always use a binary fetch and requring the IMAP server to strip the > CTE to binary? Saves a SIP extension and teaching media servers about > CTE. IMAP server already has to do binary for LEMONADE... My memory > suggests we required the ability for the server to unwrap CTE's for > client-server BW savings. IMAP URL doesn't support binary fetch. If it did I would be happy. > Section 3. > > Why should a client trust a particular media server? "Bad news, > your lab > results show you are....." The client authenticates to the > submission > server, so there is some reasonable expectation that the server is > authorized to see message content. There does not seem to be any > equivalent for the media server. Maybe there is more trust if you > found > the media server identity in METADATA from the IMAP server? I don't > know if this needs a fix, but it needs a mention in section 3. I will mention it. I think if you get the media server identity from the IMAP server then there is implicit trust. Otherwise, the media server is configured by out of band means, and I have no way to determine the security or otherwise of such a method, other than to mention it. > Section 4. > > This discussion seems to be limited to Forward-Lock DRM. Crypto-based > DRM may use separate solutions that are between the media server > and the > client, where the client provides necessary gunk to unlock the blob > fetched by the media server. Such solutions don't require any > extension > to URLAUTH. > I will re-work the DRM discussion. Further comments on suggested text are welcome, as it is not a particular area of expertise for me. Neil. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Mar 29 11:03:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWwA2-0001yE-3N; Thu, 29 Mar 2007 11:03:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWwA0-0001xr-L1 for lemonade@ietf.org; Thu, 29 Mar 2007 11:03:32 -0400 Received: from noware.co.uk ([82.153.134.193] helo=mail.noware.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWw9W-0002zT-A9 for lemonade@ietf.org; Thu, 29 Mar 2007 11:03:32 -0400 Received: by mail.noware.co.uk (Postfix, from userid 1008) id 55E6F37B3; Thu, 29 Mar 2007 15:58:28 +0100 (BST) X-CMAE-Analysis: v=1.0 c=1 a=p9A_RFqr_MlJ9MBvMasA:9 a=u8sY4MxnYYrAwpv7Q-4A:7 a=nPwG829JtTguADUyA5Y1VQXyORkA:4 Received: from [172.22.1.156] (unknown [72.5.239.5]) by mail.noware.co.uk (Postfix) with ESMTP id 0F6FF36EC; Thu, 29 Mar 2007 15:58:25 +0100 (BST) In-Reply-To: <4C38DC11F6B4FF4FAEA73E30DB5AA1573FE64D@esebe199.NOE.Nokia.com> References: <4C38DC11F6B4FF4FAEA73E30DB5AA1573FE64D@esebe199.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <412F021B-A3E6-4A2B-8354-E3ACDF682AF8@noware.co.uk> Content-Transfer-Encoding: 7bit From: Neil Cook Subject: Re: [lemonade] WGLC streaming - update; comments Date: Thu, 29 Mar 2007 16:02:50 +0100 To: X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d 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 On 28 Mar 2007, at 10:50, wrote: > Hi all, > here are some additional comments to this draft: > 1. Title. Would it be OK to remove "Messaging" from the title? One > might think MMS here. I could just replace "Messaging" with "Email". > 2. Conventions: "The key words "MUST", "MUST NOT", "SHOULD", > "SHOULD NOT", and "MAY" in this document are to be interpreted as > defined in RFC 2119 [8]." > Interestingly the list of these key words seems to vary from draft > to draft (take a look at draft-ietf-lemonade-rfc2192bis-04). Isn't > there a consolidated list that could be in every draft? Yes, I thought I had copied verbatim from RFC2119 but obviously not. I will correct. > 3. Section 1, paragraph one: "Email clients on resource and/or > network constrained devices, such a mobile phones, may have > difficulties in retrieving and/or storing large attachments > received in a message. For example, on a poor network link, the > latency required to download the entire attachment may not be > acceptable to the user." > Typo: "such a" -> "such as" Ok. > I am not sure how streaming helps network contstrained devices > since streaming might be more network-demanding in some cases than > a slow fetch. I thought the whole reason of doing streaming was: > not to download and store stream-able attachments at all. I've seen > streaming on slow networks, and I can tell that I would rather wait > longer to retrieve it slowly in the background without streaming. > Looking at the phone and waiting for new frames to be drawn is > just: bad. Even today, in my office where there is gigabits of > bandwidth I still have to wait for some streams for pre-load more > than half of the movies (not because there is a network limit, not > because there is a client limit, but because there are limitations > on the server.) Therefore, I suggest removing any hints about doing > this because there is not enough bandwidth. I'm not sure I agree. There are plenty of scenarios where streaming is more network efficient. If someone sends me a very high definition movie or audio clip, but that clip is streamed to my device rather than retrieved, I can watch/listen to it in a fraction of the time it would have taken to download it, because streaming almost always means transcoding to a lower quality suitable for the device. > 4. Section 1, paragraph two: "Streaming the media to the device > addresses both the latency issue, since the client can start > playing the media immediately..." > Who are we kidding here? There is no way to start playing without > receiving data first. (Unless of course we play something else than > what the user has asked for.) I will change "immediately" to "shortly". > 5. Typo in Section 1, paragraph two: "A tradeoff" -> "A trade-off" Both are acceptable, at least in UK English. > 6. Section 1, paragrapth two: "A tradeoff is that the media cannot > be viewed/played when the device is offline." > Unless of course it has been downloaded already (e.g. he user has > viewed is once already so it's cached locally). I will change "cannot" to "may not be able to". Due to resource or other constraints, the device may not be able to cache the media. > 7. Wording change suggestion in Section 2.1, paragraph two: > "in order to accommodate the passing of a content transfer encoding > parameter." > -> > "in order to accommodate passing a content transfer encoding > parameter." Ok. > 8. Question regarding Figure 1: Shouldn't all arrows be double-headed? Theoretically yes, but I hoping to make initiation implicitly clear. > 9. Bullet 6. below figure 1: > "The media server or the client terminates the SIP session." > SIP session? I thought it would be RTP, MSRP, but SIP? SIP is not a > transport protocol. Paragraph 1 in 2.4 says RTP. You're right. Will change to "terminates the media session". > 10. Section 2.2 paragraph 1: "will be attempted" -> "is required"? > I mean the next paragraph talks about it that way. > Ok. > 11. Section 2.2 paragraph 2: ";EXPIRE=" Isn't there a > "nicer" way to do this? This requires "funny" calculations on the > client: current time (what if it's not valid?), current time zone > (what if it's not valid), daylight saving setting (what if it's not > valid)? A period (like: 1 hour period from now on) or an access > count (like: 1 access attempt only) would be more comfy. > > 12. Section 2.2 paragraph 3: "the use of anonymous URLAUTH > authorized URLs" shouldn't we disable anonymous access completely? > It's an attachment in my email after all, which might very well > contain strictly confidential info. I suspect that streaming will > not be used when the smallest chance to leak info exists. > > 13. Section 2.2 paragraph 4: "SHOULD be 'authuser'" authuser being > what? There is no info about this (not in syntax either). Also, I > think that this should be a MUST and forbid anonymous access. > Answered by Dave Cridland already. > 14. Extra space in section 2.3 paragraph 3: "pawn- ticket" Ok. > 15. Wording change suggestion in 2.3 paragraph 3: > "For example, the client could discover a tuple of a media server > address and an IMAP username, which allowed the client to generate > a URL which was secure in that it could *only* be accessed by a > specific (presumably trusted) media server." > -> > "For example, the client could discover a tuple of a media server > address and an IMAP username, which allows the client to generate a > secure URL that could *only* be accessed by a specific (presumably > trusted) media server." Ok. Will be changing this section anyway, as "IMAP username" is wrong. > 16. Same as comment #1 for the IANA registration in section 2.3: > "Description: Defined in Streaming Multimedia Messaging > Attachments" : remove the word "Messaging" - foe some it might mean > MMS. WIll change to Email. > 17. Typo (?) in 2.3 last paragraph: "left to the client implementor > to decide" isn't is "implementer"? Ok. > 18. Wording change suggestion in 2.4 paragraph 3: > "then if the client supports it," > -> > "but the client supports it, ok. > 19. Wording change suggestion in 2.5 paragraph 4: > "Similarly, the message may well be encoded with a content transfer > encoding such as base 64" > -> > "Similarly, the message may be encoded with a content transfer > encoding such as BASE64 [BASE64]" Will reference. > 20. Word missing in 2.5 second last paragraph: "If the receives a > 200 OK response" Will fix. > 21. 2.5 last paragraph: > 404 does not seem to be sufficient - a single status code covering > all possible errors is not very useful. Is there any way to > indicate to the client what very wrong (really)? Theoretically the media server could return a number of SIP error code, but this document doesn't attempt to cover all of them. It just explains what that particular error code means. > 22. Wording change suggesion in 2.6 paragraph 1: > "it is felt worthwhile to give some examples " > -> > "it is worth giving some examples" ok > 23. Wording change suggestion in 2.6 paragraph 2: > "In the below example" > -> > "In the example below" ok > 24. Section 2.6, paragraph 3: "The client and server now know from > the SDP advertised by both client and server that communication > must be using the subset of audio > codecs supported by both client and server (in the example SDP, > it is clear that the server does not support any video codecs)." > I think they knew this without having to perform any communication > - what they gain here is that they will both know the smallest > common set. Will wordsmith. > 25. Section 2.6 paragraph 4: " request" What is it? > (No previous mentioning if this, at least a reference would be nice). This is part of MSCML RFC. Will reference. > 26. Wording change suggestion 2.7 paragraph 2: "establish" -> > "discover". ok > 27. Question on 2.7 paragraph 2: "must generate a SIP INFO request > " shouldn't this be a MUST (upper-case)? > Yep. > 28. Question on 2.7 paragraph 4: shoudn't "playcollect" be always > ""? > Probably, yes :) > 29. Wording change suggestion in 2.7 paragraph 12: > "The following gives an example dialog between" > -> > "The following example shows a dialog between" > ok. > 30. Question on Section 2.8 paragraph 2: Could we change that > "SHOULD" to a "MUST"? Or, how will the IMAP server know the client > policy? Same question for "SHOULD NOT"->"MUST NOT" in the next > paragraph. I think that would be okay. > 31. Typos in Section 3 paragraph 1: "INote that f one" -> "Note > that one" Ok. > 32. Typo (?) in section 3 paragraph 2: "implementors" -> > "implementers"? I am not sure. > I think both are valid. Neil. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Mar 29 11:07:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWwDa-0005Gg-Hd; Thu, 29 Mar 2007 11:07:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWwDY-0005GQ-Lt for lemonade@ietf.org; Thu, 29 Mar 2007 11:07:12 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWwDC-0003vt-SD for lemonade@ietf.org; Thu, 29 Mar 2007 11:07:12 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 29 Mar 2007 16:06:50 +0100 Message-ID: <460BD5DF.7080808@isode.com> Date: Thu, 29 Mar 2007 16:06:07 +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: Lemonade WG References: <460A7A38.5000304@isode.com> In-Reply-To: <460A7A38.5000304@isode.com> 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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [lemonade] Re: Open Issues with IMAP CONVERT 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 one more additional issue with CONVERT (so far): 4). CONVERT uses the '*' character in annotations to signal "any media type" or "any subtype". However '*' is not allowed in annotation names. Any objections to changing this to the '@' character? [FYI, ABNF for media type or subtype is: reg-name-chars = ALPHA / DIGIT / "!" / "#" / "$" / "&" / "." / "+" / "-" / "^" / "_" So, I would like to pick a character that can never occur in a media type/subtype name] _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Mar 29 11:33:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWwcS-0000TD-Ma; Thu, 29 Mar 2007 11:32:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWwcR-0000T8-W8 for lemonade@ietf.org; Thu, 29 Mar 2007 11:32:55 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWwcO-0000Xw-HY for lemonade@ietf.org; Thu, 29 Mar 2007 11:32:55 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 29 Mar 2007 16:32:51 +0100 Message-ID: <460BDBF9.9040901@isode.com> Date: Thu, 29 Mar 2007 16:32: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 MIME-Version: 1.0 To: Zoltan.Ordogh@nokia.com Subject: Re: [lemonade] Open Issues with IMAP CONVERT References: <460A7A38.5000304@isode.com> <4C38DC11F6B4FF4FAEA73E30DB5AA1573FED5D@esebe199.NOE.Nokia.com> In-Reply-To: <4C38DC11F6B4FF4FAEA73E30DB5AA1573FED5D@esebe199.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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 Zoltan, Zoltan.Ordogh@nokia.com wrote: >>2). draft -05 currently allows for default conversion (i.e. >>"just convert to any media type, you know best"). >>I don't think this should be allowed and I suggest removing >>this feature from ABNF. >> >> >OMA has a requirement for the server making the decision (based on some >capability information about the client) and I think this is our "hook" >to do that. Removing it would complicate our lives in OMA. I would like >to ask You to re-consider this proposal. > > Considering your anwer to the related question below, I am now Ok with keeping this. Is support for this feature optional for a general IMAP server? I think the answer is "yes". But OMA can make this a required feature. >>Somewhat related to this: is the server allowed to convert to >>image/png instead of image/jpeg when .STRICT suffix to CONVERT >>is not specified? (I don't think this should be allowed) >> >> >I don't think it should be allowed. >In fact, I think STRICT should be removed and if the server cannot >fulfill the convert then it should fail the request. I think mosts >client would add it there anyway because they want exactly what they >asked for - and nothing else. If clients don't want to convert to some >specific type, they will let the server decide the best conversion. > > Your suggestion will work for me. It will certainly make the document simpler to read and implement. >>3). There is one big issue surrounding INFORMATIONLOSS. I will >>publish an updated draft shortly, but it will not tackle this >>issue. I will try to address the issue in the subsequent revision. >> >> >Could You elaborate this, please? > > The issue is how the client can figure out which bodypart was converted with loss when the client requested multiple conversions in a single FETCH command. Some suggested to use URLs to identify the bodypart. Arnt wrote the following: > Serious: I don't like the INFORMATIONLOSS response code - it's on the > wrong response. As it stands, it means "one or more of the preceeding > untagged responses is approximate rather than exact". Either it should > be a flag on BODYPARTSTRUCTURE to show exactly which conversion is > approximate, or it should carry some arguments to specify the inexact > bodypart(s). _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Mar 29 11:41:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWwkl-0005VY-BR; Thu, 29 Mar 2007 11:41:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWwkk-0005VJ-DW for lemonade@ietf.org; Thu, 29 Mar 2007 11:41:30 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWwki-0001w4-V9 for lemonade@ietf.org; Thu, 29 Mar 2007 11:41:30 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 29 Mar 2007 16:41:28 +0100 Message-ID: <460BDDFD.3010709@isode.com> Date: Thu, 29 Mar 2007 16:40:45 +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] WGCL Convert-05 References: <774007.99226.qm@web30502.mail.mud.yahoo.com> In-Reply-To: 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.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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: > Three serious problems and some irritants. > > Serious: The document could do a better job of explaining why it's = > useful. It never has persuaded me to do much more than skim and ignore = > it. Mark would say =ABneat to have, not need to have=BB. Maybe it _is_ a = > need-to-have, but reading the abstract/introduction hasn't shown me = > any need. I would like to solicit some help with this text. > In section 3, the second paragraph could mention an additional reason = > to keep the original format: S/MIME. If you change the format, you = > break all signatures. The second paragraph of section 3 now reads: Note: The requirement that original data be unaltered allows such = data to remain accessible by other clients, permits replies or forwards of the original documents, permits signature verification (the converted bodyparts are not likely to contain any signatures), and preserves BODYSTRUCTURE and related information. > The examples on page 6 urgently need better formatting. Fixed (I hope). > In 6.1, this sentence makes no sense to me: =ABA client requesting the = > server annotation "/convert/text/plain" MUST return "text/plain" as an = > allowed destination conversion.=BB This is referring to charset conversion. I've changed the text to read: The server MUST list "text/plain" as an allowed destination conversion in the "/convert/text/plain" annotation. Is this any better? > I suggest removing the word =ABand=BB at the head of the following senten= ce. I removed the "And". [...] > The formal syntax has lots of formatting problems. Because of that I = > didn't look closely for other problems. Fixed. > Serious: The security considerations section omits a new attack: A = > client can APPEND a carefully crafted bad message followed by FETCH to = > attack the server. If the server's conversion function or library has = > a security problem, this could result in provilege escalation or = > denial of service. Added. Alexey P.S. I will try to address the remaining comments later. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Mar 29 12:30:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWxW5-0001tq-84; Thu, 29 Mar 2007 12:30:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWxW3-0001m3-Ql for lemonade@ietf.org; Thu, 29 Mar 2007 12:30:23 -0400 Received: from mxout5.cac.washington.edu ([140.142.32.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWxVz-0002J1-GA for lemonade@ietf.org; Thu, 29 Mar 2007 12:30:23 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l2TGUIlC005486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Mar 2007 09:30:18 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l2TGUFOm029383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 29 Mar 2007 09:30:17 -0700 Date: Thu, 29 Mar 2007 09:30:15 -0700 (PDT) From: Mark Crispin To: Neil Cook Subject: Re: [lemonade] WGLC streaming - update; comments In-Reply-To: <412F021B-A3E6-4A2B-8354-E3ACDF682AF8@noware.co.uk> Message-ID: References: <4C38DC11F6B4FF4FAEA73E30DB5AA1573FE64D@esebe199.NOE.Nokia.com> <412F021B-A3E6-4A2B-8354-E3ACDF682AF8@noware.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=us-ascii; format=flowed X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.3.29.91734 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: cf4fa59384e76e63313391b70cd0dd25 Cc: lemonade@ietf.org, "" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu, 29 Mar 2007, Neil Cook wrote: >> 1. Title. Would it be OK to remove "Messaging" from the title? One might >> think MMS here. > I could just replace "Messaging" with "Email". That's no good. We switched from "mail" to "messaging" in IMAP's name for a reason; IMAP encompasses news as well as email. That is a far more serious possibility of confusion. Suggest "Internet Messaging" if you want to exclude MMS. -- 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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Mar 29 12:33:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWxYl-0004EW-RF; Thu, 29 Mar 2007 12:33:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWxYk-0004EF-NC for lemonade@ietf.org; Thu, 29 Mar 2007 12:33:10 -0400 Received: from mxout7.cac.washington.edu ([140.142.32.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWxYj-0002hU-Cp for lemonade@ietf.org; Thu, 29 Mar 2007 12:33:10 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9] (may be forged)) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l2TGX8HK004927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Mar 2007 09:33:08 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l2TGX5Mk016018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 29 Mar 2007 09:33:07 -0700 Date: Thu, 29 Mar 2007 09:33:04 -0700 (PDT) From: Mark Crispin To: Neil Cook Subject: Re: [lemonade] WGLC streaming - update; comments In-Reply-To: Message-ID: References: <4C38DC11F6B4FF4FAEA73E30DB5AA1573FE64D@esebe199.NOE.Nokia.com> <412F021B-A3E6-4A2B-8354-E3ACDF682AF8@noware.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.3.29.92134 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 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 On Thu, 29 Mar 2007, Mark Crispin wrote: > Suggest "Internet Messaging" if you want to exclude MMS. And, since IMAP is the "Internet Message Access Protocol" you have a precedent for the term. -- 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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Mar 29 14:16:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWzA1-0002Tm-8K; Thu, 29 Mar 2007 14:15:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWz9z-0002TZ-L5 for lemonade@ietf.org; Thu, 29 Mar 2007 14:15:43 -0400 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HWz9x-0000CN-Ii for lemonade@ietf.org; Thu, 29 Mar 2007 14:15:43 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 29 Mar 2007 19:15:37 +0100 Message-ID: <460C021E.1070205@isode.com> Date: Thu, 29 Mar 2007 19:14:54 +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 WG Content-Type: multipart/mixed; boundary="------------010509010802030103020808" X-Spam-Score: 0.1 (/) X-Scan-Signature: c19b0202782d58bc2165351c4000e72f Subject: [lemonade] Updated version of IMAP CONVERT 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 --------------010509010802030103020808 Content-type: text/plain; charset="us-ascii" The attached version doesn't address some of the issues I've brought up on the mailing list this week. Please review this version during the next week (while I am on holidays). Note that some editorial comments are enclosed in <<>>. They either mark some text that needs to be changed or they ask some questions that need to be addressed. I would welcome comments on such editorial comments. --------------010509010802030103020808 Content-type: unknown/exe; name="draft-ietf-lemonade-convert-06a.txt" Content-transfer-encoding: 7bit Content-Disposition: inline; filename="draft-ietf-lemonade-convert-06a.txt" Internet Draft: CONVERT A. Melnikov (Ed.) Document: draft-ietf-lemonade-convert-06 Isode Limited Intended status: Standard Track R. Cromwell (Ed.) S. H. Maes (Ed.) Oracle Expires: September 2007 March 2007 CONVERT Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Distribution of this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract CONVERT defines extensions to IMAP allowing clients to request adaptation and/or transcoding of attachments. Clients can specify the conversion details or allow servers to decide based on knowledge of client capabilities, on user or administrator preferences or its settings. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. When describing the general syntax, some definitions are omitted as they are defined in [RFC3501]. Table of Contents Status of this Memo ....................................... 1 Copyright Notice........................................... 1 Abstract................................................... 1 Conventions used in this document.......................... 1 Table of Contents.......................................... 2 1. Introduction............................................ 3 2. Relation with other E-mail specifications............... 3 3. Scope of Conversions.................................... 4 4. Discovery with the CAPABILITY and GETMETADATA Commands.. 4 4.1. CAPABILITY......................................... 4 4.2. GETMETADATA ....................................... 4 5. CONVERT extension to BODY and BINARY FETCH data items... 5 6. CONVERT transcoding parameters.......................... 7 6.1. Mandatory Transcoding support...................... 7 6.1.1. Additional features for mobile usage.......... 8 7. FETCH response extensions............................... 8 8. Status responses, Response code extensions.............. 8 9. Formal Syntax........................................... 9 10. IANA Considerations.................................... 11 11. IANA Entry and Attribute registrations ................ 11 11.1. IANA Entry "/convert"............................. 11 11.2. IANA Attribute "types"............................ 12 11.3. IANA Attribute "params"........................... 12 Security Considerations.................................... 12 Normative References....................................... 13 Informative References..................................... 14 Version History............................................ 14 Acknowledgments............................................ 15 Authors' Addresses........................................ 15 Intellectual Property Statement........................... 16 Disclaimer of Validity.................................... 16 Copyright Statement .......................................16 1. Introduction This document defines the CONVERT extension to IMAP4 [RFC3501]. It defines additional enhancements for optimization in a mobile setting: extensions to the IMAP4Rev1 protocol [RFC3501] that allows adaptation and transcoding of body parts 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 server that supports CONVERT can convert <> to other formats to be viewed on a mobile device. The client can explicitly request a particular conversion. <> 2. Relation with other E-mail specifications The CONVERT extension does not address conversion during streaming of attachments. CONVERT depends on the METADATA extension [METADATA] to support discovery of supported conversion formats. In addition, to use CONVERT, the server MUST support the IMAP Binary specification [RFC3516]. 3. Scope of Conversions 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. Note: The requirement that original data be unaltered allows such data to remain accessible by other clients, permits replies or forwards of the original documents, permits signature verification (the converted bodyparts are not likely to contain any signatures), and preserves BODYSTRUCTURE and related information. 4. Discovery with the CAPABILITY and GETMETADATA Commands 4.1. CAPABILITY A server that supports the CONVERT extension MUST return "CONVERT", "METADATA", and "BINARY" in the CAPABILITY response. Example: A server that implements CONVERT C: a001 CAPABILITY S: * CAPABILITY IMAP4rev1 CONVERT BINARY METADATA [...] S: a001 OK CAPABILITY completed 4.2. GETMETADATA To determine which conversions are supported, server annotations are used. For each MIME format (/ [MIME-IMT]) that can be converted, an annotation with the name "/convert//" SHOULD exist. <> For each source MIME type that the client is interested in, it SHOULD determine which target conversions are supported by reading <>. Note that a special annotation named "/convert//@" can be used to reference any subtype of media type. A client that doesn't find an "/convert//" annotation SHOULD check the value of the "/convert//@" annotation. Note that names of server annotations are case-sensitive (see [METADATA]). In order to guaranty interoperability, clients and servers MUST use the lowercases version of and when constructing an annotation name described above. Example: Discover all image conversions C: a GETMETADATA "/convert/image/@" types.shared S: * METADATA "/convert/image/jpeg" (types.shared "image/jpeg;image/png;image/gif;image/wbmp") S: a OK GETMETADATA complete The above example shows that the server supports one kind of input image transcoding, from image/jpeg to four different outputs: JPEG, PNG, GIF, and WBMP. For a given conversion, optional transcoding parameters MAY be present. <> Example: Discover optional parameters for image/jpeg -> image/gif. C: a GETMETADATA /convert/image/jpeg/image/gif "params.shared" S: * METADATA /convert/image/jpeg/image/gif ("params.shared" "width;height;depth;interlaced") S: a OK GETMETADATA complete The above example shows that to convert from image/jpeg to image/gif, the transcoding supports the following types of option parameters: width, height, depth, and interlaced. A client MAY use these values to check whether or not a desired conversion is possible, or it may present the parameters as a GUI preferences pane for the user to customize. A baseline set of register transcoding parameter names should be standardized (see [OMA-STI]) in the future, and it is beyond the scope of this spec to allow the client to discover the underlying legal values that these parameters may take. 5. CONVERT extension to BODY and BINARY FETCH data items The CONVERT extension defines a FETCH extension used to transcode the media type of a <> into another media type, and/or the same media type, with different encoding parameters. It adds new options to the section-spec part of the BODY data item, a new FETCH response data item BODYPARTSTRUCTURE, and new response codes. It is also expected to work with IMAP BINARY data item extension, whose grammar is modified as well. The response to a CONVERT request always includes a BODYPARTSTRUCTURE. Each request for BODY or BINARY FETCH data item that contains CONVERT MUST result in a FETCH response containing BODY/BINARY and BODYPARTSTRUCTURE data items containing the same section specifier (including the CONVERT keyword and its parameters). This is needed so that the client can match the requested data items with the received ones. This also allows the client to request multiple conversions of the same bodypart in a single request. CONVERT's syntax is modeled after the HEADER.FIELDS syntax in [RFC3501], and is generally structured as: BODY[section-part.CONVERT[.STRICT] ("media type/subtype" (parameters))] BODY.PEEK[section-part.CONVERT[.STRICT] ("media type/subtype" (parameters))] BINARY[section-part.CONVERT[.STRICT] ("media type/subtype" (parameters))] BINARY.PEEK[section-part.CONVERT[.STRICT] ("media type/subtype" (parameters))] BINARY.SIZE[section-part.CONVERT[.STRICT] ("media type/subtype" (parameters))] Example: The client fetches body part section 3 in the message with the message sequence number of 2 and asks to have that attachment converted to pdf format. C: a001 FETCH 2 BODY[3.CONVERT ("APPLICATION/PDF")] S: * 2 FETCH (BODYPARTSTRUCTURE[3.CONVERT ("APPLICATION/PDF")] ("APPLICATION" "PDF" () NIL NIL "Base64" 2135 NIL NIL NIL) BODY[3.CONVERT ("APPLICATION/PDF")] {2135} ) S: a001 OK FETCH COMPLETED <> C: b001 FETCH 2 BODY[3.CONVERT ("text/plain" ("charset" "us-ascii"))] S: * 2 FETCH (BODYPARTSTRUCTURE[3.CONVERT ("text/plain" ("charset" "us-ascii"))] ("TEXT" "PLAIN" ("charset" "utf-8") NIL NIL "Base64" 2135 181 NIL NIL NIL) BODY [3.CONVERT ("text/plain" ("charset" "us-ascii"))] {2135} ) S: b001 OK FETCH COMPLETED <> Example: The client requests for conversion of a text/html section as text/plain, but only wants 1000 bytes, starting from byte 2001. C: c001 FETCH 2 BODY[3.CONVERT ("TEXT/PLAIN" ("CHARSET" "us-ascii"))]<2001.1000> S: * 2 FETCH (BODYPARTSTRUCTURE[3.CONVERT ("TEXT/PLAIN" ("CHARSET" "us-ascii"))] ("TEXT" "PLAIN" ("charset" "us-ascii") NIL NIL "7bit" 2135 181 NIL NIL NIL) BODY[3.CONVERT ("TEXT/PLAIN" ("CHARSET" "us-ascii"))]<2001> {135} ) S: c001 OK FETCH COMPLETED The server is not required to respect a particular transcoding request or its request parameters unless the STRICT qualifier is used, although it MAY try to make a best effort to fulfill that request if it is omitted. Indeed, the server may know a priori information about the client obtained through a different mechanism outside the scope of CONVERT (e.g. dynamically through device description mechanisms or when the device was associated to the account). These preferences may be used to predefine what conversions are possible. Ideally the client should request the same conversions. In addition, this information may also allow attachment adaptation (e.g. picture form factor) instead of solely format conversion. 6. CONVERT transcoding parameters IMAP servers which support CONVERT MAY support additional transcoding parameters for each media type. All such servers MUST minally support recognition of charset for text/* MIME types, although they may decline to honor some requests. For media types other than text, it is beyond the scope of this document to define conversion parameters. In general however, CONVERT compliant servers MAY choose to support additional parameters, and if so, they SHOULD follow the OMA STI 1.0 spec [OMA-STI] adopting the same parameter names as defined in section 5.2.4 and above for the most popular image/*, video/*, and audio/* codecs As an example, in section 5.2.6.2 of [OMA-STI], the parameters "width" and "height" are defined. The following example illustrates how these OMA STI parameters are used with CONVERT. C: d001 UID FETCH 100 BINARY[2.CONVERT ("IMAGE" "JPG" ( "WIDTH" "128" "HEIGHT" "96"))] S: * 2 FETCH (UID 100 BODYPARTSTRUCTURE[2.CONVERT ("IMAGE" "JPG" ("WIDTH" "128" "HEIGHT" "96"))] ("IMAGE" "JPG" () NIL NIL "8bit" 4182 NIL NIL NIL) BINARY[2.CONVERT ("IMAGE" "JPG" ("WIDTH" "128" "HEIGHT" "96"))] ~{4182} ) S: d001 OK UID FETCH COMPLETED 6.1. Mandatory Transcoding support A server implementing CONVERT MUST support character set conversions for the text/plain MIME type, and MUST support character set conversions from iso-8859-* <> to utf-8. The server MUST list "text/plain" as an allowed destination conversion in the "/convert/text/plain" annotation. A request for annotation "/convert/text/plain/text/plain" MUST return "charset" as a supported transcoding parameter. Servers SHOULD offer additional character encoding conversions where they make sense as character conversion libraries are generally available on many platforms. If for some reason, the server cannot carry out the trancoding while preserving all the characters, the server SHOULD <> add an INFORMATIONLOSS response code to the response, unless STRICT is specified. If STRICT is specified, the server MUST return the BADPARAMETERS response code. 6.1.1. Additional features for mobile usage Based on the expected usage of convert in mobile environments: - Servers SHOULD support conversion of HTML and XHTML documents to text/plain in ways that preserve at the minimum the document structure and tables. - Server SHOULD support image conversions among the types image/gif, image/jpeg and image/png for at least the following parameters: o Size limit (i.e. reduce quality), o width, o height, o resize directive (crop, stretch, aspect ratio) The support for "depth" may also be of interest. Audio conversion is of significant interest but the relevant formats depend significantly on the usage context. Support of other formats like proprietary document formats and video can also be described as MIME types with STI parameters. Their support depends on the usage context. 7. FETCH response extensions The BODYPARTSTRUCTURE data item is introduced when using the CONVERT extension. Its data follows the exact syntax specified in the [RFC3501] BODYSTRUCTURE data item, but contains information for only the converted part. All information contained in BODYPARTSTRUCTURE pertains to the state of the part after it is converted, such as the converted MIME type, sub-type, size, or charset. The client must respect the return values and not assume the conversion request succeeds exactly as requested unless the STRICT qualifier is used. <> 8. Status responses, Response code extensions Some transcodings may require parameters. If a transcoding request is sent for a format which requires parameters, the server can reply with a NO response. Likewise, malformed MIME types may also generate NO responses. If the server is unable to perform the requested conversion because a resource is unavailable (e.g. internal error, transcoding service down) then a NO response should be returned. If a request is denied because of an operational error, such as lack of disk space, or because the requested conversion for some reason cannot be performed, and there is no fallback for this particular device (such as the case where a proprietary document format has no existing transcoding implementation, and the server recognizes that the client has no default viewer for it), the server MUST return a NO response. Otherwise, the server should return an OK response. The client in general can tell from the BODYPARTSTRUCTURE response whether or not its request was honored exactly, but may not know the reasons why. The following extension response codes are provided for OK and NO responses to disambiguate those situations, or warn about possible important data loss. INFORMATIONLOSS the conversion was satisfied for conversion request, but it may have resulted in the loss of important data (primarily of use for loss of text data, since rich media is often compressed with loss) BADPARAMETERS "(" convert-params ")" the listed parameters were not understood, or could not be honored for the reasons noted in section- text. In particular, a CONVERT.STRICT request may be fail because the server has no way to honor it. SERVEROVERRIDE the server override the request because it determined it could substitute a better one based on preferences, device capability knowledge, or server policy. If CONVERT.STRICT is used, the server MUST NOT return SERVEROVERRIDE. It must either honor the request, or fail. 9. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (ABNF) notation as used in [ABNF], and incorporates by reference the Core Rules defined in that document. This syntax augments the grammar specified in [RFC3501] and [RFC3516]. Non-terminals not defined in this document can be found in [RFC3501], [RFC3516] and [MIME-MTSRP]. In the ABNF section-msgtext grammar in section 9 of [RFC3501], Section-msgtext is hereby amended to read: section-convert = "CONVERT" [".STRICT"] SP convert-params section-msgtext =/ section-convert convert-params = "(" (quoted-to-mime-type / default-conversion) [SP "(" transcoding-params ")"] ")" quoted-to-mime-type = DQUOTE to-mime-type DQUOTE transcoding-params = transcoding-param-name SP transcoding-param-value *(SP transcoding-param-name SP transcoding-param-value) transcoding-param-name = astring transcoding-param-value = astring default-conversion = "NIL" <> In the ABNF syntax "section-binary" of [RFC3516], is amended to: section-binary = "[" [section-part ["." section-convert]] "]" In the ABNF syntax "msg-att-static" of [RFC3501], is amended to: msg-att-static =/ "BODYPARTSTRUCTURE" section SP "(" body-type-1part ")" <> In the ABNF syntax "resp-text-code" of [RFC3501], is amended to: Resp-text-code =/ "INFORMATIONLOSS" / "SERVEROVERRIDE" / "BADPARAMETERS" SP "(" bad-param-list ")" bad-param-list = transcoding-params In addition, the following ABNF describes the syntax of the GETMETADATA entries in Section 4.2 convert-entry-req = available-conversions / available-transcoding-parameters available-conversions = "/convert/" from-mime-type any-mime-type = "@" from-mime-type = any-mime-type / (type-name "/" any-mime-type) / concrete-mime-type ; i.e. "@" or "type/@" or "type/subtype" ; type-name is defined in [MIME-MTSRP]. concrete-mime-type = type-name "/" subtype-name ; i.e. "type/subtype". ; type-name and subtype-name ; are defined in [MIME-MTSRP]. <> from-concrete-mime-type = concrete-mime-type to-mime-type = concrete-mime-type available-transcoding-parameters = "/convert/" from-concrete-mime-type "/" to-mime-type ; Name of an annotation containing transcoding parameters. ; i.e. /convert/fromtype/fromsubtype/totype/tosubtype <> 10. IANA Considerations IMAP4 capabilities are registered by publishing a standards track or IESG approved experimental RFC. The registry is currently located at . This document defines the CONVERT IMAP capability. This extension shall be submitted to the IANA IMAP Capability registry. 10.1. IANA Entry and Attribute registrations The following sections specify IANA registrations for entries and attributes used in this document. 10.1.1. IANA Entry "/convert" To: iana@iana.org Subject: IMAP METADATA Registration Please register the following IMAP METADATA item: [x] Entry [ ] Attribute [ ] Mailbox [x] Server Name: /convert Description: Defined in IMAP CONVERT extension document. Content-type: text/plain; charset=utf-8 Contact person: Alexey Melnikov email: alexey.melnikov@isode.com 10.1.2. IANA Attribute "types" To: iana@iana.org Subject: IMAP METADATA Registration Please register the following IMAP METADATA item: [ ] Entry [x] Attribute [ ] Mailbox [x] Server Name: types Description: Defined in IMAP CONVERT extension document. Content-type: <<->> Contact person: Alexey Melnikov email: alexey.melnikov@isode.com 10.1.3. IANA Attribute "params" To: iana@iana.org Subject: IMAP METADATA Registration Please register the following IMAP METADATA item: [ ] Entry [x] Attribute [ ] Mailbox [x] Server Name: params Description: Defined in IMAP CONVERT extension document. Content-type: <<->> Contact person: Alexey Melnikov email: alexey.melnikov@isode.com 11. Security Considerations It is to be noted that some conversions may present security threats (e.g. converting a document to a damaging executable, exploiting a buffer overflow in a media codec/parser, or a denial of service attack against a client or server such as requesting an image be scaled to extremely large dimensions). Clients should be careful when requesting conversions or processing transformed attachments. Servers should avoid dangerous conversions if possible. Whenever possible, servers should perform verification of the converted attachments before returning them to the client. A client can create a carefully crafted bad message with the APPEND command followed by the FETCH command to attack the server. If the server's conversion function or library has a security problem, this could result in provilege escalation or Denial of Service. On bandwidth limited mobile networks where users pay per data volumes, spam may become an important issue. It can be mitigated with appropriate filters and server-side spam prevention tools. These are of course outside the scope of CONVERT. <> Deployments in which the actual transcoding is done outside the IMAP server in a separate server are recommended to keep the servers in the same trusted domain (e.g. subnet) 12. References 12.1. Normative References [METADATA] Daboo, C., "IMAP METADATA Extension", work in progress, draft-daboo-imap-annotatemore-11, 2007. [ABNF] D. Crocker, et al. "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. http://www.ietf.org/rfc/rfc4234 [RFC2119] Brader, S. "Keywords for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. http://www.ietf.org/rfc/rfc2119 [RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol Version 4 rev1", RFC 3501, March 2003. http://www.ietf.org/rfc/rfc3501 [RFC3516] Nerenberg, L. "IMAP4 Binary Content Extension", RFC 3516, April 2003. http://www.ietf.org/rfc/rfc3516.txt [MIME-IMT] Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail Extensions) Part Two: Media Types", RFC 2046, November 1996. [MIME-MTSRP] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", RFC 4288, December 2005. 12.2. Informative References [MEMAIL] Maes, S.H., "Lemonade and Mobile e-mail", draft-maes- lemonade-mobile-email-xx.txt, (work in progress). [OMA-ME-RD] Open Mobile Alliance Mobile Email Requirement Document, work in progress, http://www.openmobilealliance.org/ [OMA-STI] Open Mobile Alliance, Standard Transcoding Interface Specification, version 1.0, work in progress, . [SMIME] <<>> 13. Acknowledgments The authors want to specifically acknowledge the excellent criticism and comments received from Randall Gellens (Qualcomm) and Arnt Gulbrandsen (Oryx) which improved the quality of the CONVERT specification considerably. The authors also want to thank all who have contributed key insight and extensively reviewed and discussed the concepts of CONVERT and its predecessor P-IMAP. In particular, this includes the authors of the LCONVERT draft: Rafiul Ahad Oracle Corporation, Eugene Chiu Oracle Corporation, Ray Cromwell Oracle Corporation, Jia-der Day Oracle Corporation, Vi Ha Oracle Corporation, Wook- Hyun Jeong Samsung Electronics Co. LTF, Chang Kuang Oracle Corporation, Rodrigo Lima Oracle Corporation, Stephane H. Maes Oracle Corporation, Gustaf Rosell - Sony Ericsson, Jean Sini Symbol Technologies, Sung-Mu Son LG Electronics, Fan Xiaohui - CHINA MOBILE COMMUNICATIONS CORPORATION (CMCC), Zhao Lijun - CHINA MOBILE COMMUNICATIONS CORPORATION (CMCC). 14. Authors' Addresses Stephane H. Maes (Editor) Oracle Corporation 500 Oracle Parkway M/S 4op634 Redwood Shores, CA 94065 USA Phone: +1-650-607-6296 Email: stephane.maes@oracle.com Ray Cromwell (Editor) Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065 USA Alexey Melnikov (Editor) Isode Limited 5 Castle Business Village, 36 Station Road, Hampton, Middlesex, TW12 2BX, UK Email: Alexey.Melnikov@isode.com Version History Note to RFC-editor: Please delete this section before publication Release 05 - Client not mandated to support BINARY - Misc syntax and spelling fixes - New abstract contributed by Randall Gellens Release 04 - Remove compression and encryption - Update to use latest METADATA draft - Add IANA registrations Release 03 - Add mandatory character set conversions. - Add object level compression - Add object level encryption Release 02 Fixed a normative example to be informative. Added formal syntax for BODYPARTSTUCTURE, response text codes, and formal structure of composite GETANNOTATE values. Release 01 Corrected some grammatical mistakes. Clarified meaning of GETTANNOTATION response properties. Changed CONVERT grammar to merge media type and subtype into a single parameter instead of two parameters. Clarified that BODYSTRUCTURERESPONSE is always returned for CONVERT requests. Moved transcoding parameter discussion to main body from appendix. Release 00 Initial release published in October 2005 based on draft-maes- lemonade-lconvert-00 and the comments received at the London face to face meeting end of September 2005. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. --------------010509010802030103020808 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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --------------010509010802030103020808-- From lemonade-bounces@ietf.org Thu Mar 29 14:49:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWzgc-0000c6-Mi; Thu, 29 Mar 2007 14:49:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWzgb-0000c1-AW for lemonade@ietf.org; Thu, 29 Mar 2007 14:49:25 -0400 Received: from noware.co.uk ([82.153.134.193] helo=mail.noware.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWzga-0003ow-0G for lemonade@ietf.org; Thu, 29 Mar 2007 14:49:25 -0400 Received: by mail.noware.co.uk (Postfix, from userid 1008) id 95B0337B3; Thu, 29 Mar 2007 19:44:51 +0100 (BST) X-CMAE-Analysis: v=1.0 c=1 a=dCAVMpo6AAAA:8 a=0yIwn1B_hzhLAJNQcf4A:9 a=vrXCo9MMe4hHkkr9YpmQ7bSvE_sA:4 Received: from [172.22.1.156] (unknown [72.5.239.5]) by mail.noware.co.uk (Postfix) with ESMTP id C6ABE36EC; Thu, 29 Mar 2007 19:44:48 +0100 (BST) In-Reply-To: References: <4C38DC11F6B4FF4FAEA73E30DB5AA1573FE64D@esebe199.NOE.Nokia.com> <412F021B-A3E6-4A2B-8354-E3ACDF682AF8@noware.co.uk> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Neil Cook Subject: Re: [lemonade] WGLC streaming - update; comments Date: Thu, 29 Mar 2007 19:49:15 +0100 To: Mark Crispin X-Mailer: Apple Mail (2.752.3) 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 Sounds good, thanks, Neil. On 29 Mar 2007, at 17:33, Mark Crispin wrote: > On Thu, 29 Mar 2007, Mark Crispin wrote: >> Suggest "Internet Messaging" if you want to exclude MMS. > > And, since IMAP is the "Internet Message Access Protocol" you have > a precedent for the term. > > -- 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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Mar 29 17:11:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX1tK-0002EW-BS; Thu, 29 Mar 2007 17:10:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX1tI-0002EP-Oz for lemonade@ietf.org; Thu, 29 Mar 2007 17:10:40 -0400 Received: from smtp-out.sendmail.com ([209.246.26.45] helo=foon.sendmail.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HX1tH-0004Zd-9J for lemonade@ietf.org; Thu, 29 Mar 2007 17:10:40 -0400 Received: from [10.201.0.14] (adsl-64-58-1-252.mho.net [64.58.1.252] (may be forged)) (authenticated bits=0) by foon.sendmail.com (Switch-3.2.5/Switch-3.2.0) with ESMTP id l2TMDXVW022375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Mar 2007 14:13:35 -0800 X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com l2TMDXVW022375 DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1175206422; bh=+b+AbNXSGGnSGpBZRTgG0H+2qEI=; h=X-DomainKeys: DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:In-Reply-To: Message-ID:References:MIME-Version:Content-Type; b=ZTPEeR7x+KltM+xt bxiKFD4oXk2h5dWNntnAFOf9P/cVb0M3789TnAvgBGKR2SIyq0y7NJsMh1Wsm1qVLa0 ECZ2jdkZfl+7lblqGlj3uxUngRIMVJBPWQkTmptFZOfZs41fSPGX7k09jkhBdBWzjIT WguTOkvr0zPNJI6l7ralI= X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com l2TMDXVW022375 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type; b=CmKlpcnGG39MjNgvEI9u+j2PVs0WpNv1htAVR3nlNdAWSb1UYb0cLkSKPdGJwIZbJ ysI7AaZvm2m4YsGs7MlSh9cLGZn4nReeCr76a07/xT8i14YkVhe5APmj1yZL39xXN2v x0xs6ersSeTH2bl8JuztBLMDWFSjR9krCMjYTAA= Date: Thu, 29 Mar 2007 15:10:17 -0600 From: Philip Guenther X-X-Sender: guenther@vanye.mho.net To: neil.cook@noware.co.uk Subject: Re: [lemonade] WGLC streaming In-Reply-To: <4608EF81.5050401@isode.com> Message-ID: References: <4608EF81.5050401@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) 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 On Tue, 27 Mar 2007, Alexey Melnikov wrote: ... > Should be: > > C: a122 UID FETCH 24356 BODY[1.2.MIME] > S: * 26 FETCH (BODY[1.2.MIME] {62} > S: Content-Transfer-Encoding: base64 > S: Content-Type: video/mpeg; > S: UID 24356 FLAGS (\Seen)) Actually, I think it should read: C: a122 UID FETCH 24356 BODY[1.2.MIME] S: * 26 FETCH (BODY[1.2.MIME] {63} S: Content-Transfer-Encoding: base64 S: Content-Type: video/mpeg S: S: UID 24356 FLAGS (\Seen)) That is, no trailing semicolon on the content-type (please don't propagate that syntax error) and a blank line at the end of the MIME header. (While RFCs 3501 and 2045 don't specifically say that the blank line between the MIME headers and the body of the part--when present--is considered part of the MIME header, that definitely *is* true of the blank line for message headers returned by BODY[x.y.HEADER], so it's certainly more consistent to include it.) Philip Guenther _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Mar 30 03:49:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXBr3-0003SF-Si; Fri, 30 Mar 2007 03:49:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXBr3-0003S3-Fz for lemonade@ietf.org; Fri, 30 Mar 2007 03:49:01 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXBr1-000293-Uv for lemonade@ietf.org; Fri, 30 Mar 2007 03:49:01 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2U7mZuX017205; Fri, 30 Mar 2007 10:48:58 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Mar 2007 10:48:48 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Mar 2007 10:48:48 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] WGLC streaming - update; comments Date: Fri, 30 Mar 2007 10:47:07 +0300 Message-ID: <4C38DC11F6B4FF4FAEA73E30DB5AA15743BBD4@esebe199.NOE.Nokia.com> In-Reply-To: <412F021B-A3E6-4A2B-8354-E3ACDF682AF8@noware.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] WGLC streaming - update; comments thread-index: AcdyE1y/LNE55M2iT6SFg9hmfDcWegAiTNsw References: <4C38DC11F6B4FF4FAEA73E30DB5AA1573FE64D@esebe199.NOE.Nokia.com> <412F021B-A3E6-4A2B-8354-E3ACDF682AF8@noware.co.uk> From: To: X-OriginalArrivalTime: 30 Mar 2007 07:48:48.0426 (UTC) FILETIME=[D9E330A0:01C7729F] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070330104858-42ACBBB0-37A51ABB/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 Neil, I have some comments vs. Yours. >> 3. Section 1, paragraph one: "Email clients on resource..:" >> I am not sure how streaming helps network contstrained devices since=20 >> streaming might be more network-demanding in some cases than a slow=20 >> fetch. I thought the whole reason of doing streaming was: >> not to download and store stream-able attachments at all. I've seen=20 >> streaming on slow networks, and I can tell that I would rather wait=20 >> longer to retrieve it slowly in the background without streaming. >> Looking at the phone and waiting for new frames to be drawn is >> just: bad. Even today, in my office where there is gigabits of=20 >> bandwidth I still have to wait for some streams for pre-load=20 >more than=20 >> half of the movies (not because there is a network limit,=20 >not because=20 >> there is a client limit, but because there are limitations on the=20 >> server.) Therefore, I suggest removing any hints about doing this=20 >> because there is not enough bandwidth. >I'm not sure I agree. There are plenty of scenarios where=20 >streaming is more network efficient. If someone sends me a=20 >very high definition movie or audio clip, but that clip is=20 >streamed to my device rather than retrieved, I can=20 >watch/listen to it in a fraction of the time it would have=20 >taken to download it, because streaming almost always means=20 >transcoding to a lower quality suitable for the device. Hmm, yes. But then I have to say that I do not know what You mean by constrained network. I've never seen a clip played without hickups - and in some cases I did not even want to watch it: having to wait 1-5secs for a few frames to arrive (video looks like a slideshow). I think streaming saves sudden spikes in bandwidth (a more balanced network utilization): download all vs. download frame-by-frame. But I guess arguing over this is not worth our time since it's not a major issue. >> 8. Question regarding Figure 1: Shouldn't all arrows be=20 >double-headed? > >Theoretically yes, but I hoping to make initiation implicitly clear. Could we decribe this fact somehow? (To aviod questions like mine.) >> 21. 2.5 last paragraph: >> 404 does not seem to be sufficient - a single status code=20 >covering all=20 >> possible errors is not very useful. Is there any way to indicate to=20 >> the client what very wrong (really)? > >Theoretically the media server could return a number of SIP=20 >error code, but this document doesn't attempt to cover all of=20 >them. It just explains what that particular error code means. It is more like an example then, right? Thank You Neil! _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Mar 30 04:05:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXC7I-0004wh-IO; Fri, 30 Mar 2007 04:05:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXC7H-0004wX-Lc for lemonade@ietf.org; Fri, 30 Mar 2007 04:05:47 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXC7F-0006t7-Jb for lemonade@ietf.org; Fri, 30 Mar 2007 04:05:47 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2U85ARt019257; Fri, 30 Mar 2007 11:05:43 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Mar 2007 11:05:38 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Mar 2007 11:05:38 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Open Issues with IMAP CONVERT Date: Fri, 30 Mar 2007 11:03:56 +0300 Message-ID: <4C38DC11F6B4FF4FAEA73E30DB5AA15743BC12@esebe199.NOE.Nokia.com> In-Reply-To: <460BDBF9.9040901@isode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Open Issues with IMAP CONVERT thread-index: AcdyF4nYaJvdzfDVTfa3It2zYgI03wAiFJOw References: <460A7A38.5000304@isode.com> <4C38DC11F6B4FF4FAEA73E30DB5AA1573FED5D@esebe199.NOE.Nokia.com> <460BDBF9.9040901@isode.com> From: To: X-OriginalArrivalTime: 30 Mar 2007 08:05:38.0190 (UTC) FILETIME=[33C0F2E0:01C772A2] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070330110543-425A8BB0-00D2F5DB/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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 Alexei, >>>2). draft -05 currently allows for default conversion (i.e.=20 >>>"just convert to any media type, you know best"). >>>I don't think this should be allowed and I suggest removing this=20 >>>feature from ABNF. >>> =20 >>> >>OMA has a requirement for the server making the decision=20 >(based on some=20 >>capability information about the client) and I think this is=20 >our "hook" >>to do that. Removing it would complicate our lives in OMA. I=20 >would like=20 >>to ask You to re-consider this proposal. >> =20 >> >Considering your anwer to the related question below, I am now=20 >Ok with keeping this. > >Is support for this feature optional for a general IMAP server? >I think the answer is "yes". But OMA can make this a required feature. It will be a MUST in OMA. You can mandate it, but I sense that this is something You would not want to do - and I have to agree since OMA will provide the means to get capability information about the client. >>>Somewhat related to this: is the server allowed to convert to=20 >>>image/png instead of image/jpeg when .STRICT suffix to=20 >CONVERT is not=20 >>>specified? (I don't think this should be allowed) >>> =20 >>> >>I don't think it should be allowed. >>In fact, I think STRICT should be removed and if the server cannot=20 >>fulfill the convert then it should fail the request. I think mosts=20 >>client would add it there anyway because they want exactly what they=20 >>asked for - and nothing else. If clients don't want to=20 >convert to some=20 >>specific type, they will let the server decide the best conversion. >> =20 >> >Your suggestion will work for me. It will certainly make the=20 >document simpler to read and implement. As long as my proposal is OK with everyone else. >>>3). There is one big issue surrounding INFORMATIONLOSS. I=20 >will publish=20 >>>an updated draft shortly, but it will not tackle this issue. I will=20 >>>try to address the issue in the subsequent revision. >>> =20 >>> >>Could You elaborate this, please? >> =20 >> >The issue is how the client can figure out which bodypart was=20 >converted with loss when the client requested multiple=20 >conversions in a single FETCH command. >Some suggested to use URLs to identify the bodypart. Arnt wrote the >following: > >> Serious: I don't like the INFORMATIONLOSS response code -=20 >it's on the=20 >> wrong response. As it stands, it means "one or more of the=20 >preceeding=20 >> untagged responses is approximate rather than exact". Either=20 >it should=20 >> be a flag on BODYPARTSTRUCTURE to show exactly which conversion is=20 >> approximate, or it should carry some arguments to specify=20 >the inexact=20 >> bodypart(s). Can we take a moment and think about why we need this? I mean I am not sure that we need this: - Probably no client will upscale->no loss. - Most clients will downscale -> there is always loss. - Some clients might use format/size conversions-> If client requests explicit conversion, it should be aware that there might be loss, while if the client left the conversion choice up to the server, it should assume that there was a loss. What do You think? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Mar 30 09:45:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXHQ1-0006Wv-JY; Fri, 30 Mar 2007 09:45:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXHQ0-0006Wo-9L for lemonade@ietf.org; Fri, 30 Mar 2007 09:45:28 -0400 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HXHPx-0008EC-NT for lemonade@ietf.org; Fri, 30 Mar 2007 09:45:28 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 30 Mar 2007 14:45:20 +0100 Message-ID: <460CCF33.6040705@isode.com> Date: Fri, 30 Mar 2007 09:49:55 +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: Zoltan.Ordogh@nokia.com Subject: Re: [lemonade] WGLC IMAP URL - update; comments References: <4C38DC11F6B4FF4FAEA73E30DB5AA1573FDF7B@esebe199.NOE.Nokia.com> In-Reply-To: <4C38DC11F6B4FF4FAEA73E30DB5AA1573FDF7B@esebe199.NOE.Nokia.com> 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: 3002fc2e661cd7f114cb6bae92fe88f1 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 Zoltan.Ordogh@nokia.com wrote: >Hi all, > Hi Zoltan, Thank you for the comments! I've addressed/replied to some of your comments, see below. I will deal with the rest of your comments later. >here are some comments for -04: >1. Possible typo in "3. IMAP userinfo component" -> iuserinfo? Or, does it mean userinfo of [URI-GEN]? > The section title should read: IMAP userinfo component (iuserinfo) [...] >4. Typo in section 3.2 first paragraph: "may contains" -> "may contain" > Fixed, thanks. >5. Caps use in section 3.2 first paragraph: "an IMAP user Name" > I lowercased Name. [...] >7. Clarification needed in section 3.2 paragraph 1: "They are used in the "LOGIN" or "AUTHENTICATE" commands after making the connection to the IMAP server." >What exactly does "They" refer to? > I've changed "They" to "The IMAP user name and the authentication mechanism". [...] >12. Wording change in section 3.2 paragraph 8: "care must be taken when resolving a URL which requires or requests any sort of authentication" Wouldn't there be an easier way to say this? > I think the "Since URLs can easily come from untrusted sources" part provides important background. I can move it till after the "Care must be taken ...". Would this be any better? [...] >15. Typo in section 3.2 paragraph 9: "SASL mechaninism" -> "SASL mechanism" > Fixed. [...] >20. Wording change suggesting in section 5, last paragraph: >"If it is not present, the contents of the mailbox SHOULD be presented by the program interpreting the URL." >-> >"If it is not present, all contents of the mailbox SHOULD be presented by the program interpreting the URL." > I will change this to "the entire content ..." instead. >21. Question about this requirement in section 6.1.1.2 paragraph 1: "MUST be unpredictable" >How can I verify that the random string that I have generated in unpredictable? > In general case you can't ;-). This requirement can't be externally verified, but it is needed to make sure that implementations don't use bad sources of randomness, such as rand() >22. Question for section 6.1.1.2 and 6.1.1.5. >Can these strings include spaces and other "fun stuff" > Yes. >that might break an IMAP URI? > ... but they wouldn't break IMAP URIs. Mailbox access key is never a part of an IMAP URI, so weird characters there don't matter. The URLAUTH token is always hex encoded. >I read no restriction here. Similarly, any considerations for UTF-8 here (I mean 128bit means something else using US-ASCII and UTF8)? I would expect at least a statement that the limitations described in [URLAUTH] apply here as well, no additional restrictions. > The text describing URLAUTH was taken from [URLAUTH], so there should be no differences. 2192bis should be self sufficient for understanding URLAUTH part of IMAP URLs. Let me know if it isn't. [...] >27. "Funny" line breaks in section 10.1 > Chris Newman has already reported this and I've fixed this in my copy. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Mar 30 09:45:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXHQ2-0006YC-OK; Fri, 30 Mar 2007 09:45:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXHQ1-0006Xj-Tl for lemonade@ietf.org; Fri, 30 Mar 2007 09:45:29 -0400 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HXHQ0-0008EN-J1 for lemonade@ietf.org; Fri, 30 Mar 2007 09:45:29 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 30 Mar 2007 14:45:20 +0100 Message-ID: <460CCB08.2000004@isode.com> Date: Fri, 30 Mar 2007 09:32:08 +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: Mark Crispin , Chris Newman Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: Lemonade WG Subject: [lemonade] 2192bis: URLAUTH in relative IMAP URLs 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, Is there any particular reason to allow relative IMAP URLs to contain URLAUTH signatures? (GENURLAUTH only uses absolute IMAP URLs, while CATENATE only uses relative IMAP URLs with no URLAUTH.) If not, I would like to remove the URLAUTH part from relative URLs in 2192bis. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Mar 30 13:32:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXKxL-0004sI-Eg; Fri, 30 Mar 2007 13:32:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXKxK-0004qu-Pa for lemonade@ietf.org; Fri, 30 Mar 2007 13:32:06 -0400 Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXKxG-0003bk-DM for lemonade@ietf.org; Fri, 30 Mar 2007 13:32:06 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l2UHVxLI011985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 30 Mar 2007 10:31: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.7+UW06.06/8.13.7+UW07.03) with ESMTP id l2UHVuNe008666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 30 Mar 2007 10:31:58 -0700 Date: Fri, 30 Mar 2007 10:31:56 -0700 (PDT) From: Mark Crispin To: Alexey Melnikov In-Reply-To: <460CCB08.2000004@isode.com> Message-ID: References: <460CCB08.2000004@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.3.30.102134 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: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Lemonade WG , Chris Newman Subject: [lemonade] Re: 2192bis: URLAUTH in relative IMAP URLs 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, 30 Mar 2007, Alexey Melnikov wrote: > Is there any particular reason to allow relative IMAP URLs to contain URLAUTH > signatures? (GENURLAUTH only uses absolute IMAP URLs, while CATENATE only > uses relative IMAP URLs with no URLAUTH.) If not, I would like to remove the > URLAUTH part from relative URLs in 2192bis. As far as I'm concerned, you can go ahead. But get other, more informed, input before doing so. -- 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 Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Mar 30 17:08:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXOJl-0003Sx-B1; Fri, 30 Mar 2007 17:07:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXOJj-0003Nx-Cw for lemonade@ietf.org; Fri, 30 Mar 2007 17:07:27 -0400 Received: from stiedprtick1-ext.va.neustar.com ([156.154.16.147] helo=ticket.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXOJj-0006YG-3N for lemonade@ietf.org; Fri, 30 Mar 2007 17:07:27 -0400 Received: from apache by ticket.ietf.org with local (Exim 4.43) id 1HXOJi-0000dk-Po for lemonade@ietf.org; Fri, 30 Mar 2007 17:07:27 -0400 From: "Liaison Statements via RT" In-Reply-To: Message-ID: Precedence: bulk X-RT-Loop-Prevention: Inquiry RT-Ticket: Inquiry #94503 Managed-by: RT 3.2.1 (http://www.bestpractical.com/rt/) RT-Originator: lemonade@ietf.org To: lemonade@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Fri, 30 Mar 2007 17:07:26 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Subject: [lemonade] [Inquiry #94503] AutoReply: Updated Liaison Statement, "Update on LEMONADE activity" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Reply-To: statements@ietf.org 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 Greetings, This message has been automatically generated in response to the creation of a ticket regarding: "Updated Liaison Statement, "Update on LEMONADE activity"", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [Inquiry #94503] in the queue: Liaison-Statements. Please include the string: [Inquiry #94503] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, statements@ietf.org ------------------------------------------------------------------------- Title: Update on LEMONADE activity Submission Date: 2007-03-29 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=309 Please reply by 2007-05-15 From: Glenn Parsons(IETF LEMONADE WG) To: OMA MEM(OMA-LIAISON@mail.openmobilealliance.org)) Cc: lemonade@ietf.org dean.willis@softarmor.com Chris.Newman@Sun.COM Reponse Contact: lemonade@ietf.org Technical Contact: gparsons@nortel.com eburger@bea.com Purpose: For action Body: The IETF LEMONADE working group (WG) would like to update you on our progress. Of note is that we have several RFCs that have already been approved and published: RFC 4467 – IMAP URL Authorization (URLAUTH) RFC 4468 – IMAP BURL RFC 4469 – IMAP CATENATE RFC 4550 – LEMONADE Profile RFC 4551 – IMAP Conditional STORE (CONDSTORE) RFC 4731 – IMAP ESEARCH Furthermore, the following documents have been essentially completed and are in the process of formal approval and publication: draft-vaudreuil-futuredelivery (SMTP Future Delivery) draft-ietf-lemonade-search-within (IMAP SEARCH WITHIN) draft-ietf-lemonade-deployments (for LEMONADE-compliant Mobile Email) draft-ietf-lemonade-compress (IMAP COMPRESS) draft-ietf-lemonade-reconnect-client (IMAP Quick Mailbox Resync) In addition, we are nearing completion on the rest of the documents in discussion in the WG. This includes IMAP CONVERT, IMAP notifications, and LEMONADE Profile-bis. We intend to conclude this work by June 2007. In the LEMONADE Notifications document (draft-ietf-lemonade- notifications) we have based ‘out of band’ notification on OMA E-Mail Notification (EMN). However, in the development of the functionality we have the need to identify items (such as message subject, date, sender, etc.) that are not part of the EMN mechanism. As a result, we have described these items as a different extended notification payload in addition to the base EMN payload. We understand that OMA MEM has been working with OMA BAC PUSH to validate our current approach and to extend EMN with these capabilities. We would appreciate a status on this activity. For the IMAP CONVERT protocol, the LEMONADE WG had agreed that the only ‘Mandatory to Implement’ conversion that will appear in the CONVERT protocol is HTML to TEXT. However, as we indicated previously the protocol itself can support any subset or even the entire OMA STI parameter suite, although we do not believe that support of the full list of OMA STI parameters is appropriate. The LEMONADE profile will not specify this list. We understand that OMA MEM would further subset the full list of STI parameters to make it realistic for the OMA mobile enabler. We would appreciate a status on this activity. As we had previously indicated, LEMONADE has conducted a preliminary interoperability event. Note that from an IETF perspective, our interest is only to facilitate protocol maturity. Specifically, that is to prove the feasibility of the protocol (which we have done with our preliminary event) and to document multiple interworking implementations to prove maturity (which we will do later this year). At our preliminary event nine entities participated with four test LEMONADE servers and numerous clients. The group tested these implementations against the LEMONADE Profile (RFC 4550) and identified some clarifications that were needed to make the specifications clear. The specific issues identified at the interop event have been used to update our documents. We expect that we will have another event later this year based on the published Profile-bis. We understand, from your earlier Liaison Statement, that this latter event would be of interest to OMA IOP. Finally, as you know, the work of the LEMONADE WG is focused on a set of extensions to IMAP and ESMTP to support mobile email. This set will be succinctly summarized in the LEMONADE profile (draft-ietf-lemonade- profile-bis). We understand that the OMA TS will normatively reference the LEMONADE profile for the MEM protocol. In order to help us understand your usage better, we would appreciate a presentation on the OMA MEM TS for LEMONADE. Would it be possible to have such a presentation at our next meeting? Up-to-date information on LEMONADE Internet-Drafts and RFCs can always be found at http://tools.ietf.org/wg/lemonade/ with additional information on our charter page http://www.ietf.org/html.charters/lemonade-charter.html Finally, as information, the next meetings of the IETF LEMONADE WG are: - Week of May 15 – LEMONADE interim – TBD - July 22-27 – IETF 69 plenary – Chicago Attachment(s): text of liaison (https://datatracker.ietf.org/documents/LIAISON/file410.pdf) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Mar 30 17:17:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXOT8-00028b-6O; Fri, 30 Mar 2007 17:17:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXOJf-0003No-Pe; Fri, 30 Mar 2007 17:07:23 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HXOJe-00010Y-E9; Fri, 30 Mar 2007 17:07:23 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns4.neustar.com (Postfix) with ESMTP id 5CCD02AC88; Fri, 30 Mar 2007 21:06:52 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1HXOJA-0007li-4v; Fri, 30 Mar 2007 17:06:52 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: statements@ietf.org From: Glenn Parsons (IETF LEMONADE WG) Message-Id: Date: Fri, 30 Mar 2007 17:06:52 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 X-Mailman-Approved-At: Fri, 30 Mar 2007 17:17:08 -0400 Cc: Subject: [lemonade] Updated Liaison Statement, "Update on LEMONADE activity" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lemonade@ietf.org 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 Title: Update on LEMONADE activity Submission Date: 2007-03-29 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=309 Please reply by 2007-05-15 From: Glenn Parsons(IETF LEMONADE WG) To: OMA MEM(OMA-LIAISON@mail.openmobilealliance.org)) Cc: lemonade@ietf.org dean.willis@softarmor.com Chris.Newman@Sun.COM Reponse Contact: lemonade@ietf.org Technical Contact: gparsons@nortel.com eburger@bea.com Purpose: For action Body: The IETF LEMONADE working group (WG) would like to update you on our progress. Of note is that we have several RFCs that have already been approved and published: RFC 4467 – IMAP URL Authorization (URLAUTH) RFC 4468 – IMAP BURL RFC 4469 – IMAP CATENATE RFC 4550 – LEMONADE Profile RFC 4551 – IMAP Conditional STORE (CONDSTORE) RFC 4731 – IMAP ESEARCH Furthermore, the following documents have been essentially completed and are in the process of formal approval and publication: draft-vaudreuil-futuredelivery (SMTP Future Delivery) draft-ietf-lemonade-search-within (IMAP SEARCH WITHIN) draft-ietf-lemonade-deployments (for LEMONADE-compliant Mobile Email) draft-ietf-lemonade-compress (IMAP COMPRESS) draft-ietf-lemonade-reconnect-client (IMAP Quick Mailbox Resync) In addition, we are nearing completion on the rest of the documents in discussion in the WG. This includes IMAP CONVERT, IMAP notifications, and LEMONADE Profile-bis. We intend to conclude this work by June 2007. In the LEMONADE Notifications document (draft-ietf-lemonade- notifications) we have based ‘out of band’ notification on OMA E-Mail Notification (EMN). However, in the development of the functionality we have the need to identify items (such as message subject, date, sender, etc.) that are not part of the EMN mechanism. As a result, we have described these items as a different extended notification payload in addition to the base EMN payload. We understand that OMA MEM has been working with OMA BAC PUSH to validate our current approach and to extend EMN with these capabilities. We would appreciate a status on this activity. For the IMAP CONVERT protocol, the LEMONADE WG had agreed that the only ‘Mandatory to Implement’ conversion that will appear in the CONVERT protocol is HTML to TEXT. However, as we indicated previously the protocol itself can support any subset or even the entire OMA STI parameter suite, although we do not believe that support of the full list of OMA STI parameters is appropriate. The LEMONADE profile will not specify this list. We understand that OMA MEM would further subset the full list of STI parameters to make it realistic for the OMA mobile enabler. We would appreciate a status on this activity. As we had previously indicated, LEMONADE has conducted a preliminary interoperability event. Note that from an IETF perspective, our interest is only to facilitate protocol maturity. Specifically, that is to prove the feasibility of the protocol (which we have done with our preliminary event) and to document multiple interworking implementations to prove maturity (which we will do later this year). At our preliminary event nine entities participated with four test LEMONADE servers and numerous clients. The group tested these implementations against the LEMONADE Profile (RFC 4550) and identified some clarifications that were needed to make the specifications clear. The specific issues identified at the interop event have been used to update our documents. We expect that we will have another event later this year based on the published Profile-bis. We understand, from your earlier Liaison Statement, that this latter event would be of interest to OMA IOP. Finally, as you know, the work of the LEMONADE WG is focused on a set of extensions to IMAP and ESMTP to support mobile email. This set will be succinctly summarized in the LEMONADE profile (draft-ietf-lemonade- profile-bis). We understand that the OMA TS will normatively reference the LEMONADE profile for the MEM protocol. In order to help us understand your usage better, we would appreciate a presentation on the OMA MEM TS for LEMONADE. Would it be possible to have such a presentation at our next meeting? Up-to-date information on LEMONADE Internet-Drafts and RFCs can always be found at http://tools.ietf.org/wg/lemonade/ with additional information on our charter page http://www.ietf.org/html.charters/lemonade-charter.html Finally, as information, the next meetings of the IETF LEMONADE WG are: - Week of May 15 – LEMONADE interim – TBD - July 22-27 – IETF 69 plenary – Chicago Attachment(s): text of liaison (https://datatracker.ietf.org/documents/LIAISON/file410.pdf) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sat Mar 31 06:28:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXaoL-00009T-4x; Sat, 31 Mar 2007 06:27:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXaoJ-00009O-L8 for lemonade@ietf.org; Sat, 31 Mar 2007 06:27:51 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXaoI-00033F-84 for lemonade@ietf.org; Sat, 31 Mar 2007 06:27:51 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2VARlIf010760; Sat, 31 Mar 2007 13:27:48 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 31 Mar 2007 13:27:47 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 31 Mar 2007 13:27:47 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] WGLC IMAP URL - update; comments Date: Sat, 31 Mar 2007 13:26:05 +0300 Message-ID: <4C38DC11F6B4FF4FAEA73E30DB5AA15743C211@esebe199.NOE.Nokia.com> In-Reply-To: <460CCF33.6040705@isode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] WGLC IMAP URL - update; comments thread-index: Acdy0a3oOt98nhkuSA+xqq+jeFol/QAq+xBQ References: <4C38DC11F6B4FF4FAEA73E30DB5AA1573FDF7B@esebe199.NOE.Nokia.com> <460CCF33.6040705@isode.com> From: To: X-OriginalArrivalTime: 31 Mar 2007 10:27:47.0271 (UTC) FILETIME=[39E52D70:01C7737F] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070331132748-2490CBB0-18D409FB/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Alexei, thank You for all fixes. Here are some futher comments on the open ones: >>12. Wording change in section 3.2 paragraph 8: "care must be=20 >taken when resolving a URL which requires or requests any sort=20 >of authentication" Wouldn't there be an easier way to say this? >> >I think the "Since URLs can easily come from untrusted=20 >sources" part provides important background. I can move it=20 >till after the "Care must be taken ...". Would this be any better? > [...] The part I do not like is "Care must be taken" it does not sound right to me, especially at the beginning of a sentence - however I can understand what it means. Perhaps a native English speaker can respond on this? >>21. Question about this requirement in section 6.1.1.2=20 >paragraph 1: "MUST be unpredictable" >>How can I verify that the random string that I have generated=20 >in unpredictable? =20 >> >In general case you can't ;-). > >This requirement can't be externally verified, but it is=20 >needed to make sure that implementations don't use bad sources=20 >of randomness, such as >rand() Wouldn't it be better to describe this (instead of requiring something that cannot be verified)? Thank You. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade