From owner-ietf-imap-voice Tue Jan 5 19:38:20 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA28566 for ietf-imap-voice-bks; Tue, 5 Jan 1999 19:38:20 -0800 (PST) Received: from mail.mediagate.com (depot.mediagate.com [209.157.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA28559 for ; Tue, 5 Jan 1999 19:38:19 -0800 (PST) Received: from mediagate.com ([209.157.115.120]) by mail.mediagate.com (1.0.242) for ietf-imap-voice@imc.org; 5 Jan 1999 19:25:30 -0800 Message-ID: <3692D8DC.6B70A997@mediagate.com> Date: Tue, 05 Jan 1999 19:30:36 -0800 From: Jutta Degener Organization: IRDG, Inc. X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: ietf-imap-voice@imc.org Subject: Welcome to ietf-imap-voice! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imap-voice@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Welcome to the ietf-imap-voice mailing list. This is an unmoderated mailing list for the discussion of IMAP4 extensions for binary and streaming media. The list is concerned with issues such as: - Binary messages or message parts. - Transfer to clients other than the IMAP client, or from servers other than the IMAP server. - Streaming media attachments. - Server-side conversion and transcoding. - Integration of user-level message length indicators. Our initial goal is to write drafts for IMAP4 extensions where appropriate, and to discuss these drafts and other ideas at a BOF at the next IETF conference. Thanks to Paul Hoffman of the Internet Mail Consortium for hosting both the mailing list and the web page. Enjoy, Jutta Degener From owner-ietf-imap-voice Fri Jan 15 10:05:40 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23724 for ietf-imap-voice-bks; Fri, 15 Jan 1999 08:44:12 -0800 (PST) Received: (from phoffman@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23656; Fri, 15 Jan 1999 08:43:39 -0800 (PST) Date: Fri, 15 Jan 1999 08:43:39 -0800 (PST) Message-Id: <199901151643.IAA23656@mail.proper.com> From: List Manager of ietf-imap-voice To: ietf-imap-voice@imc.org Subject: How to be removed from this list Sender: owner-ietf-imap-voice@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Greetings again. Occasionally, people will sign up for a mailing list and forget how to be removed. This message is a reminder for those folks. First off, when you subscribe to a mailing list, you almost always get a first message from the list owner telling you about the mailing list, and explaining how to unsubscribe. It is always a good idea to keep those messages, since you never know when you will need to unsubscribe. This is particularly useful when you change email addresses, because it is difficult to unsubscribe from a list after you have a different mailing address. In the case of this list, the method to unsubscribe is to send a message to: ietf-imap-voice-request@imc.org with the single word: unsubscribe in the body of the message. This is the same as it always has been. To make this easier for you, I have crafted this message so that you should be able to simply reply to this message, and the reply address should be ietf-imap-voice-request@imc.org (although some mail clients screw this up...). Remove everything from the body of the reply, and put in the single word: unsubscribe If you have tried this method, and the mailing list software won't let you unsubscribe, it is probably because your address has changed. In that case, please send a message to subs@imc.org stating which list (or lists) you want to unsubscribe from, and what you think your previous address was. There is a human (that's me!) who will then try to take care of your request, often within a few days. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-imap-voice Fri Feb 26 12:42:05 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA05427 for ietf-imap-voice-bks; Fri, 26 Feb 1999 12:42:05 -0800 (PST) Received: from smtprich.nortel.com (smtprich.nortel.com [192.135.215.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA05423 for ; Fri, 26 Feb 1999 12:42:04 -0800 (PST) Received: from zrchb213.us.nortel.com (actually 47.100.128.42) by smtprich.nortel.com; Fri, 26 Feb 1999 14:46:51 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2232.9) id ; Fri, 26 Feb 1999 14:45:48 -0600 Message-ID: From: "Glenn Parsons" To: ietf-imap-voice@imc.org Cc: "'vpim-l@ema.org'" Subject: draft-ema-vpim-imap-00.txt Date: Fri, 26 Feb 1999 14:45:43 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BE61C8.FBA4525A" X-Orig: Sender: owner-ietf-imap-voice@imc.org Precedence: bulk List-Archive: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BE61C8.FBA4525A Content-Type: text/plain Folks, I was meaning to send the minutes from the December BOF to this list, but as I finally got around to putting them together (since I never really took many notes -- nor did anyone else I think) it made more sense to just summarize the issues and the current suggestions and post them as a draft. So that's what I did. I posted the draft today (and attached it here) that covers the topics mentioned by Jutta in the intro message last month. All of the suggestions for each of the IMAP voice extension topics were discussed in December. Please review and comment. Do folks think that we need another informal BOF or should we work the details out on the list? Cheers, Glenn. <> -------------------------------------------------------- Glenn Parsons Internet Messaging Standards Nortel Networks Phone: +1-613-763-7582 Ottawa, Ontario, CANADA G3fax: +1-613-763-2697 Email: Glenn.Parsons@NortelNetworks.com ------_=_NextPart_000_01BE61C8.FBA4525A Content-Type: application/applefile; name="draft-ema-vpim-imap-00.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-ema-vpim-imap-00.txt" Content-Location: ATT-0-414DB762B8CDD211A19D0000F81ABA04-D RAFT-EM.TXT AAUWAAACAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAASgAAABAAAAAJAAAAWgAAACAAAAADAAAA egAAABoAAAABAAAAlAAAMM2y/G2vsvxtrwAAAAAAAAAAVEVYVFIqY2gAAf////8AAAAAAAAAAAAA AAAAAAAAAABkcmFmdC1lbWEtdnBpbS1pbWFwLTAwLnR4dCAgICAgSW50ZXJuZXQgRHJhZnQgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgR2xlbm4gUGFyc29ucw0gICAgIEV4 cGlyZXMgaW4gc2l4IG1vbnRocyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOb3J0ZWwg TmV0d29ya3MNICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEZlYnJ1YXJ5IDI2LCAxOTk5DQ0gICAgICAgICAgICAgICAgICAgSU1BUCBWb2ljZSBF eHRlbnNpb25zDSAgICAgICAgICAgICAgICA8ZHJhZnQtZW1hLXZwaW0taW1hcC0wMC50eHQ+DQ0g ICBTdGF0dXMgb2YgdGhpcyBNZW1vDQ0gICAgIFRoaXMgZG9jdW1lbnQgaXMgYW4gSW50ZXJuZXQt RHJhZnQgYW5kIGlzIGluIGZ1bGwgY29uZm9ybWFuY2UNICAgICB3aXRoIGFsbCBwcm92aXNpb25z IG9mIFNlY3Rpb24gMTAgb2YgUkZDMjAyNi4NDSAgICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3Jr aW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcNICAgICBUYXNrIEZvcmNl IChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0IA0g ICAgIG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFz IA0gICAgIEludGVybmV0LURyYWZ0cy4NDSAgICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBk b2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggDSAgICAgb250aHMgYW5kIG1heSBi ZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyANICAg ICBhdCBhbnkgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0 cyBhcyANICAgICByZWZlcmVuY2UgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4g YXMgIndvcmsgaW4gDSAgICAgcHJvZ3Jlc3MuIg0NICAgICBUaGUgbGlzdCBvZiBjdXJyZW50IElu dGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQNICAgICBodHRwOi8vd3d3LmlldGYub3Jn L2lldGYvMWlkLWFic3RyYWN0cy50eHQNDSAgICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQg U2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA0gICAgIGh0dHA6Ly93d3cuaWV0 Zi5vcmcvc2hhZG93Lmh0bWwuDQ0gICAxLiAgQWJzdHJhY3QgDQ0gICAgIFRoaXMgZG9jdW1lbnQg aXMgYW4gb3ZlcnZpZXcgb2YgcHJvcG9zYWxzIGZvciB2YXJpb3VzIGV4dGVuc2lvbnMgdG8gDSAg ICAgSU1BUCB0byBtZWV0IHRoZSByZXF1aXJlbWVudHMgb2Ygdm9pY2UgbWFpbCBzeXN0ZW1zLiAg VGhlIHRvcGljcyANICAgICBpbmNsdWRlZCBhcmUgDSAgICAgLSBCaW5hcnkgQXR0YWNobWVudCB0 cmFuc2Zlcg0gICAgIC0gRXh0ZXJuYWwgUmVmZXJlbmNlIA0gICAgIC0gQWx0ZXJuYXRlIENvZGVj IFJlcXVlc3QNICAgICAtIFN0cmVhbWluZyBhdWRpbyBhdHRhY2htZW50cw0gICAgIC0gTWVzc2Fn ZSBsZW5ndGggSW5kaWNhdG9yDSAgICAgLSBCb2R5IHBhcnQgcmVhZCBpbmRpY2F0b3INDSAgIDIu ICBJbnRyb2R1Y3Rpb24NDSAgICAgVGhpcyBJbnRlcm5ldCBEcmFmdCBzdW1tYXJpemVzIHRoZSBw cm9wb3NlZCBleHRlbnNpb25zIGFzIGRpc2N1c3NlZCANICAgICBhdCB0aGUgSU1BUC1WT0lDRSBp bmZvcm1hbCBCT0YgYXQgSUVURiwgT3JsYW5kbywgRGVjZW1iZXIgMTk5OC4NDSAgICAgSU1BUC1W T0lDRSBpcyBhIEJPRiBmb3IgZGlzY3Vzc2lvbiBvZiBleHRlbnNpb25zIHRvIElNQVA0IGluIA0g ICAgIHN1cHBvcnQgb2Ygdm9pY2UgbWVzc2FnaW5nIGFwcGxpY2F0aW9ucywgYW5kIHRoZSBzdGFu ZGFyZGl6YXRpb24gb2YgDSAgICAgdGhlc2UgaW4gdGhlIElFVEYuIEZvciBtb3JlIGluZm9ybWF0 aW9uIHNlZSANICAgICBodHRwOi8vd3d3LmltYy5vcmcvaWV0Zi1pbWFwLXZvaWNlLw0NICAgICBW b2ljZSBtZXNzYWdpbmcgdHJhbnNwb3J0IG92ZXIgSW50ZXJuZXQgTWFpbCBpcyBkZWZpbmVkIGJ5 IFZQSU0gdjIgDSAgICAgKFJGQyAyNDIxKVsxXS4gIFRoZSBWUElNIGVmZm9ydCBpcyBsZWQgYnkg dGhlIFZQSU0gV29ya2luZyBHcm91cCAgDSAgICAgd2l0aGluIHRoZSBFbGVjdHJvbmljIE1lc3Nh Z2luZyBBc3NvY2lhdGlvbi4gRm9yIG1vcmUgaW5mb3JtYXRpb24gDSAgICAgc2VlIGh0dHA6Ly93 d3cuZW1hLm9yZy92cGltLy4NDSAgICAgUGFyc29ucyAgICAgICAgICAgICAgICAgRXhwaXJlcyA4 LzI2Lzk5ICAgICAgICAgICAgICAgICAgICBbUGFnZSAxXQ0MICAgICBJbnRlcm5ldCBEcmFmdCAg ICAgICAgICAgICAgIElNQVAgVm9pY2UgICAgICAgICAgIEZlYnJ1YXJ5IDI2LCAxOTk5DQ0gICAz LiAgQ29udmVudGlvbnMgVXNlZCBpbiB0aGlzIERvY3VtZW50DQ0gICAgIEluIGV4YW1wbGVzLCAi QzoiIGFuZCAiUzoiIGluZGljYXRlIGxpbmVzIHNlbnQgYnkgdGhlIGNsaWVudCBhbmQNICAgICBz ZXJ2ZXIgcmVzcGVjdGl2ZWx5LiANDSAgICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5P VCIsICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsIGFuZCAiTUFZIg0gICAgIGluIHRoaXMgZG9jdW1l bnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlZmluZWQgaW4gIktleSB3b3JkcyBmb3INICAg ICB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZSBSZXF1aXJlbWVudCBMZXZlbHMiIFsyXS4NDSAgIDQu ICBCaW5hcnkgQXR0YWNobWVudCBIZWFkZXINDSAgICAgU2luY2UgVlBJTSBvcHRpb25hbGx5IHN1 cHBvcnRzIGJpbmFyeSBhdHRhY2htZW50cywgYW5kIHNpbmNlIGl0IG1heSANICAgICBiZSBiZW5l ZmljaWFsIGZvciB0aGUgY2xpZW50IG5vdCB0byBkZWNvZGUgYmFzZTY0IGVuY29kZWQgYXVkaW8s IGl0IA0gICAgIGlzIGRlc2lyYWJsZSB0byBoYXZlIGEgbWV0aG9kIG9mIHJldHJpZXZpbmcgYmlu YXJ5IGJvZHkgcGFydHMgaW4gDSAgICAgSU1BUC4gIE5vdGUgdGhhdCB0aGlzIHdvdWxkIGJlIG5p Y2UgdG8gaGF2ZSwgaG93ZXZlciBpdCBpcyANICAgICBub3QgbmVlZGVkIGZvciB2b2ljZSBtZXNz YWdpbmcuICBPbmUgc3VnZ2VzdGlvbiBmb3IgYWNjb21wbGlzaGluZyANICAgICB0aGlzIGlzOg0N ICAgNC4xICBBIERBVEEgc3VmZml4IGluc2lkZSBhIEZFVENIIEJPRFlbXSBjb25zdHJ1Y3QNDSAg ICAgSXRzIHN5bnRheCB3b3VsZCBiZSBzaW1pbGFyIHRvIHRoYXQgb2YgSEVBREVSLkZJRUxEUyBh cyBkZXNjcmliZWQgDSAgICAgaW4gSU1BUDRyZXYxIFszXS4NDSAgICAgVGhlIERBVEEgcGFydCBz cGVjaWZpZXIgTVVTVCBiZSBwcmVmaXhlZCBieSBvbmUgb3IgbW9yZSBudW1lcmljIA0gICAgIHBh cnQgc3BlY2lmaWVycy4NDSAgICAgQzogYWJjIEZFVENIIDEgKEJPRFlbMS4yLkRBVEEoRU5DT0RJ TkcgQklOQVJZKV0pDQ0gICAgIFRoZSBrZXl3b3JkIEVOQ09ESU5HIHNlbGVjdHMgZW5jb2Rpbmcg YXMgZGVmaW5lZCBpbiB0aGUgTUlNRSANICAgICBDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nIEhl YWRlciBGaWVsZC4gWzRdDQ0gICAgIFNlcnZlcnMgdGhhdCBzdXBwb3J0IHRoZSBEQVRBIHBhcnQg c3BlY2lmaWVyIFNIT1VMRCBsaXN0IHRoZSBEQVRBIA0gICAgIGNhcGFiaWxpdHkgaW4gcmVzcG9u c2UgdG8gdGhlIENBUEFCSUxJVFkgY29tbWFuZC4NDSAgIDUuICBFeHRlcm5hbCBSZWZlcmVuY2UN DSAgICAgVG8gbWVldCB0aGUgcmVxdWlyZW1lbnRzIG9mIHZvaWNlbWFpbCBzeXN0ZW1zLCB0aGVy ZSBpcyBhIG5lZWQgdG8gDSAgICAgc3VwcG9ydCBleHRlcm5hbCByZWZlcmVuY2UsIHN1Y2ggYXMg dXNpbmcgYSB0ZWxlcGhvbmUgZm9yIHBsYXliYWNrIA0gICAgIG9mIHZvaWNlIG1lc3NhZ2VzLiAg VGhyZWUgc3VnZ2VzdGlvbnMgb2YgaG93IHRoaXMgY2FuIGJlIA0gICAgIGFjY29tcGxpc2hlZCBh cmU6DQ0gICA1LjEgIFVzZSBvZiBhbiBleHRlcm5hbCByZWZlcmVuY2UgbWVjaGFuaXNtIHJlcXVp cmVzIHNwbGl0IGNsaWVudCANICAgICBzdXBwb3J0IGZvciBSZWFsIFRpbWUgU3RyZWFtaW5nIFBy b3RvY29sIChSVFNQKSBhcyB3ZWxsIGFzIElNQVAuDQ0gICAgIElmIHVzaW5nIGFuIGV4dGVybmFs IG1lY2hhbmlzbSBmb3IgcGxheWJhY2ssIGltcGxlbWVudGF0aW9ucyBtYXkgDSAgICAgdXNlIFJU U1AgYXMgZGVzY3JpYmVkIGluIFJGQyAyMzI2IFs1XSwgYXMgdGhlIGNvbnRyb2wgcHJvdG9jb2wg ZnJvbSANICAgICB0aGUgY2xpZW50IHRvIGEgcHJveHkgc2VydmVyLiAoV2hpY2ggY291bGQgbWFr ZSB0aGUgb3V0Y2FsbCB0byB0aGUgDSAgICAgcGhvbmUpDQ0gICAgIFBhcnNvbnMgICAgICAgICAg ICAgICAgICBFeHBpcmVzIDgvMjYvOTkgICAgICAgICAgICAgICAgICAgW1BhZ2UgMl0NDCAgICAg SW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICBJTUFQIFZvaWNlICAgICAgICAgICBGZWJydWFy eSAyNiwgMTk5OQ0NICAgNS4yICBBIG5ldyBvcHRpb25hbCBrZXl3b3JkIFRPIGluIHRoZSBEQVRB IHBhcnQgc3BlY2lmaWVyLCBhcyANICAgICBkZXNjcmliZWQgaW4gNC4xLCBpcyBhY2NvbXBhbmll ZCBieSBVUkwgZm9yIHdoaWNoIHRvIHNlbmQgdGhlIGRhdGEuIA0gICAgIFRoZSBVUkwgIGJlZ2lu cyB3aXRoIGEgcHJvdG9jb2wuDQ0gICAgIEM6IGFiYyBGRVRDSCAxIChCT0RZWzEuMi5EQVRBKFRP ICJydHA6MTU1LjUuMS4yMzo0NTY3IildKQ0NICAgNS4zICBJTUFQIFVSTHMgY2FuIGJlIHVzZWQg dG8gcmVmZXJlbmNlIHRoZSBtZXNzYWdlIG9uIHRoZSBJTUFQIA0gICAgIHNlcnZlciBhcyAJZGVz Y3JpYmVkIGluIHRoZSBJTUFQIFVSTCBTY2hlbWUgWzZdLg0NICAgICBUaGUgSU1BUCBVUkwgZm9y IGEgc3BlY2lmaWMgbWVzc2FnZSBvciBtZXNzYWdlIHBhcnQgaGFzIHRoZSANICAgICBmb2xsb3dp bmcgZm9ybToNDSAgICAgaW1hcDovLzxpc2VydmVyPi88ZW5jX21haWxib3g+W3VpZHZhbGlkaXR5 XTxpdWlkPltpc2VjdGlvbl0NDSAgIDYuICBBbHRlcm5hdGUgQ29kZWMgUmVxdWVzdCANDSAgICAg Q2xpZW50cyB0b2RheSBhcmUgdXNpbmcgbWFueSBkaWZmZXJlbnQgdHlwZXMgb2YgY29kZWNzLiAg QmVjYXVzZSBvZiANICAgICB0aGlzLCB0aGVyZSBpcyBhIGRlc2lyZSB0byBoYXZlIHRoZSBzZXJ2 ZXIgdHJhbnNjb2RlIGFuZCBwcmVzZW50IA0gICAgIHRoZSBtZXNzYWdlIGluIHRoZSBhcHByb3By aWF0ZSBjb2RlYyBmb3IgdGhhdCBjbGllbnQuICBUaGVyZSBhcmUgDSAgICAgdHdvIHN1Z2dlc3Rp b25zIGZvciBhY2NvbXBsaXNoaW5nIHRoaXM6DQ0gICA2LjEgIFRoZSByZWNlaXZpbmcgSU1BUCBT ZXJ2ZXIgc2hvdWxkIGNyZWF0ZSBtdWx0aXBhcnQvYWx0ZXJuYXRpdmUgb24gDSAgICAgcmVjZXB0 aW9uIAl3aXRoIHN1cHBvcnQgZm9yICAnbiBjb2RlY3MnIHdoZXJlICduIGNvZGVjcycgYXJlIHRo ZSANICAgICBjb2RlY3Mgc3VwcG9ydGVkIGF0IHRoYXQgc2VydmVyLiAgVGhlIGNsaWVudCB3b3Vs ZCB0aGVuIGhhdmUgdGhlIA0gICAgIG9wdGlvbiBvZiBjaG9vc2luZyB0aGUgY29kZWMgdGhhdCBp dCBzdXBwb3J0cy4NDSAgIDYuMiAgT3B0aW9uYWwga2V5d29yZCBUWVBFIGluIHRoZSBEQVRBIHN1 ZmZpeCAoYXMgZGVzY3JpYmVkIGluIDQuMSksIA0gICAgIGlmIHByZXNlbnQsIHJlcXVlc3RzIGNv bnZlcnNpb24gb2YgdGhlIGNvbnRlbnQgaW50byB0aGUgc3BlY2lmaWVkIA0gICAgIHR5cGUuDQ0g ICAgIEM6IGFiYyBGRVRDSCAxIChCT0RZW0RBVEEoRU5DT0RJTkcgQklOQVJZIFRZUEUoIkFVRElP IiAiR1NNIikpXSkNDSAgICAgSWYgdGhlIHNlcnZlciBjYW4ndCBhY2NvbXBsaXNoIHRoZSBjb252 ZXJzaW9uLCB0aGUgRkVUQ0ggZmFpbHMuDQ0gICA3LiAgU3RyZWFtaW5nIEF1ZGlvIEF0dGFjaG1l bnRzDQ0gICAgIFN0cmVhbWluZyBpcyBuZWVkZWQgaW4gc3VjaCBjYXNlcyBvZiBsYXJnZSBhdWRp byBhdHRhY2htZW50cywgc21hbGwgDSAgICAgY2xpZW50cywgc2xvdyBsaW5rcyB0byBhbGxvdyB0 aGUgdXNlciB0byBsaXN0ZW4gdG8gdGhlIG1lc3NhZ2UgYXMgDSAgICAgaXQgaXMgYmVpbmcgZG93 bmxvYWRlZCwgcmF0aGVyIHRoYW4gaGF2aW5nIHRvIGRvd25sb2FkIHRoZSB3aG9sZSANICAgICBt ZXNzYWdlIGZpcnN0LiAgT25lIHN1Z2dlc3Rpb24gZm9yIGFjY29tcGxpc2hpbmcgdGhpcyBpczoN DSAgIDcuMSAgVGhlIHN0cmVhbWluZyBvZiBhdWRpbyBhdHRhY2htZW50cyBjYW4gYmUgZG9uZSB1 c2luZyB3aW5kb3dpbmcuIA0NICAgICBGRVRDSCBCT0RZW108PHBhcnRpYWw+Pg0NICAgICBTb21l IGlzc3VlcyBjb25jZXJuaW5nIHN0cmVhbWluZyBieSB3aW5kb3dpbmcgYXJlIA0gICAgIC0gbGF0 ZW5jeSANICAgICAtIG5vIHNldCB3aW5kb3cgc2l6ZS4NDSAgICAgUGFyc29ucyAgICAgICAgICAg ICAgICAgRXhwaXJlcyA4LzI2Lzk5ICAgICAgICAgICAgICAgICAgICBbUGFnZSAzXQ0MICAgICBJ bnRlcm5ldCBEcmFmdCAgICAgICAgICAgICAgIElNQVAgVm9pY2UgICAgICAgICAgIEZlYnJ1YXJ5 IDI2LCAxOTk5DQ0gICA4LiAgTWVzc2FnZSBMZW5ndGggSW5kaWNhdG9yDQ0gICAgIEluIHRoZSBj YXNlcyBvZiBsYXJnZSBhdHRhY2htZW50cywgc21hbGwgY2xpZW50cyBhbmQgc2xvdyBsaW5rcyAN ICAgICB0aGVyZSBpcyBhbHNvIGEgbmVlZCBmb3IgdGhlIGNsaWVudCB0byBzZWUgdGhlIGxlbmd0 aCBvZiB0aGUgDSAgICAgbWVzc2FnZSBpbiBhIHN1aXRhYmxlIGZvcm1hdCBiZWZvcmUgb3Blbmlu ZyBpdC4gDQ0gICAgIEEgbWVzc2FnZSBsZW5ndGggaW5kaWNhdG9yIHN1aXRhYmxlIGZvciB2b2lj ZW1haWwgYW5kIGZheCBzaG91bGQgDSAgICAgaW5kaWNhdGUgdGhlIGxlbmd0aCBvZiB0aGUgbWVz c2FnZSB1c2luZyBudW1iZXIgb2Ygc2Vjb25kcyBmb3IgYSANICAgICB2b2ljZSBtZXNzYWdlIGFu ZCB1c2luZyBudW1iZXIgb2YgcGFnZXMgZm9yIGEgZmF4IG1lc3NhZ2UuICBUaGUgDSAgICAgY2xp ZW50IE1VU1Qgc3VwcG9ydCB0aGUgY2hvc2VuIG1ldGhvZC4gIFRoZXJlIGFyZSB0aHJlZSBzdWdn ZXN0ZWQgDSAgICAgbWV0aG9kczoNDSAgIDguMSAgTUlNRSBIZWFkZXIgQ29udGVudC1EdXJhdGlv biBhcyBkZXNjcmliZWQgaW4gUkZDIDI0MjQgWzddDQ0gICAgIEZvciBmYXggbWVzc2FnZXMgYSBu ZXcgTUlNRSBIZWFkZXIsIENvbnRlbnQtUGFnZS1MZW5ndGgsIHdvdWxkIGJlIA0gICAgIGRlZmlu ZWQsIHNpbWlsYXIgdG8gQ29udGVudC1EdXJhdGlvbiB3aXRoIHRoZSBleGNlcHRpb24gdGhhdCBu dW1iZXIgDSAgICAgb2YgcGFnZXMgd291bGQgYmUgc3BlY2lmaWVkLCByYXRoZXIgdGhhbiBudW1i ZXIgb2Ygc2Vjb25kcy4gKGUuZy4gDSAgICAgQ29udGVudC1QYWdlLUxlbmd0aDozKS4gIFRoaXMg d291bGQgYmUgY3JlYXRlZCBhdCBvcmlnaW5hdG9yLg0NICAgOC4yICBGRVRDSCBpdGVtIFVTRVJT SVpFIHNpbWlsYXIgdG8gRkVUQ0ggaXRlbXMgZGVzY3JpYmVkIGluIA0gICAgIElNQVA0cmV2MSBb M10uICBUaGlzIHdvdWxkIGJlIGNyZWF0ZWQgYXQgcmVjZXB0aW9uLg0NICAgOC4yLjEgIFVTRVJT SVpFIGlzIGEgbm9uLW5lZ2F0aXZlIG51bWJlci4gIEl0cyBtZWFuaW5nIGRlcGVuZHMgb24gDSAg ICAgZG9jdW1lbnQgdHlwZS4NDSAgICAgQzogYWJjIEZFVENIIDE6MiAoVVNFUlNJWkUpDSAgICAg UzogKjEgRkVUQ0ggKDEyKQ0gICAgIFM6ICoyIEZFVENIICg1NykNICAgICBTOiBhYmMgRkVUQ0gg Y29tcGxldGVkLg0NICAgOC4yLjIgIFVTRVJTSVpFIGlzIGEgcGFpciBvZiBudW1iZXIgYW5kIHVu aXQuICBUaGVyZSBpcyBhIHNtYWxsIHNldCANICAgICBvZiB1bml0IHRva2Vucy4NDSAgICAgQzog YWJjIEZFVENIIDE6MiAoVVNFUlNJWkUpDSAgICAgUzogKjEgRkVUQ0ggKDEyIHBhZ2VzKQ0gICAg IFM6ICoyIEZFVENIICg1NyBzZWNvbmRzKQ0gICAgIFM6IGFiYyBGRVRDSCBjb21wbGV0ZWQuDQ0g ICA4LjIuMyAgVVNFUlNJWkUgaXMgYSBzZXF1ZW5jZSBvZiBwYWlycywgaW4gY2FzZSBzb21ldGhp bmcgZXh0ZW5kcyBpbg0gICAgIG1vcmUgdGhhbiAJb25lIHVuaXQuDQ0gICAgIEM6IGFiYyBGRVRD SCAxOjIgKFVTRVJTSVpFKQ0gICAgIFM6ICoxIEZFVENIICgxMiBsaW5lcykNICAgICBTOiAqMSBG RVRDSCAoNTcgcGFnZXMgNiBob3VycykNICAgICBTOiBhYmMgRkVUQ0ggY29tcGxldGVkLg0NICAg ICBTZXJ2ZXJzIHRoYXQgc3VwcG9ydCBVU0VSU0laRSBTSE9VTEQgbGlzdCB0aGUgVVNFUlNJWkUg Y2FwYWJpbGl0eSANICAgICBpbiByZXNwb25zZSB0byB0aGUgQ0FQQUJJTElUWSBjb21tYW5kLg0N ICAgICBQYXJzb25zICAgICAgICAgICAgICAgICBFeHBpcmVzIDgvMjYvOTkgICAgICAgICAgICAg ICAgICAgIFtQYWdlIDRdDQwgICAgIEludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgSU1BUCBW b2ljZSAgICAgICAgICAgRmVicnVhcnkgMjYsIDE5OTkNDSAgIDguMyAgTWVzc2FnZSBsZW5ndGgg aW5kaWNhdGVkIGFzIGEgcGFyYW1ldGVyIG9mIHRoZSBDb250ZW50LVR5cGUgDSAgICAgSGVhZGVy IEZpZWxkIFs0XS4gIFRoaXMgd291bGQgYmUgY3JlYXRlZCBhdCB0aGUgc291cmNlLiAgVGhpcyAN ICAgICBtZXRob2Qgd291bGQgYWxsb3cgdGhlIG1lc3NhZ2UgbGVuZ3RoIHRvIGJlIHBhc3NlZCB0 byB0aGUgY2xpZW50IGJ5IA0gICAgIGRlZmF1bHQuIA0NICAgICBDb250ZW50LVR5cGU9YXVkaW8v KjsgbGVuZ3RoPTUwDSAgICAgQ29udGVudC1UeXBlPWltYWdlL3RpZmY7IHBhZ2VzPTMNDSAgIDku ICBCb2R5IFBhcnQgUmVhZCBJbmRpY2F0b3INDSAgICAgV2l0aCB0aGUgdXNlIG9mIG11bHRpcGFy dCBtZXNzYWdlcyB0aGVyZSBzaG91bGQgYmUgYSBzZXBhcmF0ZSBCT0RZIA0gICAgIFBBUlQgUkVB RCBpbmRpY2F0b3IgZm9yIGVhY2ggYm9keSBwYXJ0IG9yLCBhdCBsZWFzdCwgdG8gb25seSANICAg ICBpbmRpY2F0ZSBSRUFEIHdoZW4gdGhlIHByaW1hcnkgYm9keSBwYXJ0IGhhcyBiZWVuIHJlYWQu IFRoZXJlIGFyZSANICAgICB0d28gc3VnZ2VzdGVkIG1ldGhvZHM6DQ0gICA5LjEgIFxTRUVOIHBl ciBCT0RZIFBBUlQNICAgICBGb3IgZXhhbXBsZSwgaWYgYSBjbGllbnQgcmV0cmlldmVzIHRoZSB0 ZXh0IHBhcnQgb2YgYSBtZXNzYWdlIA0gICAgIHdpdGhvdXQgbG9va2luZyBhdCB0aGUgYXVkaW8g YXR0YWNobWVudCwgdGhlIGluZGljYXRvciB3b3VsZCBzaG93IA0gICAgIHRoYXQgb25seSB0aGUg dGV4dCBwYXJ0IGhhZCBiZWVuIHJlYWQgYW5kIG5vdCB0aGUgZW50aXJlIG1lc3NhZ2UuDQ0gICA5 LjIgIFxTRUVOIG9ubHkgYWZ0ZXIgUHJpbWFyeSBNZXNzYWdlIFR5cGUgaGFzIGJlZW4gb3BlbmVk LiANICAgICBQcmltYXJ5IE1lc3NhZ2UgVHlwZSBpcyBkaXNjdXNzZWQgaW4gVlBJTSBVbmlmaWVk IE1lc3NhZ2UgWzhdDQ0gICAxMC4gIFJlZmVyZW5jZXMNDSAgIFsxXSAgVmF1ZHJldWlsLCBHLiwg UGFyc29ucywgRy4sICJWb2ljZSBQcm9maWxlIGZvciBJbnRlcm5ldCBNYWlsIC0gDSAgICAgICAg dmVyc2lvbiAyIiwgUkZDIDI0MjEsIFNlcHRlbWJlciAxOTk4Lg0NICAgWzJdICBCcmFkbmVyLCBT LiwgIktleSBXb3JkcyBmb3IgdXNlIGluIFJGQ3MgVG8gSW5kaWNhdGUgUmVxdWlyZW1lbnQgDSAg ICAgICAgTGV2ZWxzIiwgUkZDIDIxMTksIE1hcmNoIDE5OTcuDQ0gICBbM10gIENyaXNwaW4sIE0u LCAiSU5URVJORVQgTUVTU0FHRSBBQ0NFU1MgUFJPVE9DT0wgLSBWRVJTSU9OIDRyZXYxIiwgDSAg ICAgICAgUkZDIDIwNjAsIERlY2VtYmVyIDE5OTYuDQ0gICBbNF0gIEZyZWVkLCBOLiwgQm9yZW5z dGVpbiwgTi4sICJNdWx0aXB1cnBvc2UgSW50ZXJuZXQgTWFpbCANICAgICAgICBFeHRlbnNpb25z IChNSU1FKSBQYXJ0IE9uZTogRm9ybWF0IG9mIEludGVybmV0IE1lc3NhZ2UgQm9kaWVzIiwgDSAg ICAgICAgUkZDIDIwNDUsIE5vdmVtYmVyIDE5OTYuDQ0gICBbNV0gIFNjaHVsenJpbm5lLCBILiwg UmFvLCBBLiwgTGFucGhpZXIsIFIuLCAiIFJlYWwgVGltZSBTdHJlYW1pbmcgDSAgICAgICAgUHJv dG9jb2wgKFJUU1ApIiwgUkZDIDIzMjYsIEFwcmlsIDE5OTguDQ0gICBbNl0JTmV3bWFuLCBDLiwg IklNQVAgVVJMIFNjaGVtZSIsIFJGQyAyMTkyLCBTZXB0ZW1iZXIgMTk5Nw0NICAgWzddICBWYXVk cmV1aWwsIEcuLCBQYXJzb25zLCBHLiwgIkNvbnRlbnQgRHVyYXRpb24gTUlNRSBIZWFkZXIgDSAg ICAgICAgRGVmaW5pdGlvbiIsIFJGQyAyNDI0LCBTZXB0ZW1iZXIgMTk5OC4NDSAgIFs4XSAgUGFy c29ucywgRy4sIENvaGVuLCBNLiwgVmF1ZHJldWlsLCBHLiwgIlZQSU0gVW5pZmllZCBNZXNzYWdl IA0gICAgICAgIE1JTUUgU3ViLVR5cGUgUmVnaXN0cmF0aW9uIiwgPGRyYWZ0LWVtYS12cGltLXVt LTAxLnR4dD4sIFdvcmsgSW4gDSAgICAgICAgUHJvZ3Jlc3MuDQ0gICAgIFBhcnNvbnMgICAgICAg ICAgICAgICAgIEV4cGlyZXMgOC8yNi85OSAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNV0NDCAg ICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICBJTUFQIFZvaWNlICAgICAgICAgICBGZWJy dWFyeSAyNiwgMTk5OQ0NICAgMTEuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0NICAgVEJEDQ0g ICAxMi4gIEF1dGhvcidzIEFkZHJlc3MNDSAgICAgR2xlbm4gVy4gUGFyc29ucw0gICAgIE5vcnRl bCBOZXR3b3Jrcw0gICAgIFAuTy4gQm94IDM1MTEsIFN0YXRpb24gQw0gICAgIE90dGF3YSwgT04g SzFZIDRINw0NICAgICBQaG9uZTogKzEtNjEzLTc2My03NTgyDSAgICAgRmF4OiArMS02MTMtNzYz LTQ0NjENICAgICBFbWFpbDogZ3BhcnNvbnNAbm9ydGVsbmV0d29ya3MuY29tDQ0gICAxMy4gIEFj a25vd2xlZGdlbWVudHMNDSAgICAgQ2hlcnlsIEtpbmRlbiBhc3Npc3RlZCBpbiB0aGUgcHJlcGFy YXRpb24gb2YgdGhpcyBkb2N1bWVudCBpbiANICAgICBzdW1tYXJpemluZyBJTUFQLVZPSUNFIEJP RiBtZWV0aW5nIG5vdGVzIGFuZCBlbWFpbCBjb21tZW50cyANICAgICAobm90YWJseSBmcm9tIEp1 dHRhIERlZ2VuZXIgYW5kIEpvaG4gR2FyZGluZXIgTXllcnMpLg0NICAgMTQuICBGdWxsIENvcHly aWdodCBTdGF0ZW1lbnQNDSAgICJDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgx OTk5KS4gIEFsbCBSaWdodHMgUmVzZXJ2ZWQuDQ0gIFRoaXMgZG9jdW1lbnQgYW5kIHRyYW5zbGF0 aW9ucyBvZiBpdCBtYXkgYmUgY29waWVkIGFuZCBmdXJuaXNoZWQgdG8NICBvdGhlcnMsIGFuZCBk ZXJpdmF0aXZlIHdvcmtzIHRoYXQgY29tbWVudCBvbiBvciBvdGhlcndpc2UgZXhwbGFpbiBpdA0g IG9yIGFzc2lzdCBpbiBpdHMgaW1wbGVtZW50YXRpb24gbWF5IGJlIHByZXBhcmVkLCBjb3BpZWQs IHB1Ymxpc2hlZCANICBhbmQgZGlzdHJpYnV0ZWQsIGluIHdob2xlIG9yIGluIHBhcnQsIHdpdGhv dXQgcmVzdHJpY3Rpb24gb2YgYW55IGtpbmQsDSAgcHJvdmlkZWQgdGhhdCB0aGUgYWJvdmUgY29w eXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwYXJhZ3JhcGggYXJlDSAgaW5jbHVkZWQgb24gYWxsIHN1 Y2ggY29waWVzIGFuZCBkZXJpdmF0aXZlIHdvcmtzLiAgSG93ZXZlciwgdGhpcw0gIGRvY3VtZW50 IGl0c2VsZiBtYXkgbm90IGJlIG1vZGlmaWVkIGluIGFueSB3YXksIHN1Y2ggYXMgYnkgcmVtb3Zp bmcNICB0aGUgY29weXJpZ2h0IG5vdGljZSBvciByZWZlcmVuY2VzIHRvIHRoZSBJbnRlcm5ldCBT b2NpZXR5IG9yIG90aGVyDSAgSW50ZXJuZXQgb3JnYW5pemF0aW9ucywgZXhjZXB0IGFzIG5lZWRl ZCBmb3IgdGhlIHB1cnBvc2Ugb2YNICBkZXZlbG9waW5nIEludGVybmV0IHN0YW5kYXJkcyBpbiB3 aGljaCBjYXNlIHRoZSBwcm9jZWR1cmVzIGZvcg0gIGNvcHlyaWdodHMgZGVmaW5lZCBpbiB0aGUg SW50ZXJuZXQgU3RhbmRhcmRzIHByb2Nlc3MgbXVzdCBiZQ0gIGZvbGxvd2VkLCBvciBhcyByZXF1 aXJlZCB0byB0cmFuc2xhdGUgaXQgaW50byBsYW5ndWFnZXMgb3RoZXIgdGhhbg0gIEVuZ2xpc2gu DQ0gIFRoZSBsaW1pdGVkIHBlcm1pc3Npb25zIGdyYW50ZWQgYWJvdmUgYXJlIHBlcnBldHVhbCBh bmQgd2lsbCBub3QgYmUNICByZXZva2VkIGJ5IHRoZSBJbnRlcm5ldCBTb2NpZXR5IG9yIGl0cyBz dWNjZXNzb3JzIG9yIGFzc2lnbnMuDQ0gIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlv biBjb250YWluZWQgaGVyZWluIGlzIHByb3ZpZGVkIG9uIGFuDSAgIkFTIElTIiBiYXNpcyBhbmQg VEhFIElOVEVSTkVUIFNPQ0lFVFkgQU5EIFRIRSBJTlRFUk5FVCBFTkdJTkVFUklORw0gIFRBU0sg Rk9SQ0UgRElTQ0xBSU1TIEFMTCBXQVJSQU5USUVTLCBFWFBSRVNTIE9SIElNUExJRUQsIElOQ0xV RElORw0gIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GIFRI RSBJTkZPUk1BVElPTg0gIEhFUkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBBTlkgUklHSFRTIE9SIEFO WSBJTVBMSUVEIFdBUlJBTlRJRVMgT0YNICBNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBGT1Ig QSBQQVJUSUNVTEFSIFBVUlBPU0UuIg0NDQ0gICAgIFBhcnNvbnMgICAgICAgICAgICAgICAgIEV4 cGlyZXMgOC8yNi85OSAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNl0NDA0= ------_=_NextPart_000_01BE61C8.FBA4525A-- From owner-ietf-imap-voice Fri Mar 12 14:44:58 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA19331 for ietf-imap-voice-bks; Fri, 12 Mar 1999 14:44:58 -0800 (PST) Received: from mailgate.nortel.ca (mailgate.NortelNetworks.com [192.58.194.74]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA19327 for ; Fri, 12 Mar 1999 14:44:57 -0800 (PST) Received: from zcard00m.ca.nortel.com by mailgate.nortel.ca; Fri, 12 Mar 1999 17:50:13 -0500 Received: by zcard00m.ca.nortel.com with Internet Mail Service (5.5.2232.9) id ; Fri, 12 Mar 1999 17:50:10 -0500 Message-ID: From: "Glenn Parsons" To: "'ietf-imap-voice@imc.org'" Cc: "'vpim-l@ema.org'" Subject: RE: draft-ema-vpim-imap-00.txt Date: Fri, 12 Mar 1999 17:50:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain X-Orig: Sender: owner-ietf-imap-voice@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Folks, Ooops. It seems that you may not have been able to read the I-D I sent out with Mac EOLs. Please review the version from the IETF archives: ftp://www.ietf.org/internet-drafts/draft-ema-vpim-imap-00.txt Thanks, Glenn. > ---------- > From: Parsons, Glenn [NORSE:6L45-I:EXCH] > Sent: Friday, February 26, 1999 8:45 PM > To: ietf-imap-voice@imc.org > Cc: 'vpim-l@ema.org' > Subject: draft-ema-vpim-imap-00.txt > > Folks, > > I was meaning to send the minutes from the December BOF to this list, but > as I finally got around to putting them together (since I never really > took many notes -- nor did anyone else I think) it made more sense to just > summarize the issues and the current suggestions and post them as a draft. > So that's what I did. > > I posted the draft today (and attached it here) that covers the topics > mentioned by Jutta in the intro message last month. All of the > suggestions for each of the IMAP voice extension topics were discussed in > December. > > Please review and comment. > > Do folks think that we need another informal BOF or should we work the > details out on the list? > > Cheers, > Glenn. > > <> > > -------------------------------------------------------- > Glenn Parsons Internet Messaging Standards > Nortel Networks > Phone: +1-613-763-7582 Ottawa, Ontario, CANADA > G3fax: +1-613-763-2697 > Email: Glenn.Parsons@NortelNetworks.com > > > From owner-ietf-imap-voice Tue Jun 22 09:46:27 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA07632 for ietf-imap-voice-bks; Tue, 22 Jun 1999 09:46:27 -0700 (PDT) Received: from smtprich.nortel.com ([192.135.215.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA07628; Tue, 22 Jun 1999 09:46:26 -0700 (PDT) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprich.nortel.com; Tue, 22 Jun 1999 11:48:05 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Tue, 22 Jun 1999 11:47:56 -0500 Message-ID: <456E6DB7180ED3118A670000F8BDCA290A959B@zcard00p.ca.nortel.com> From: "Glenn Parsons" To: "'Dmitry Rubinstein'" Cc: imap@u.washington.edu, "'ietf-imap-voice@imc.org'" , "'ietf-imapext@imc.org'" , "'vpim-l@ema.org'" Subject: RE: Oslo IETF meeting Date: Tue, 22 Jun 1999 11:47:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ietf-imap-voice@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Dmitry, > I'd like to know what will be the agenda of the WG(s), that will > deal with IMAP issues. In particular I'd like to know whether > the following two drafts are going to be discussed: > > 2. draft-ema-vpim-imap-00 (VPIM over IMAP) > I hope to have a slightly updated version of this available soon based on the various comments to date. The goal of this draft is to list the possible options to solve various requirements we have noted for retrieving voice messages over IMAP. > I'd appreciate it if whoever is preparing the agenda (assuming > such preparations are being done) will tip us on the major > points that are to be discussed. The agendas are only due within > two weeks and will probably be written on the last night, but > still... > At previous meetings, the view was that this was sufficiently different that we should create another list (IMAP-Voice) and have it discussed in a different IETF session. I'd be happy to discuss it in IMAPEXT if folks wanted to talk about this and revisit if it should be in the charter. We will likely mention this draft in passing in the VPIM meeting -- though we won't have time to look at any details. Cheers, Glenn. From owner-ietf-imap-voice Thu Jun 24 11:28:47 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA05742 for ietf-imap-voice-bks; Thu, 24 Jun 1999 11:28:47 -0700 (PDT) Received: from granite.plpt.com (granite.plpt.com [199.181.238.77]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA05738 for ; Thu, 24 Jun 1999 11:28:46 -0700 (PDT) Received: by granite.plpt.com with Internet Mail Service (5.5.2232.9) id ; Thu, 24 Jun 1999 11:31:35 -0700 Message-ID: <0D7E878509BED111BEAC00A0C9A3CA60438680@granite.plpt.com> From: "Kirchhoff, Lee" To: ietf-imap-voice@imc.org Subject: Streaming Date: Thu, 24 Jun 1999 11:31:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-imap-voice@imc.org Precedence: bulk List-Archive: List-Unsubscribe: In reviewing the goals and current approach of VPIM v3 I applaud the efforts to support unified messaging by introducing the primary content type notion and adopting codecs that are usable on a PC. However there is an important need that is not yet being adequately addressed -- streaming. Responsiveness in the delivery of message content is important to users. Downloading an entire body part before presenting it is not a very responsive way to present a message whose primary content is audio, especially over modem connections Streaming is much more effective since it removes total message size as a factor in responsiveness. To date there has been some discussion on the IMAP and VPIM lists about how to introduce support for streaming. The basic need is to give the messaging client more control over how the content is retrieved. The proprosal on the IMAP list by John Haxby to introduce a BINARY fetch capability helps streaming by eliminating base64 overhead but it still assumes that the media flows over the IMAP session's TCP connection. That has the advantage of staying within the security framework of IMAP but it has the disadvantage of using TCP, which is not a very effective base for streaming (UDP is much better), and it is not necessarily easy for the IMAP client to hand off the stream of data being received to a separately invoked media player. Another proprosal on the IMAP list by Glen Parsons introduces a DATA fetch specifier with the client having the option to specify an address for the server to deliver the content via RTP. That looks attractive in certain situations but does not fit well with most existing commercial media players that are structured around being given a handle for initiating a connection to a media source. This approach also potentially encounters additional firewall difficulties since the server is connecting to the client, rather than sticking with client initiated connections and only having to deal with firewalls in one direction. An approach that seems more effective in meeting the general streaming needs is sketched below. It does not affect the MIME structuring of the message. It centers around a new IMAP4 extension called STREAM. -- Introduce a new IMAP4 extension named STREAM that a server declares in a CAPABILITY response. -- A server supporting this extension responds to STREAM as a BODY part specifier in a FETCH; for example, "A001 FETCH 3 BODY[1.2.STREAM]" would request to stream the second body part of the first multipart of the third message. -- When an IMAP4 client requests a STREAM for a body part, the server does not respond with the body part data itself but rather information about how the body part can be streamed over a separate connection. -- The client can then put this fetched streaming setup information in a file (i.e., a redirector file) and pass it to the media player configured for streaming. The streaming setup information could include several alternatives for establishing a streaming connection. Basically it looks like a prioritized list of URLs. -- The media player connects to the server using one of the specified choices, receives media packets on the established stream, and presents the data to the user appropriately for the given media type. -- The STREAM specifier would only be valid for certain MIME body part types, presumably only audio and video. -- If the client requested STREAM on a body part for which the server could not support streaming, the server would return a NO response. The client would then use a standard non-streaming FETCH to get the body part. -- The client would not use streaming in situations where the message was being forwarded or being downloaded for viewing during disconnected operation. -- The security of the streaming connection could be managed by passing a security token as part of the streaming information. The IMAP4 server shares this token with the media server so that the media server can properly accept or reject the connection from the media player. The above approach is aimed at empowering an IMAP4 messaging client to offer streaming as an option to users. It does this by giving the client the option of fetching a pointer to the message content rather than fetching the content itself. One of the details to be worked out with this approach is how this "pointer" is communicated. This approach to streaming does not affect the MIME formatting of the message. So what form does the "pointer" take? A possible starting point is ASF (Advanced Streaming Format). This format defines a redirector file for communicating the streaming source and protocol to the media player. It nicely fills the need. But rather than settling on a single redirector file format, we may want to consider supporting a registration of different formats. In that case it would be necessary to expand upon the server's STREAM declaration of capability or the client would need a way to declare the format it wanted to use in the FETCH request. The redirector file approach cleanly separates IMAP4 from the details of the streaming. It leaves those details to the media player and the media server. This can include management of stream security. It potentially could also include negotiation of the media encoding to be used (e.g., PCM vs. GSM) during stream setup in cases where the server can support media transformation. This proposal obviously requires messaging client adoption for it to be useful, but that is generally true of the other proposed unified messaging related enhancements in VPIM v3. I am seeking feedback to fine tune this approach and make it workable for a broad set of implementations. Lee Kirchhoff PulsePoint Communications lee.kirchhoff@plpt.com From owner-ietf-imap-voice Fri Jun 25 05:26:02 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA28434 for ietf-imap-voice-bks; Fri, 25 Jun 1999 05:26:02 -0700 (PDT) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA28430 for ; Fri, 25 Jun 1999 05:26:01 -0700 (PDT) Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.8.8/8.8.7) with ESMTP id IAA21022; Fri, 25 Jun 1999 08:39:09 -0400 (EDT) Received: from a3mail.lotus.com (A3MAIL.lotus.com [9.95.5.66]) by internet2.lotus.com (8.8.8/8.8.7) with ESMTP id IAA14672; Fri, 25 Jun 1999 08:25:18 -0400 (EDT) Subject: Re: Streaming To: ""Kirchhoff@internet2.lotus.com, Lee" Cc: ietf-imap-voice@imc.org X-Mailer: Lotus Notes Release 5.0 (Intl) 30 March 1999 From: "Stuart McRae/STA/Lotus" Date: Fri, 25 Jun 1999 12:52:53 +0100 Message-ID: X-Priority: 3 (Normal) X-MIMETrack: Serialize by Router on A3MAIL/CAM/H/Lotus(Build V5010617|June 17, 1999) at 06/25/99 08:14:19 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-imap-voice@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Lee, I absolutely agree with the concept of separating out the a generic streamed content specifier (redirector file) from the IMAP4 extensions to allow its use. That is going to make it easier to progress. It is immediately clear that such a redirector file could be used in other contexts - most relevantly within a MIME body to indicate that content should be streamed directly from a source rather than being sent within the message. I am no expert on either Streaming or the Web standards, so I wonder if there is any other work going on in the IETF or W3C in this area? It might be nice if all that was returned was a URL pointing to the redirector file (two levels of indirection) - although it could take a little longer for the client to work through them and find one it could handle, if there were several choices it might be quicker to get to the first than downloading them all to start with. One thing I don't want is to be stuck in the middle of a battle between different streaming mechanisms, so let's consider making this generic (especially if alternatives can be presented by the server) - we don't want another "what codecs" type discussion :-). ASF could be one format supported, but there may be other contenders (would RealNetworks support the use of ASF?). I guess the key questions are: how much data is there to be presented apart from the URL where it resides, and how much contention will there be about the file format used? This is not my area, so I leave others to comment. I think having the ability to return several different possible streaming sources/formats so the client can choose, rather than burdening the protocol with the ability for the client to declare the streaming mechanisms that it supports, will help a lot. Especially if it allows different redirector file formats to be used for different applications, and I see no reason why the MIME content types that can be streamed need to be restricted explicitly to audio and video at this stage, as you suggest. The restriction on what you can stream would be imposed by the set of redirector file formats which have been defined and are supported by the IMAP4 server. Whether there are any applications for a generic mechanism beyond video and audio I do not know, but why not define something that could be used for other things if they arise? The biggest possible issue that I see is the security area. We need some way of separating that out as well, I think. Internally (within the intranet) omitting any security may be acceptable, and for some applications a simple clear text token might be enough of a basic check, but I am sure there are going to be requirements for challenge/response and certificate based mechanisms for some applications, so I think we need an extensible mechanism that will let us defer that to subsequent specifications. It is interesting to consider the relationship between this and the existing MIME external body construct. In fact, another approach would be to have the IMAP4 server present two alternate MIME bodies, one containing the external reference (either as a URL reference to the redirector file, or as the redirector file itself) and the other the actual content. Then the client could then choose which one it wanted to pull from the IMAP4 server. I guess there may well be some objections to having the IMAP4 server fiddle with the contents of the message in this way, so your idea is probably more acceptable (although it does needs new standards to be defined). On the other hand, maybe an alternate body containing the url of an ASF file would just work today? Opinions anyone? Stuart From owner-ietf-imap-voice Sat Jun 26 14:13:55 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA17278 for ietf-imap-voice-bks; Sat, 26 Jun 1999 14:13:55 -0700 (PDT) Received: from smtprtp.nortel.com (smtprtp.NortelNetworks.com [192.122.117.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA17274 for ; Sat, 26 Jun 1999 14:13:53 -0700 (PDT) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprtp.nortel.com; Sat, 26 Jun 1999 17:16:47 -0400 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Sat, 26 Jun 1999 16:16:47 -0500 Message-ID: <456E6DB7180ED3118A670000F8BDCA290A95DC@zcard00p.ca.nortel.com> From: "Glenn Parsons" To: "'ietf-imap-voice@imc.org'" Cc: "'vpim-l@ema.org'" Subject: Updated IMAP Voice Summary draft Date: Sat, 26 Jun 1999 16:16:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BEC019.32A0DD92" Sender: owner-ietf-imap-voice@imc.org Precedence: bulk List-Archive: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BEC019.32A0DD92 Content-Type: text/plain Folks, I have updated the issues and summaries of IMAP voice proposals. I took the liberty of indicating what appears to be the favoured proposal for each issue. I submitted this to the I-D editor before the new streaming proposal, so it is not included. I have slotted a few minutes at the end of the IETF VPIM BOF to at least mention this. Cheers, Glenn. <> <> ------_=_NextPart_000_01BEC019.32A0DD92 Content-Type: application/applefile; name="draft-ema-vpim-imap-01.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-ema-vpim-imap-01.txt" AAUWAAACAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAASgAAABAAAAAJAAAAWgAAACAAAAADAAAA egAAABoAAAABAAAAlAAAQrezmCzMs5guGQAAAAAAAAAAVEVYVE1TV0QBAANAANwAAAAAAAAAAAAA AAAAAAAAAABkcmFmdC1lbWEtdnBpbS1pbWFwLTAxLnR4dCAgICAgSW50ZXJuZXQgRHJhZnQgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHbGVubiBQYXJzb25zDQogICAgIEV4 cGlyZXMgaW4gc2l4IG1vbnRocyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5vcnRlbCBO ZXR3b3Jrcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEp1bmUgMjMsIDE5OTkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSU1B UCBWb2ljZSBFeHRlbnNpb25zDQogICAgICAgICAgICAgICAgICAgICAgICAgPGRyYWZ0LWVtYS12 cGltLWltYXAtMDEudHh0Pg0KDQogICBTdGF0dXMgb2YgdGhpcyBNZW1vDQoNCiAgICAgVGhpcyBk b2N1bWVudCBpcyBhbiBJbnRlcm5ldC1EcmFmdCBhbmQgaXMgaW4gZnVsbCBjb25mb3JtYW5jZQ0K ICAgICB3aXRoIGFsbCBwcm92aXNpb25zIG9mIFNlY3Rpb24gMTAgb2YgUkZDMjAyNi4NCg0KICAg ICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBF bmdpbmVlcmluZw0KICAgICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdv cmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0IA0KICAgICBvdGhlciBncm91cHMgbWF5IGFsc28gZGlz dHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyANCiAgICAgSW50ZXJuZXQtRHJhZnRzLg0KDQog ICAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGlt dW0gb2Ygc2l4IA0KICAgICBtb250aHMgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Ig b2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyANCiAgICAgYXQgYW55IHRpbWUuICBJdCBpcyBp bmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgDQogICAgIHJlZmVyZW5jZSBt YXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiANCiAgICAgcHJv Z3Jlc3MuIg0KDQogICAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBi ZSBhY2Nlc3NlZCBhdA0KICAgICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0 cy50eHQNCg0KICAgICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3Jp ZXMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0 bWwuDQoNCiAgIDEuICBBYnN0cmFjdCANCg0KICAgICBUaGlzIGRvY3VtZW50IGlzIGFuIG92ZXJ2 aWV3IG9mIHByb3Bvc2FscyBmb3IgdmFyaW91cyBleHRlbnNpb25zIHRvIA0KICAgICBJTUFQIHRv IG1lZXQgdGhlIHJlcXVpcmVtZW50cyBvZiB2b2ljZSBtYWlsIHN5c3RlbXMuICBUaGUgdG9waWNz IA0KICAgICBpbmNsdWRlZCBhcmUgDQogICAgIC0gQmluYXJ5IEF0dGFjaG1lbnQgdHJhbnNmZXIN CiAgICAgLSBFeHRlcm5hbCBSZWZlcmVuY2UgDQogICAgIC0gQWx0ZXJuYXRlIENvZGVjIFJlcXVl c3QNCiAgICAgLSBTdHJlYW1pbmcgYXVkaW8gYXR0YWNobWVudHMNCiAgICAgLSBNZXNzYWdlIGxl bmd0aCBJbmRpY2F0b3INCiAgICAgLSBCb2R5IHBhcnQgcmVhZCBpbmRpY2F0b3INCg0KICAgMi4g IE92ZXJ2aWV3DQoNCiAgICAgVW5pZmllZCBtZXNzYWdpbmcnIHJlcXVpcmVzIHRoYXQgc3lzdGVt cyBhcmUgY2FwYWJsZSBvZiBzZW5kaW5nIGFuZCANCiAgICAgcmVjZWl2aW5nIGVhY2ggb2Ygc2V2 ZXJhbCBkaWZmZXJlbnQgbWVzc2FnZSB0eXBlcy4gIFR5cGljYWwgdW5pZmllZA0KICAgICBtZXNz YWdpbmcgc3lzdGVtcyB0b2RheSBjb25zb2xpZGF0ZSBmYXggbWVzc2FnZXMsIHZvaWNlIG1lc3Nh Z2VzDQogICAgIGFuZCBlbWFpbCBtZXNzYWdlcyBpbnRvIGEgc2luZ2xlIHN5c3RlbS4gDQoNCiAg ICAgVGhlcmUgYXJlIGNlcnRhaW4gcmVxdWlyZW1lbnRzIG9yIHJlc3RyaWN0aW9ucyB0aGF0IGEg dm9pY2VtYWlsIG9yIGZheA0KICAgICBzeXN0ZW0gaGFzIG92ZXIgdGhvc2Ugb2YgZWxlY3Ryb25p YyBtYWlsIHN5c3RlbXMuICBGb3IgZXhhbXBsZSwNCiAgICAgdm9pY2VtYWlsIG11c3QgYmUgYWJs ZSB0byBiZSBhY2Nlc3NlZCB1c2luZyBhIHRlbGVwaG9uZS4NCg0KICAgICBBcyB0aGUgSU1BUCBi YXNlIHNwZWNpZmljYXRpb24gd2FzIGRlZmluZWQgd2l0aG91dCBjb25jZXJuIGZvcg0KICAgICB2 b2ljZSBtZXNzYWdpbmcsIHRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgdGhlc2UgZXh0ZW5zaW9ucyB0 byBJTUFQIHRvIA0KICAgICBtZWV0IHRoZSByZXF1aXJlbWVudHMgb2Ygc2VydmVycyB0aGF0IGhh bmRsZSB2b2ljZSBtZXNzYWdlcy4NCiAgIA0KICAgICANCiAgICAgUGFyc29ucyAgICAgICAgICAg ICAgICAgRXhwaXJlcyAxMi8yMy85OSAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMV0NCgwgICAg IEludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgSU1BUCBWb2ljZSAgICAgICAgICAgICAgICAg IEp1bmUgMjMsIDE5OTkNCiAgIA0KICAgMy4gIEludHJvZHVjdGlvbg0KDQogICAgIFRoaXMgSW50 ZXJuZXQgRHJhZnQgc3VtbWFyaXplcyB0aGUgcHJvcG9zZWQgZXh0ZW5zaW9ucyBhcyBkaXNjdXNz ZWQgDQogICAgIGF0IHRoZSBJTUFQLVZPSUNFIGluZm9ybWFsIEJPRiBhdCBJRVRGLCBPcmxhbmRv LCBEZWNlbWJlciAxOTk4DQogICAgIGFuZCBpbmNsdWRlcyBtb2RpZmljYXRpb25zIGJhc2VkIG9u IGNvbW1lbnRzIGZyb20gdGhlIElNQVAgYW5kIA0KICAgICBJTUFQLVZPSUNFIGxpc3RzLg0KDQog ICAgIFRoZSBpbnRlbnQgb2YgdGhpcyBkcmFmdCBpcyB0byBkb2N1bWVudCB0aGUgb3B0aW9ucyBh bmQgdGhlcmVmb3JlIA0KICAgICBmYWNpbGl0YXRlIGRpc2N1c3Npb25zIG9uIHRoZSBJTUFQIGFu ZCBJTUFQLVZPSUNFIGxpc3RzLg0KICAgICBJdCBpcyBlbnZpc2FnZWQgdGhhdCBzZXBhcmF0ZSBk cmFmdHMgd2lsbCBkZXNjcmliZSBlYWNoIGV4dGVuc2lvbiBvcHRpb24NCiAgICAgY2hvc2VuLg0K DQogICAgIElNQVAtVk9JQ0UgaXMgYSBCT0YgZm9yIGRpc2N1c3Npb24gb2YgZXh0ZW5zaW9ucyB0 byBJTUFQNCBpbiANCiAgICAgc3VwcG9ydCBvZiB2b2ljZSBtZXNzYWdpbmcgYXBwbGljYXRpb25z LCBhbmQgdGhlIHN0YW5kYXJkaXphdGlvbiBvZiANCiAgICAgdGhlc2UgaW4gdGhlIElFVEYuIEZv ciBtb3JlIGluZm9ybWF0aW9uIHNlZSANCiAgICAgaHR0cDovL3d3dy5pbWMub3JnL2lldGYtaW1h cC12b2ljZS8NCg0KICAgICBWb2ljZSBtZXNzYWdpbmcgdHJhbnNwb3J0IG92ZXIgSW50ZXJuZXQg TWFpbCBpcyBkZWZpbmVkIGJ5IFZQSU0gdjIgDQogICAgIChSRkMgMjQyMSlbMV0uIEZvciBtb3Jl IGluZm9ybWF0aW9uIHNlZSBodHRwOi8vd3d3LmVtYS5vcmcvdnBpbS8uDQogDQogICAzLjEgIENv bnZlbnRpb25zIFVzZWQgaW4gdGhpcyBEb2N1bWVudA0KDQogICAgIEluIGV4YW1wbGVzLCAiQzoi IGFuZCAiUzoiIGluZGljYXRlIGxpbmVzIHNlbnQgYnkgdGhlIGNsaWVudCBhbmQNCiAgICAgc2Vy dmVyIHJlc3BlY3RpdmVseS4gDQoNCiAgICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5P VCIsICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsIA0KICAgICBhbmQgIk1BWSIgaW4gdGhpcyBkb2N1 bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVmaW5lZCBpbiANCiAgICAgIktleSB3b3Jk cyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUgUmVxdWlyZW1lbnQgTGV2ZWxzIiBbMl0uDQoN CiAgIDQuICBCaW5hcnkgQXR0YWNobWVudCBIZWFkZXINCg0KICAgICBTaW5jZSBWUElNIG9wdGlv bmFsbHkgc3VwcG9ydHMgYmluYXJ5IGF0dGFjaG1lbnRzLCBhbmQgc2luY2UgaXQgbWF5IA0KICAg ICBiZSBiZW5lZmljaWFsIGZvciB0aGUgY2xpZW50IG5vdCB0byBkZWNvZGUgYmFzZTY0IGVuY29k ZWQgYXVkaW8sIGl0IA0KICAgICBpcyBkZXNpcmFibGUgdG8gaGF2ZSBhIG1ldGhvZCBvZiByZXRy aWV2aW5nIGJpbmFyeSBib2R5IHBhcnRzIGluIA0KICAgICBJTUFQLiAgTm90ZSB0aGF0IHRoaXMg d291bGQgYmUgbmljZSB0byBoYXZlLCBob3dldmVyIGl0IGlzIA0KICAgICBub3QgbmVlZGVkIGZv ciB2b2ljZSBtZXNzYWdpbmcuICAgDQoNCiAgICAgSU1BUDRyZXYxIFNlcnZlcnMgdGhhdCBzdXBw b3J0IHRoZSB0cmFuc2ZlciBvZiBiaW5hcnkgYXR0YWNobWVudHMNCiAgICAgTVVTVCBsaXN0IHRo ZSBrZXl3b3JkIEJJTkFSWSBpbiB0aGVpciBDQVBBQklMSVRZIHJlc3BvbnNlLg0KDQogICAgIFN1 Z2dlc3Rpb25zIGZvciBhY2NvbXBsaXNoaW5nIHRoaXMgYXJlIGFzIGZvbGxvd3MuICANCiAgICAg VGhlIGZhdm91cmVkIG9wdGlvbiBpcyA0LjIsIGNsb3NlbHkgZm9sbG93ZWQgYnkgNC40Lg0KDQog ICA0LjEgIEEgREFUQSBzdWZmaXggaW5zaWRlIGEgRkVUQ0ggQk9EWVtdIGNvbnN0cnVjdA0KDQog ICAgIEl0cyBzeW50YXggd291bGQgYmUgc2ltaWxhciB0byB0aGF0IG9mIEhFQURFUi5GSUVMRFMg YXMgZGVzY3JpYmVkIA0KICAgICBpbiBJTUFQNHJldjEgWzNdLg0KDQogICAgIFRoZSBEQVRBIHBh cnQgc3BlY2lmaWVyIE1VU1QgYmUgcHJlZml4ZWQgYnkgb25lIG9yIG1vcmUgbnVtZXJpYyANCiAg ICAgcGFydCBzcGVjaWZpZXJzLg0KDQogICAgIEM6IGFiYyBGRVRDSCAxIChCT0RZWzEuMi5EQVRB KEVOQ09ESU5HIEJJTkFSWSldKQ0KICAgICANCg0KICAgICBQYXJzb25zICAgICAgICAgICAgICAg ICBFeHBpcmVzIDEyLzIzLzk5ICAgICAgICAgICAgICAgICAgICBbUGFnZSAyXQ0KDCAgICAgSW50 ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICBJTUFQIFZvaWNlICAgICAgICAgICAgICAgICAgSnVu ZSAyMywgMTk5OQ0KDQogICAgIFRoZSBrZXl3b3JkIEVOQ09ESU5HIHNlbGVjdHMgZW5jb2Rpbmcg YXMgZGVmaW5lZCBpbiB0aGUgTUlNRSANCiAgICAgQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZyBI ZWFkZXIgRmllbGQuIFs0XQ0KDQogICAgICJFTkNPRElORyBCSU5BUlkiIFNIT1VMRCByZXF1ZXN0 IHRoYXQgdGhlIHNlcnZlciBub3QgZW5jb2RlDQogICAgIHRoZSBiaW5hcnkgaW50byBiYXNlNjQg b3IgdG8gZGVjb2RlIHRoZSBiYXNlNjQgYmFjayBpbnRvIGJpbmFyeSwgDQogICAgIGlmIGFscmVh ZHkgZW5jb2RlZC4JDQoNCiAgIDQuMiAgQSBCSU5BUlkgcGFydCBzcGVjaWZpZXIgdG8gdGhlIEZF VENIIGNvbW1hbmQNCg0KCUM6IGFiYyBGRVRDSCAxIEJPRFlbeC55LkJJTkFSWV0NCg0KICAgICBU aGlzIHByb3ZpZGVzIHBhcnQgeC55IGFzIGEgbGl0ZXJhbCBzdHJpbmcgY29udGFpbmluZyBkYXRh IHdpdGggbm8gdHJhbnNmZXINCiAgICAgZW5jb2RpbmcsIHB1cmUgYmluYXJ5IGRhdGEuICBCSU5B UlkgaXMgb25seSBwZXJtaXR0ZWQgZm9yIGxlYWYgYm9keSANCiAgICAgcGFydHMsIG5vdCBmb3Ig aGVhZGVycyBhbmQgbm90IGZvciBjb21wb3NpdGUgYm9keSBwYXJ0cy4NCg0KICAgNC4zICBBIG5l dyBjb21tYW5kIHRoYXQgbGlzdHMgY2xpZW50IGNhcGFiaWxpdGllcywgQ0NBUEFCSUxJVFkgb3Ig DQogICAgICAgYSBzZXQgb2YgcGFyYW1ldGVycyBmb3IgdGhlIENBUEFCSUxJVFkgY29tbWFuZC4N Cg0KCTQuMy4xIFM6IENDQVBBQklMSVRZDQoJQzogQ0NBUEFCSUxJVFkgQklOQVJZDQoJDQoJNC4z LjIgQzogQ0FQQUJJTElUWSBCSU5BUlkgRk9PQkFSDQoJUzogQ0FQQUJJTElUWSBJTUFQNHJldjEg QklOQVJZIEZPT0JBUg0KDQogICA0LjQgIEEgbmV3IERFQ09ERSBjb21tYW5kDQogICAgIFRoZSBh ZHZhbnRhZ2Ugb2YgdGhpcyBpcyBpdCBjYW4gYmUgaW1wbGVtZW50ZWQgYXMgaW5kZXBlbmRlbnQg DQogICAgIGNvZGUuDQoNCglDOiB0YWcgREVDT0RFIEJJTkFSWSBCT0RZWzEuMl17Li4ufQ0KCVM6 ICoxIERFQ09ERSBCSU5BUlkgQk9EWVsxLjJdey4uLn0NCgkuLi5kYXRhLi4uDQoNCiAgIDQuNSAg QSBCRkVUQ0ggY29tbWFuZC9yZXNwb25zZSB3aGljaCBpcyBpZGVudGljYWwgdG8gRkVUQ0gNCiAg ICAgZXhjZXB0IHRoYXQgaXQgYWx3YXlzIHJlbW92ZXMgY29udGVudC10cmFuc2Zlci1lbmNvZGlu Z3Mgd2hlbiANCiAgICAgYSBsZWFmIGJvZHkgcGFydCBpcyBmZXRjaGVkLg0KICANCiAgICA1LiAg RXh0ZXJuYWwgUmVmZXJlbmNlDQoNCiAgICAgVG8gbWVldCB0aGUgcmVxdWlyZW1lbnRzIG9mIHZv aWNlbWFpbCBzeXN0ZW1zLCB0aGVyZSBpcyBhIG5lZWQgdG8gDQogICAgIHN1cHBvcnQgZXh0ZXJu YWwgcmVmZXJlbmNlLCBzdWNoIGFzIHVzaW5nIGEgdGVsZXBob25lIGZvciBwbGF5YmFjayANCiAg ICAgb2Ygdm9pY2UgbWVzc2FnZXMuICANCg0KICAgICBJTUFQNHJldjEgc2VydmVycyB0aGF0IHN1 cHBvcnQgdGhlIHNlbGVjdGVkIG1ldGhvZCBmb3IgZXh0ZXJuYWwgDQogICAgIHJlZmVyZW5jZSBN VVNUIGxpc3QgdGhlIGtleXdvcmQgRVhURVJOQUwgaW4gdGhlaXIgQ0FQQUJJTElUWQ0KICAgICBy ZXNwb25zZS4NCg0KICAgICBUaHJlZSBzdWdnZXN0aW9ucyBvZiBob3cgdGhpcyBjYW4gYmUgYWNj b21wbGlzaGVkIGFyZSBhcyBmb2xsb3dzLiAgDQogICAgIFRoZSBmYXZvdXJlZCBvcHRpb24gZm9y IEV4dGVybmFsIFJlZmVyZW5jZSBpcyA1LjI6DQoNCiAgIDUuMSAgVXNlIG9mIGFuIGV4dGVybmFs IHJlZmVyZW5jZSBtZWNoYW5pc20gcmVxdWlyZXMgc3BsaXQgY2xpZW50IA0KICAgICBzdXBwb3J0 IGZvciBSZWFsIFRpbWUgU3RyZWFtaW5nIFByb3RvY29sIChSVFNQKSBhcyB3ZWxsIGFzIElNQVAu DQoNCiAgICAgDQogICAgIFBhcnNvbnMgICAgICAgICAgICAgICAgIEV4cGlyZXMgMTIvMjMvOTkg ICAgICAgICAgICAgICAgICAgIFtQYWdlIDNdDQoMICAgICBJbnRlcm5ldCBEcmFmdCAgICAgICAg ICAgICAgIElNQVAgVm9pY2UgICAgICAgICAgICAgICAgICBKdW5lIDIzLCAxOTk5DQoNCiAgICAg SWYgdXNpbmcgYW4gZXh0ZXJuYWwgbWVjaGFuaXNtIGZvciBwbGF5YmFjaywgaW1wbGVtZW50YXRp b25zIG1heSANCiAgICAgdXNlIFJUU1AgYXMgZGVzY3JpYmVkIGluIFJGQyAyMzI2IFs1XSwgYXMg dGhlIGNvbnRyb2wgcHJvdG9jb2wgZnJvbSANCiAgICAgdGhlIGNsaWVudCB0byBhIHByb3h5IHNl cnZlci4gKFdoaWNoIGNvdWxkIG1ha2UgdGhlIG91dGNhbGwgdG8gdGhlIA0KICAgICBwaG9uZSkN Cg0KICAgNS4yICBBIG5ldyBvcHRpb25hbCBrZXl3b3JkIFRPIGluIHRoZSBEQVRBIHBhcnQgc3Bl Y2lmaWVyLCBhcyANCiAgICAgZGVzY3JpYmVkIGluIDQuMSwgaXMgYWNjb21wYW5pZWQgYnkgVVJM IGZvciB3aGljaCB0byBzZW5kIHRoZSBkYXRhLiANCiAgICAgVGhlIFVSTCAgYmVnaW5zIHdpdGgg YSBwcm90b2NvbC4NCg0KICAgICBDOiBhYmMgRkVUQ0ggMSAoQk9EWVsxLjIuREFUQShUTyAicnRw OjE1NS41LjEuMjM6NDU2NyIpXSkNCg0KICAgNS4zICBJTUFQIFVSTHMgY2FuIGJlIHVzZWQgdG8g cmVmZXJlbmNlIHRoZSBtZXNzYWdlIG9uIHRoZSBJTUFQIA0KICAgICBzZXJ2ZXIgYXMgZGVzY3Jp YmVkIGluIHRoZSBJTUFQIFVSTCBTY2hlbWUgWzZdLg0KDQogICAgIFRoZSBJTUFQIFVSTCBmb3Ig YSBzcGVjaWZpYyBtZXNzYWdlIG9yIG1lc3NhZ2UgcGFydCBoYXMgdGhlIA0KICAgICBmb2xsb3dp bmcgZm9ybToNCg0KICAgICBpbWFwOi8vPGlzZXJ2ZXI+LzxlbmNfbWFpbGJveD5bdWlkdmFsaWRp dHldPGl1aWQ+W2lzZWN0aW9uXQ0KDQogICA2LiAgQWx0ZXJuYXRlIENvZGVjIFJlcXVlc3QgDQoN CiAgICAgQ2xpZW50cyB0b2RheSBhcmUgdXNpbmcgbWFueSBkaWZmZXJlbnQgdHlwZXMgb2YgY29k ZWNzLiAgQmVjYXVzZSBvZiANCiAgICAgdGhpcywgdGhlcmUgaXMgYSBkZXNpcmUgdG8gaGF2ZSB0 aGUgc2VydmVyIHRyYW5zY29kZSBhbmQgcHJlc2VudCANCiAgICAgdGhlIG1lc3NhZ2UgaW4gdGhl IGFwcHJvcHJpYXRlIGNvZGVjIGZvciB0aGF0IGNsaWVudC4gIA0KDQogICAgIElNQVA0cmV2MSBz ZXJ2ZXJzIHRoYXQgc3VwcG9ydCB0aGUgdHJhbnNjb2Rpbmcgb2YgYWx0ZXJuYXRlIGNvZGVjcyAN CiAgICAgU0hPVUxEIGFkdmVydGlzZSB0aGUgYXZhaWxhYmxlIGNvZGVjcyBpbiByZXNwb25zZSB0 byB0aGUgDQogICAgIENBUEFCSUxJVFkgY29tbWFuZC4NCg0KICAgICBUaGVyZSBhcmUgc2V2ZXJh bCAgc3VnZ2VzdGlvbnMgZm9yIGFjY29tcGxpc2hpbmcgdGhpcyB3aXRoIHRoZSANCiAgICAgZmF2 b3VyZWQgb3B0aW9uIGJlaW5nIDYuNDoNCg0KICAgNi4xICBUaGUgcmVjZWl2aW5nIElNQVAgU2Vy dmVyIHNob3VsZCBjcmVhdGUgbXVsdGlwYXJ0L2FsdGVybmF0aXZlIG9uIA0KICAgICByZWNlcHRp b24gd2l0aCBzdXBwb3J0IGZvciAgJ24gY29kZWNzJyB3aGVyZSAnbiBjb2RlY3MnIGFyZSB0aGUg DQogICAgIGNvZGVjcyBzdXBwb3J0ZWQgYXQgdGhhdCBzZXJ2ZXIuICBUaGUgY2xpZW50IHdvdWxk IHRoZW4gaGF2ZSB0aGUgDQogICAgIG9wdGlvbiBvZiBjaG9vc2luZyB0aGUgY29kZWMgdGhhdCBp dCBzdXBwb3J0cy4NCg0KICAgNi4yICBPcHRpb25hbCBrZXl3b3JkIFRZUEUgaW4gdGhlIERBVEEg c3VmZml4IChhcyBkZXNjcmliZWQgaW4gNC4xKSwgDQogICAgIGlmIHByZXNlbnQsIHJlcXVlc3Rz IGNvbnZlcnNpb24gb2YgdGhlIGNvbnRlbnQgaW50byB0aGUgc3BlY2lmaWVkIA0KICAgICB0eXBl Lg0KDQogICAgIEM6IGFiYyBGRVRDSCAxIChCT0RZW0RBVEEoRU5DT0RJTkcgQklOQVJZIFRZUEUo IkFVRElPIiAiR1NNIikpXSkNCg0KICAgICBJZiB0aGUgc2VydmVyIGNhbid0IGFjY29tcGxpc2gg dGhlIGNvbnZlcnNpb24sIHRoZSBGRVRDSCBmYWlscy4NCiAgIA0KICAgNi4zICBBcyBkaXNjdXNz ZWQgaW4gc2VjdGlvbiA0LjMsIGEgY2xpZW50IGNhcGFiaWxpdGllcyBjb21tYW5kL3Jlc3BvbnNl IA0KICAgICB0aGF0IGxpc3RzIHRoZSBwcmVmZXJyZWQgY29kZWMsIG9yIHRoZSBzdXBwb3J0ZWQg Y29kZWNzIG9mIHRoZSBjbGllbnQuDQoNCgk2LjMuMSBTOiBDQ0FQQUJJTElUWQ0KCUM6IENDQVBB QklMSVRZIEdTTSBGT09CQVINCg0KCTYuMy4yIEM6IENBUEFCSUxJVFkgR1NNIEZPT0JBUg0KCVM6 IENBUEFCSUxJVFkgSU1BUDRyZXYxIEdTTSBGT09CQVINCg0KICAgICBQYXJzb25zICAgICAgICAg ICAgICAgICBFeHBpcmVzIDEyLzIzLzk5ICAgICAgICAgICAgICAgICAgICBbUGFnZSA0XQ0KDCAg ICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICBJTUFQIFZvaWNlICAgICAgICAgICAgICAg ICAgSnVuZSAyMywgMTk5OQ0KDQogICA2LjQgIE5ldyBERUNPREUgY29tbWFuZCwgYXMgb3Bwb3Nl ZCB0byBtb2RpZnlpbmcgdGhlIEZFVENIIGNvbW1hbmQNCg0KICAJQzogYWJjIERFQ09ERSBCSU5B UlkgQk9EWVsxLjIoVFlQRSgiQVVESU8iICJHU00iKV0NCg0KDQogICA3LiAgU3RyZWFtaW5nIEF1 ZGlvIEF0dGFjaG1lbnRzDQoNCiAgICAgU3RyZWFtaW5nIGlzIG5lZWRlZCBpbiBzdWNoIGNhc2Vz IG9mIGxhcmdlIGF1ZGlvIGF0dGFjaG1lbnRzLCBzbWFsbCANCiAgICAgY2xpZW50cywgc2xvdyBs aW5rcyB0byBhbGxvdyB0aGUgdXNlciB0byBsaXN0ZW4gdG8gdGhlIG1lc3NhZ2UgYXMgDQogICAg IGl0IGlzIGJlaW5nIGRvd25sb2FkZWQsIHJhdGhlciB0aGFuIGhhdmluZyB0byBkb3dubG9hZCB0 aGUgd2hvbGUgDQogICAgIG1lc3NhZ2UgZmlyc3QuICBPbmUgc3VnZ2VzdGlvbiBmb3IgYWNjb21w bGlzaGluZyB0aGlzIGlzOg0KDQogICA3LjEgIFRoZSBzdHJlYW1pbmcgb2YgYXVkaW8gYXR0YWNo bWVudHMgY2FuIGJlIGRvbmUgdXNpbmcgd2luZG93aW5nLiANCg0KICAgICBGRVRDSCBCT0RZW108 PHBhcnRpYWw+Pg0KDQogICAgIFNvbWUgaXNzdWVzIGNvbmNlcm5pbmcgc3RyZWFtaW5nIGJ5IHdp bmRvd2luZyBhcmUgDQogICAgIC0gbGF0ZW5jeSANCiAgICAgLSBubyBzZXQgd2luZG93IHNpemUu DQoNCiAgIDguICBNZXNzYWdlIExlbmd0aCBJbmRpY2F0b3INCg0KICAgICBJbiB0aGUgY2FzZXMg b2YgbGFyZ2UgYXR0YWNobWVudHMsIHNtYWxsIGNsaWVudHMgYW5kIHNsb3cgbGlua3MgDQogICAg IHRoZXJlIGlzIGFsc28gYSBuZWVkIGZvciB0aGUgY2xpZW50IHRvIHNlZSB0aGUgbGVuZ3RoIG9m IHRoZSANCiAgICAgbWVzc2FnZSBpbiBhIHN1aXRhYmxlIGZvcm1hdCBiZWZvcmUgb3BlbmluZyBp dC4gDQoNCiAgICAgQSBtZXNzYWdlIGxlbmd0aCBpbmRpY2F0b3Igc3VpdGFibGUgZm9yIHZvaWNl bWFpbCBhbmQgZmF4IHNob3VsZCANCiAgICAgaW5kaWNhdGUgdGhlIGxlbmd0aCBvZiB0aGUgbWVz c2FnZSB1c2luZyBudW1iZXIgb2Ygc2Vjb25kcyBmb3IgYSANCiAgICAgdm9pY2UgbWVzc2FnZSBh bmQgdXNpbmcgbnVtYmVyIG9mIHBhZ2VzIGZvciBhIGZheCBtZXNzYWdlLiAgVGhlIA0KICAgICBj bGllbnQgTVVTVCBzdXBwb3J0IHRoZSBjaG9zZW4gbWV0aG9kLiAgVGhlcmUgYXJlIHRocmVlIHN1 Z2dlc3RlZCANCiAgICAgbWV0aG9kcyBhbmQgYW1vbmcgdGhlbSwgOC4zIGlzIGZhdm91cmVkOg0K DQogICA4LjEgIE1JTUUgSGVhZGVyIENvbnRlbnQtRHVyYXRpb24gYXMgZGVzY3JpYmVkIGluIFJG QyAyNDI0IFs3XQ0KDQogICAgIEZvciBmYXggbWVzc2FnZXMgYSBuZXcgTUlNRSBIZWFkZXIsIENv bnRlbnQtUGFnZS1MZW5ndGgsIHdvdWxkIGJlIA0KICAgICBkZWZpbmVkLCBzaW1pbGFyIHRvIENv bnRlbnQtRHVyYXRpb24gd2l0aCB0aGUgZXhjZXB0aW9uIHRoYXQgbnVtYmVyIA0KICAgICBvZiBw YWdlcyB3b3VsZCBiZSBzcGVjaWZpZWQsIHJhdGhlciB0aGFuIG51bWJlciBvZiBzZWNvbmRzLiAo ZS5nLiANCiAgICAgQ29udGVudC1QYWdlLUxlbmd0aDozKS4gIFRoaXMgd291bGQgYmUgY3JlYXRl ZCBhdCBvcmlnaW5hdG9yLg0KDQogICA4LjIgIEZFVENIIGl0ZW0gVVNFUlNJWkUgc2ltaWxhciB0 byBGRVRDSCBpdGVtcyBkZXNjcmliZWQgaW4gDQogICAgIElNQVA0cmV2MSBbM10uICBUaGlzIHdv dWxkIGJlIGNyZWF0ZWQgYXQgcmVjZXB0aW9uLg0KDQogICA4LjIuMSAgVVNFUlNJWkUgaXMgYSBu b24tbmVnYXRpdmUgbnVtYmVyLiAgSXRzIG1lYW5pbmcgZGVwZW5kcyBvbiANCiAgICAgZG9jdW1l bnQgdHlwZS4NCg0KICAgICBDOiBhYmMgRkVUQ0ggMToyIChVU0VSU0laRSkNCiAgICAgUzogKjEg RkVUQ0ggKDEyKQ0KICAgICBTOiAqMiBGRVRDSCAoNTcpDQogICAgIFM6IGFiYyBGRVRDSCBjb21w bGV0ZWQuDQoNCiAgIDguMi4yICBVU0VSU0laRSBpcyBhIHBhaXIgb2YgbnVtYmVyIGFuZCB1bml0 LiAgVGhlcmUgaXMgYSBzbWFsbCBzZXQgDQogICAgIG9mIHVuaXQgdG9rZW5zLg0KDQoNCiAgICAg UGFyc29ucyAgICAgICAgICAgICAgICAgRXhwaXJlcyAxMi8yMy85OSAgICAgICAgICAgICAgICAg ICAgW1BhZ2UgNV0NCgwgICAgIEludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgSU1BUCBWb2lj ZSAgICAgICAgICAgICAgICAgIEp1bmUgMjMsIDE5OTkNCg0KICAgICBDOiBhYmMgRkVUQ0ggMToy IChVU0VSU0laRSkNCiAgICAgUzogKjEgRkVUQ0ggKDEyIHBhZ2VzKQ0KICAgICBTOiAqMiBGRVRD SCAoNTcgc2Vjb25kcykNCiAgICAgUzogYWJjIEZFVENIIGNvbXBsZXRlZC4NCg0KICAgOC4yLjMg IFVTRVJTSVpFIGlzIGEgc2VxdWVuY2Ugb2YgcGFpcnMsIGluIGNhc2Ugc29tZXRoaW5nIGV4dGVu ZHMgaW4NCiAgICAgbW9yZSB0aGFuIG9uZSB1bml0Lg0KDQogICAgIEM6IGFiYyBGRVRDSCAxOjIg KFVTRVJTSVpFKQ0KICAgICBTOiAqMSBGRVRDSCAoMTIgbGluZXMpDQogICAgIFM6ICoxIEZFVENI ICg1NyBwYWdlcyA2IGhvdXJzKQ0KICAgICBTOiBhYmMgRkVUQ0ggY29tcGxldGVkLg0KDQogICAg IFNlcnZlcnMgdGhhdCBzdXBwb3J0IFVTRVJTSVpFIFNIT1VMRCBsaXN0IHRoZSBVU0VSU0laRSBj YXBhYmlsaXR5IA0KICAgICBpbiByZXNwb25zZSB0byB0aGUgQ0FQQUJJTElUWSBjb21tYW5kLg0K DQogICA4LjMgIE1lc3NhZ2UgbGVuZ3RoIGluZGljYXRlZCBhcyBhIHBhcmFtZXRlciBvZiBhbiBl eGlzdGluZyBIZWFkZXIgRmllbGQgWzRdLiAgDQogICAgIFRoaXMgd291bGQgYmUgY3JlYXRlZCBh dCB0aGUgc291cmNlLiAgVGhpcyBtZXRob2Qgd291bGQgYWxsb3cgdGhlIG1lc3NhZ2UgDQogICAg IGxlbmd0aCB0byBiZSBwYXNzZWQgdG8gdGhlIGNsaWVudCBieSBkZWZhdWx0LiANCg0KCTguMy4x ICBDb250ZW50LVR5cGUgSGVhZGVyIEZpZWxkDQogIAlDb250ZW50LVR5cGU9YXVkaW8vKjsgbGVu Z3RoPTUwDQogIAlDb250ZW50LVR5cGU9aW1hZ2UvdGlmZjsgcGFnZXM9Mw0KDQoJOC4zLjIgU3Vi amVjdCBIZWFkZXIgRmllbGQNCiAgCVN1YmplY3Q9Vm9pY2UgTWVzc2FnZSAoMDowNCkNCiAgCVN1 YmplY3Q9RmF4IE1lc3NhZ2UgKDMpDQoNCglUaGUgYWR2YW50YWdlIG9mIHRoZSBzdWJqZWN0IGZp ZWxkIGlzIHRoYXQgaXQgaXMgYXV0b21hdGljYWxseSBkaXNwbGF5ZWQNCgl0byB0aGUgdXNlci4N Cg0KICAgOS4gIEJvZHkgUGFydCBSZWFkIEluZGljYXRvcg0KDQogICAgIFdpdGggdGhlIHVzZSBv ZiBtdWx0aXBhcnQgbWVzc2FnZXMgdGhlcmUgc2hvdWxkIGJlIGEgc2VwYXJhdGUgQk9EWSANCiAg ICAgUEFSVCBSRUFEIGluZGljYXRvciBmb3IgZWFjaCBib2R5IHBhcnQgb3IsIGF0IGxlYXN0LCB0 byBvbmx5IA0KICAgICBpbmRpY2F0ZSBSRUFEIHdoZW4gdGhlIHByaW1hcnkgYm9keSBwYXJ0IGhh cyBiZWVuIHJlYWQuIFRoZXJlIGFyZSANCiAgICAgdHdvIHN1Z2dlc3RlZCBtZXRob2RzLiAgVGhl IGZhdm91cmVkIG1ldGhvZCBpcyA5LjEuDQoNCiAgICAgSU1BUDRyZXYxIHNlcnZlcnMgdGhhdCBz dXBwb3J0IGJvZHkgcGFydCByZWFkIGluZGljYXRvcnMgU0hPVUxEIGxpc3QgDQogICAgIHRoZSBr ZXl3b3JkIFNFRU4tQlktUEFSVCBpbiByZXNwb25zZSB0byB0aGUgQ0FQQUJJTElUWSBjb21tYW5k Lg0KDQogICA5LjEgIFxTRUVOIHBlciBCT0RZIFBBUlQNCiAgICAgRm9yIGV4YW1wbGUsIGlmIGEg Y2xpZW50IHJldHJpZXZlcyB0aGUgdGV4dCBwYXJ0IG9mIGEgbWVzc2FnZSANCiAgICAgd2l0aG91 dCBsb29raW5nIGF0IHRoZSBhdWRpbyBhdHRhY2htZW50LCB0aGUgaW5kaWNhdG9yIHdvdWxkIHNo b3cgDQogICAgIHRoYXQgb25seSB0aGUgdGV4dCBwYXJ0IGhhZCBiZWVuIHJlYWQgYW5kIG5vdCB0 aGUgZW50aXJlIG1lc3NhZ2UuDQoNCiAgIDkuMiAgXFNFRU4gb25seSBhZnRlciBQcmltYXJ5IE1l c3NhZ2UgVHlwZSBoYXMgYmVlbiBvcGVuZWQuIA0KICAgICBQcmltYXJ5IE1lc3NhZ2UgVHlwZSBp cyBkaXNjdXNzZWQgaW4gVlBJTSBVbmlmaWVkIE1lc3NhZ2UgWzhdLiAgDQogICAgIEluIHRoZSBj YXNlIG9mIG11bHRpcGxlIGF0dGFjaG1lbnRzIHRoZSBcU0VFTiBmbGFnIHdvdWxkIGJlIHNldCBh ZnRlciB0aGUgDQogICAgIGZpcnN0IGF0dGFjaG1lbnQgb2YgdGhlIHByaW1hcnkgY29udGVudCB0 eXBlIGhhcyBiZWVuIG9wZW5lZC4gIEZvciBleGFtcGxlLA0KICAgICBpZiB0aGUgcHJpbWFyeSBj b250ZW50IHR5cGUgaXMgbXVsdGlwYXJ0L3ZvaWNlLW1lc3NhZ2UsDQoNCg0KICAgICBQYXJzb25z ICAgICAgICAgICAgICAgICBFeHBpcmVzIDEyLzIzLzk5ICAgICAgICAgICAgICAgICAgICBbUGFn ZSA2XQ0KDCAgICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICBJTUFQIFZvaWNlICAgICAg ICAgICAgICAgICAgSnVuZSAyMywgMTk5OQ0KDQogICAgIHRoZSBcU0VFTiBmbGFnIHdvdWxkIGJl IHNldCBhZnRlciB0aGUgZmlyc3Qgdm9pY2UgbWVzc2FnZSBpcyBvcGVuZWQuDQogICAgIFRoaXMg Y291bGQgYmUgdGhlIHNwb2tlbiBuYW1lIG9mIHRoZSBzZW5kZXIgb3IgdGhlIHNwb2tlbiBzdWJq ZWN0IGFzIA0KICAgICBvcHBvc2VkIHRvIHRoZSBhY3R1YWwgdm9pY2UgbWVzc2FnZS4NCg0KICAg MTAuICBSZWZlcmVuY2VzDQoNCiAgIFsxXSAgVmF1ZHJldWlsLCBHLiwgUGFyc29ucywgRy4sICJW b2ljZSBQcm9maWxlIGZvciBJbnRlcm5ldCBNYWlsIC0gDQogICAgICAgIHZlcnNpb24gMiIsIFJG QyAyNDIxLCBTZXB0ZW1iZXIgMTk5OC4NCg0KICAgWzJdICBCcmFkbmVyLCBTLiwgIktleSBXb3Jk cyBmb3IgdXNlIGluIFJGQ3MgVG8gSW5kaWNhdGUgUmVxdWlyZW1lbnQgDQogICAgICAgIExldmVs cyIsIFJGQyAyMTE5LCBNYXJjaCAxOTk3Lg0KDQogICBbM10gIENyaXNwaW4sIE0uLCAiSU5URVJO RVQgTUVTU0FHRSBBQ0NFU1MgUFJPVE9DT0wgLSBWRVJTSU9OIDRyZXYxIiwgDQogICAgICAgIFJG QyAyMDYwLCBEZWNlbWJlciAxOTk2Lg0KDQogICBbNF0gIEZyZWVkLCBOLiwgQm9yZW5zdGVpbiwg Ti4sICJNdWx0aXB1cnBvc2UgSW50ZXJuZXQgTWFpbCANCiAgICAgICAgRXh0ZW5zaW9ucyAoTUlN RSkgUGFydCBPbmU6IEZvcm1hdCBvZiBJbnRlcm5ldCBNZXNzYWdlIEJvZGllcyIsIA0KICAgICAg ICBSRkMgMjA0NSwgTm92ZW1iZXIgMTk5Ni4NCg0KICAgWzVdICBTY2h1bHpyaW5uZSwgSC4sIFJh bywgQS4sIExhbnBoaWVyLCBSLiwgIiBSZWFsIFRpbWUgU3RyZWFtaW5nIA0KICAgICAgICBQcm90 b2NvbCAoUlRTUCkiLCBSRkMgMjMyNiwgQXByaWwgMTk5OC4NCg0KICAgWzZdICBOZXdtYW4sIEMu LCAiSU1BUCBVUkwgU2NoZW1lIiwgUkZDIDIxOTIsIFNlcHRlbWJlciAxOTk3DQoNCiAgIFs3XSAg VmF1ZHJldWlsLCBHLiwgUGFyc29ucywgRy4sICJDb250ZW50IER1cmF0aW9uIE1JTUUgSGVhZGVy IA0KICAgICAgICBEZWZpbml0aW9uIiwgUkZDIDI0MjQsIFNlcHRlbWJlciAxOTk4Lg0KDQogICBb OF0gIFBhcnNvbnMsIEcuLCBDb2hlbiwgTS4sIFZhdWRyZXVpbCwgRy4sICJWUElNIFVuaWZpZWQg TWVzc2FnZSANCiAgICAgICAgTUlNRSBTdWItVHlwZSBSZWdpc3RyYXRpb24iLCA8ZHJhZnQtZW1h LXZwaW0tdW0tMDEudHh0PiwgV29yayBJbiANCiAgICAgICAgUHJvZ3Jlc3MuDQoNCiAgIDExLiAg U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0KICAgVEJEDQoNCiAgIDEyLiAgQXV0aG9yJ3MgQWRk cmVzcw0KDQogICAgIEdsZW5uIFcuIFBhcnNvbnMNCiAgICAgTm9ydGVsIE5ldHdvcmtzDQogICAg IFAuTy4gQm94IDM1MTEsIFN0YXRpb24gQw0KICAgICBPdHRhd2EsIE9OIEsxWSA0SDcNCg0KICAg ICBQaG9uZTogKzEtNjEzLTc2My03NTgyDQogICAgIEZheDogKzEtNjEzLTc2My00NDYxDQogICAg IEVtYWlsOiBncGFyc29uc0Bub3J0ZWxuZXR3b3Jrcy5jb20NCg0KICAgMTMuICBBY2tub3dsZWRn ZW1lbnRzDQoNCiAgICAgQ2hlcnlsIEtpbmRlbiBhc3Npc3RlZCBpbiB0aGUgcHJlcGFyYXRpb24g b2YgdGhpcyBkb2N1bWVudCBpbiANCiAgICAgc3VtbWFyaXppbmcgSU1BUC1WT0lDRSBCT0YgbWVl dGluZyBub3RlcywgZW1haWwgY29tbWVudHMgDQogICAgIChub3RhYmx5IGZyb20gTWFyayBDcmlw aW4sIEp1dHRhIERlZ2VuZXIsIEpvaG4gR2FyZGluZXIgTXllcnMgDQogICAgIGFuZCBDaHJpcyBO ZXdtYW4pIGFuZCBjb21tZW50cyBmcm9tIHRoZSBJTUFQIE1haWxpbmcgTGlzdC4NCg0KICAgICBQ YXJzb25zICAgICAgICAgICAgICAgICBFeHBpcmVzIDEyLzIzLzk5ICAgICAgICAgICAgICAgICAg ICBbUGFnZSA3XQ0KDCAgICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICBJTUFQIFZvaWNl ICAgICAgICAgICAgICAgICAgSnVuZSAyMywgMTk5OQ0KDQogICAxNC4gIEZ1bGwgQ29weXJpZ2h0 IFN0YXRlbWVudA0KDQogICAiQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMTk5 OSkuICBBbGwgUmlnaHRzIFJlc2VydmVkLg0KDQogIFRoaXMgZG9jdW1lbnQgYW5kIHRyYW5zbGF0 aW9ucyBvZiBpdCBtYXkgYmUgY29waWVkIGFuZCBmdXJuaXNoZWQgdG8NCiAgb3RoZXJzLCBhbmQg ZGVyaXZhdGl2ZSB3b3JrcyB0aGF0IGNvbW1lbnQgb24gb3Igb3RoZXJ3aXNlIGV4cGxhaW4gaXQN CiAgb3IgYXNzaXN0IGluIGl0cyBpbXBsZW1lbnRhdGlvbiBtYXkgYmUgcHJlcGFyZWQsIGNvcGll ZCwgcHVibGlzaGVkIA0KICBhbmQgZGlzdHJpYnV0ZWQsIGluIHdob2xlIG9yIGluIHBhcnQsIHdp dGhvdXQgcmVzdHJpY3Rpb24gb2YgYW55IGtpbmQsDQogIHByb3ZpZGVkIHRoYXQgdGhlIGFib3Zl IGNvcHlyaWdodCBub3RpY2UgYW5kIHRoaXMgcGFyYWdyYXBoIGFyZQ0KICBpbmNsdWRlZCBvbiBh bGwgc3VjaCBjb3BpZXMgYW5kIGRlcml2YXRpdmUgd29ya3MuICBIb3dldmVyLCB0aGlzDQogIGRv Y3VtZW50IGl0c2VsZiBtYXkgbm90IGJlIG1vZGlmaWVkIGluIGFueSB3YXksIHN1Y2ggYXMgYnkg cmVtb3ZpbmcNCiAgdGhlIGNvcHlyaWdodCBub3RpY2Ugb3IgcmVmZXJlbmNlcyB0byB0aGUgSW50 ZXJuZXQgU29jaWV0eSBvciBvdGhlcg0KICBJbnRlcm5ldCBvcmdhbml6YXRpb25zLCBleGNlcHQg YXMgbmVlZGVkIGZvciB0aGUgcHVycG9zZSBvZg0KICBkZXZlbG9waW5nIEludGVybmV0IHN0YW5k YXJkcyBpbiB3aGljaCBjYXNlIHRoZSBwcm9jZWR1cmVzIGZvcg0KICBjb3B5cmlnaHRzIGRlZmlu ZWQgaW4gdGhlIEludGVybmV0IFN0YW5kYXJkcyBwcm9jZXNzIG11c3QgYmUNCiAgZm9sbG93ZWQs IG9yIGFzIHJlcXVpcmVkIHRvIHRyYW5zbGF0ZSBpdCBpbnRvIGxhbmd1YWdlcyBvdGhlciB0aGFu DQogIEVuZ2xpc2guDQoNCiAgVGhlIGxpbWl0ZWQgcGVybWlzc2lvbnMgZ3JhbnRlZCBhYm92ZSBh cmUgcGVycGV0dWFsIGFuZCB3aWxsIG5vdCBiZQ0KICByZXZva2VkIGJ5IHRoZSBJbnRlcm5ldCBT b2NpZXR5IG9yIGl0cyBzdWNjZXNzb3JzIG9yIGFzc2lnbnMuDQoNCiAgVGhpcyBkb2N1bWVudCBh bmQgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaXMgcHJvdmlkZWQgb24gYW4NCiAg IkFTIElTIiBiYXNpcyBhbmQgVEhFIElOVEVSTkVUIFNPQ0lFVFkgQU5EIFRIRSBJTlRFUk5FVCBF TkdJTkVFUklORw0KICBUQVNLIEZPUkNFIERJU0NMQUlNUyBBTEwgV0FSUkFOVElFUywgRVhQUkVT UyBPUiBJTVBMSUVELCBJTkNMVURJTkcNCiAgQlVUIE5PVCBMSU1JVEVEIFRPIEFOWSBXQVJSQU5U WSBUSEFUIFRIRSBVU0UgT0YgVEhFIElORk9STUFUSU9ODQogIEhFUkVJTiBXSUxMIE5PVCBJTkZS SU5HRSBBTlkgUklHSFRTIE9SIEFOWSBJTVBMSUVEIFdBUlJBTlRJRVMgT0YNCiAgTUVSQ0hBTlRB QklMSVRZIE9SIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiINCg0KDQoNCiAgICAg UGFyc29ucyAgICAgICAgICAgICAgICAgRXhwaXJlcyAxMi8yMy85OSAgICAgICAgICAgICAgICAg ICAgW1BhZ2UgOF0NCg== ------_=_NextPart_000_01BEC019.32A0DD92 Content-Type: application/applefile; name="draft-ema-vpim-imap-01.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-ema-vpim-imap-01.zip" AAUWAAACAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAASgAAABAAAAAJAAAAWgAAACAAAAADAAAA egAAABoAAAABAAAAlAAAGJSzmC8Ns5gvDgAAAAAAAAAAWklQIFpJUCABAANAARwAAAAAAAAAAAAA AAAAAAAAAABkcmFmdC1lbWEtdnBpbS1pbWFwLTAxLnppcFBLAwQUAAIACAAcltgmKXALBaoXAAC3 QgAAGgAQAGRyYWZ0LWVtYS12cGltLWltYXAtMDEudHh0BScMAFpQSVRURVhUTVNXRLRbbXPbOJL+ nKmb/4DSl7H3ZDqSX5J4M6lTZDnRjG25JDvZnM91BZOQhQtFaknKjubq/vs93XghKMtJ5i7j2p1I Igg0+vXpRkMI/A2zShWZqsRxIaeV+L6/d6nKMnEhizLPyp9/4t8GXxa6UKXQmSj1FzHPs2pWfn2a 87yoVCrOVfWQF5/dRP+nv9+WmRLdvbbovHr16hsTDc96F+JDrmMFoiuVlbrexaa/1wmxZkfN5c79 Qs939Fwudp53oupL9ebnn/jFSSWrZSnyqahmuhRnap7bJ0Jc0i9JHi/nKqsEPsvMc33HcF1mCT0A 66bLNBVxnk3zYi6zWNk5HnQ1ExKPFkV+r5lgWmyi4gqfRec5fRuf9LvPu4eRX7m5ChYulCBO6+zO E2SJVrUiDLI7nSlVYJTbgSw/i5O8AMO2hoPLk+220GY6WbYN8fjqZr4r8uWijEi8lcLUshJ2nhzr FPa5mMsVdlTmItFlVejbZbWJOFmKzZv5+i5ZYsE09zLViQBThcTCX/R8Oad9k6LaWay+0maIslsl lotEVippi0ItUhnTJ7yf35Z5qvC7uF3ZDdXL2LkkSXQlKj1XYMOwMrKVCwhvUWhJXMnFslSPSfdT FGqqCgUFADUYo2VKi+O1WDNT1dwuDv5m9F6LeEcaZCfAWncwxzJqBYqoRApm087jZVGQOq5TEGM2 7F3GMd7FJmVlX55V1eJod/fh4SHSqppGeXG3Sx92OzrZkbcQoYwhFdjExvXWFH4yk0n+II7hMeIq L7T6kyuX/H40q+apU4QOWN2zdIivGl9+r4p7rR6ILhJJXkIPWTnuZaFz2LHyboFY7vSM3Aa+zhWM hCymUP9cYgPeiu7ZpcylTkW5Kis1JyMgJlT5QsdetDqL02VCO4Si2t92xFsoSLESvaqS8YyJxU6y Elrgh5CzKjJowtgrh3/WS/kZdKOfJyrGkH8uVVn555MKxjon25LLROfgrlun9GPOwHh5B5mp7A7u ZpglOpaQTk1jnqzEQhYVti5h9PUAHtLFdkeWt14AV5meamx2zpODgF8c30rjGyyrmBuxXMjbVLFp KsxO5MIgvU3ESt/Tjwq0m0FYDgxJ9JQ5UtllwPLVQjH7V2A9RiwNGc7YHTF+9SpPYPVwvLBuTXYv pvKLmw1OzsrWfnd2DtoUy9s9AE+gIRKOJbvDPszsUaiOINNsVRWVhLk2lajAd/KG7NYtg6RZnNfB ANBlJzOzixmsn1Qao/OSeadSWFWRZzpe10Y4cSi3nC9S1baz1JPPl7BVMkESAbYRWuOyZGEIxGu1 mOWZqv1vrzTxg8zjVoKCcqFicBuqQbHpAeQlaoqQknAYy5cV8Rn7z8jmQipqubRNHPWGa8yUVUZh haZ9OsP0wn3CPkuopiosV+E2E2yzKdeIp7Dz2H8synmEChze6XR3u3u7r15tQg7XF6SLnZuff/oX 8U2wFcCS74A3/J+9iOcs8mTJGtN0e2urlcv5HP7tD8NFx9IkZCaJSpfxkkVeBzMn3p0Po2F/AB1n dJKKt6MTekyQoC1GRQqW5m1xDDOd30IfQevLwFKs30PkzxOvHiWrTCKgKHE+N6KaFvm8VqnAAQQ0 UFwJMAB5WZgeqYrDYAYCaNYQr0c0a74wC9PEFEIVduM96VTGOtUVOQDLCYO1siZBGygxFPKKKgNG g+QT6+EUfCbPaGLsgwaQAyNioB5lfJmXgaXOTheTRWcB1AmEgA2wAChu1aSy+T+yjv0AGJTLxQK4 OwhY3hkCoaROLm3HH1FW+CSLRP9hDBov2qmMMWrLG2hBxA5mTvy0SsJvlMrzNwzm89ijCIOpmZ5d v9sPa+RxQDS0k7vz6n1GzkvXXgbA7MPF8Ezcd92qW4DGorvf7Wxfd26+QmRAHVwiU0eIf5fEaw2u IxBhs3soEzP4ipSXOQACjq2aBdDUeVvws9U/ajFTWxN8sMGTEFIGmyhJO0E4cTJONX3DUCcydlwU GhYE+O9VumrGFPFZrQg8J8CBZ1eTy1bb/CvOR/x58n50dXpcf7K/B8bZOut9avmNeHuhSGUiAVlX sSgY+QYevdar1u+eBlLJpdEMMN5oodvuuHbK4hThOy1b4rp743R8Hx7tMRR6D7ihCr/jiSbswzI2 5oLMaOUUGx7FvB9AHKPMJb+mKwb4dirs7FZl2ExMEJsIDySQ5RV7DxUDU7GjOtyHcdO3xOAoSoQ8 riOulLpw4XMm7xWlGwoxLyGrAfOAdBnAWBJvHaAqA0aSwTayJxbJQ75MEyI3I6Ow07fFLH8gDERk aI8wiW5kcEQlo9qmHUUcPYLF9gt130EuGURH5ySIGQ6H0hYes9bOw9rGYL8y6kiaIN4Oz3vjT9ZD 6EL0exe9t8PT4eUnVmYYUIAjJss7hGBjVpypxYgIcEjljI2fmEDqKOlpmuYPhGcCE5jK+3xZUChh lSB27EfdNmQJHwr1MC8Z97Af7dcKB4vuiePeZQ+7nk6REWo4z4REdzK47L+Hkz3+dH3D2LAqEGdr 3kFs5SqrABS9dEo916nkTI0ZCZ69H/SOB+PoZDg4PZ4Y2zGuP6kzgkAO13s3zbjGpDHqtsAKomB2 31IQh+p+sckoIIJzbBnMFyjSJ4ONt4O42T8C2ovtRjtii/faiboRLbo1OO+Pjofn76wct2+2PTT6 YeCo+8PBUdMtsh76jZQMjUtjxBzyGq6MdPdseDZwfIOnJ0yxc2lNYGfg3jMeSZxolSaRuN6/8eu2 1rjWEtbnFiYlczatnFsnazVOpQ6rztA4nbCOx+T/1hnxGPP7rYw/24H8kvfreipkSpnayjmt6JnX +i5pvbXPNeVi3VVWKQiVcST6+adna9rCyvIlWkVmmpsm+uRKFcE9nh3DiNcSPqLilI2yHPARVkVp EBd9ZCVNoSvL15NfJ6+2WMDGHXfoDYoX1ssQTIOhL1Qx11VlnV+q5NT42cAWEBCI6/R8xoI0aND9 Rn4nL6nQUjvo2l/sEecy9eBYYwTKMNAFDs5jCUdqCvz9wO1hdl9pRJqo2EMQPESYIDJcBApescsw Ac+wPBzW5Cic1EgmXMVwBL/bN7pk6I+ei5PR6G1vjDGTxtPaF62NswzYdww4HkDTB7WKeLuTyb2E XO+UR+P0v8rVeDQhIooeBksACqkF0n3inAO+0NbI6RwmcktZgpybuvnvKIr+x2zgb51vDcI/rDFR LcsDtoKGpu+6yCQeZhrQnCgn0riMANPgwU4tv8RqYS0a25Ppg1yVMPQ5AGrJuk3ew+nyjtNiRPOZ 8vFeBjrKtoIVp6qKZyrhtMIMO4jEhgJQbXLfqkuFhYC2yXtMDkFAIcieXeRXbi1fiWzjGfgBgT0q BrDaLlK5Yl/kqr3T9ex6I+4on8Idxldz6YgR1JRrF5aqR2XSzQBk8I/Lwfi8d7oJgvgp1oHI5axA LlAGcARbAdAymlzXKS06sZW878UltI0NlTzMfBB1jywRB4RKrkw1R2YbhAGmxDOZ6XJel9NKkFM5 F7QmTlp1rDDDpZ6roBp4UeRVHucpUqTLycU27eJBIT3Fv4xDPVN+WMDf+6sC/nDqFDNgWM2mUEXb tQuyVYggJaDMhZjRhGoml8Gq3UNxfXDTpqecKuRUf+GDGcNIrl4EkdzKg8uCGPRlZTU+Elsf2cHE jB3n8rOJ6vmyiumkx0ZhF7XIzLa9dnSdC3b5j9f4y5EDMhtwYzs4YWhsDSi4ze6AtRoMM5DyanzK fDOeEBRRVZYnN6E3UHMaCrtAglHa0yrPku+FmyC9VSAB7xwcRDCAqLt3tH9w+KLFuNNufM9qBpbz prgsjQerjYModJXgsHTTzKfX5euH0V4m8L+wlOvDNTTuB5jDJFfrrJcr/Efm/czqiasvsYsgLaXK w5GfmuofR7u7r7Wh7c3ua2zkP8lp3+Zf3lwvdcJHWLpa3bzW+PbmGiO55udg1yGdf2w+Bajdbp+V 0ZW7yW0Zk5nTeVVdRefqOR8T0TTk0N6qWC6NP/K6rZuBhJPfOvMNEC4HQIatBJeQs5SBhwplZYUQ npQxBRYWSefd/mQkcevTTsmhei6Z7TlKLE4HeFFFBfYaWu4hA07p7WCu2VuE0LTRJzDbWuHfnVk0 AswT+S4bUqg9a7HkVtHQw2j/yCtBx6hpfVbCCmuSe1HO2NfE8P7Y/XyZVpqUdNdxRN+zvQTnLWYd piMMJeKXzPLjF8Iy2FbwAxeNaqIt3+zrfLLn6qLGDzLB1k2aRLoieOS1yOGJhSs/xrM8Lw2TnII4 COaKQJFnCFzl6JGT/HQxaLhJm/lvrbsE+MXtMJ+yutt2yRyDPFI6S5mLCHzYmFn1cO7X5/tkXt9w ipvybyZ7q9W7Oh6OWqL1bnLW2q59IwfAwOjgHH+pAqVytFlq20GON4WKh2cfh5zjhGcB1NRhew2Q TyCMbMp0HiNob+I+QTInD+SoSY1ZdnyszoR7DbEq4xhqbJ7TgcPvyn/AmiBp4ZfWU6BwyJP5T3Oe HwSA9v8aAHRIedn5o6yMQ36+MEc9dHpNhy8rZzyPcnwhXJa/OZna2qCDHIGYhheRCLBlj0+ae2Gt 0HlaPwZOzlYqScUov4hlaWJPKgtw69FxNdKQOeEj511MRMOviKtUTP/M9WZJYZa3iKjFJQ3SP3gV a5Mu4tR4yFRQjUdN8ocszWXC3R+y7rOAS2LO5X4ET/Ywy1MlGmfLwP26KClQjbIwl3jK0+vyyPPQ uvDSM4li1jobHPhJKP0yQRywImFsERwOhCXM16/J2WuZvnlTSyKfU/gulyZfpVNZPhb3awMF+nmb HQspYkgWr+ofspwLGma4KPUf3sm9BB9cd8Hpo+6C+rCErX1N/o8lb0Vuavq11Gs8YREJNRfZ/Hat sM9I1gQX2+xgXc2aDKGTgHhLXTEAMGdFYDofGOYLxazSVcDunn/Vzut7JBrTBCk5bYJaDWxo9hVh e1zymES3gJF5tuSjVj7dhvzs4YsUG47VDfpaf23BbQvmpaDlwUblhpGZHDsEVuZ80iboUYhyqjCH riOfGWlEJ+e58ULzNhRkj8seFt8ceb2BLXBB1tZbXUH2eFmYU7uNOdp+d19cv6jrkSembaLu0pCc OwUTt/3M5KJ3jI6267K+z5m4VNwOy/yPSPKgzVSHNCcg0BvL87o6YlhfHx04mND0OY8kjMRRRXfR eo06IPxobzuyVVg/u8F8DL7yQiNNI6Ws7bPrXIWmlpKryWA8Gf77INxn/XiN5Y9wOJ1gfGV5DyuD 1bnc4RY1Zak828nUncGkhgeROXKZK2nqxVw0LAPAWh/zfwVgHXXFllvKnWeY8qEZsNXphj933c8H L4Kf6/nYk9OpaLib7vpuFlKzCK0w2RAz8hzWZHiQ8W7kQmsdoVHg/meVGUj7w1DIwV9VhvnT3DZ2 8ATPndJ/P+/31nlfElSnqgCbHKJym7Q25k6lnBwSd5RRz0RC2Z3vB2UvRu2CFGBJWP+PLfIh/8aH 2KLxA4cCEaD4zo2Kzce1fuM2lfX1UP/A4/VVcPi4ns8+nciSn17vE3SxKjEHPP4ww9cuQcT6kRmd mIVl0idcBWcF4EqsnEOxtWAzuAZ5LsLZCS1lpnNhIUuLfQMEAFgDZy6RAZvo/exl5Ho7zIkfPEiD YgONg6e/MiTb/dvf7Wq/Hjx/PEbPQdVupafTvxsx/7rnV+uKyfL2v5BVPV7HPvjVGJ7j99bzo+f7 240BJ4hq/vEep4LPNhzAUCQ2S02Z+7r0CTOZyLLKqQkm5jYKJH1UJqVeyWeWZwShnQa8omIQHVVc UHVrTH2gj6HcRxcCbcnIVxrqEGxgmkU9VE+v26QIrfp6c298KcaD3nGApPgggLqm6iOTnEqbFR2k lEjOQTafBK6DKZ6Hj15MGgrphE0YXKu7VSrj9tYoQDMOWj7kAaSxWCZaK/NbDQVfX0Wd6HvLVLdP tNaWDVMOSmaulDEZDM533n7aYUb9KVt+Rfr+H/Q+HZkartMsAWhyraJ8lOxMx7ax2DbCCp7TymDK 3S4NQ3QNn2mec2O/ten1bMYUI2oJG/Mu6cwlLCGwUJuLzmRSi8wf4jL6yioqRzo86zfddZvm2RDx sPcLqwrOlNj6vTYQ0ofr9Sq5abBeq5Zwc5LrfXYjr18GTi9Id2oTSRsJDw8wxE5TeRdARURrQ3lY HKSEM3jdmb7Tc1eXqjZublNrsP7KBOSLff2Q04wdy+r2D8Uph38VTvk+3hqmNtMoajQwXAvjV+wm MCU/gmwiQyT0HphOuAtf6zIDnFuuyxBBqYYtJa6WMm0S4G88PIfY/Amiq65cd26E+AALK9RSp23x Lmo7MZgvLcOmiyKfapuONlspd+oWBeFqm91W2+VWnTbAx6Kqe3wdPdddrPy2kElGCdWElqKewI8b ewIvn+gJrJe23YF23U7nVRvkFXD7WPOFX3MPa/YLxCyd4TmtOTynM9/BpTgbTCa9dwPR6/fxSVyM R5ej/ugU+/tAaGh0Ltgh142Q+OO1nh8+b7Yx+ztVgC2wFKS2SNLOsdhboMQM0YAWp++tM7aJZUFC XGNrvUh960xsURK6bYLpKFNHZIZz2bgy490Hwq5W5QZy9w+wen6/gdwDkDuJZ8v0j0JnGRz5exA5 lnlb9PDhVGaLGR8Ljon2jQfE9VprR8VOMHvdQ8wGH5E2leHwhsuRiDhIrlkuzaM1L9hX3TWFeuGm ePEtTbZYS/jcO6wV1JQfU9quaUCtxftPavHLG9Fcpp8DMhjlWqOmtdHN1wszOcBqBk6O1R1ddZOW kPVrhcu5u1TYJpv5TBGiwX1zn8sZP913mqh4WRCWByOoZ9HM7TzB5dtjN5iu5vSWiMXFL6XoJQnN 5D2huc35MVq70Ln5duZFNIqgiV/E3kGHPIE5QBd9+3iE8PMg2wLG9Xvnk9h//6KOBXSEfST+tbNz 2NnbeXGI/x+87Dq0Ib80Hu3vH3bcxVKqkx2Ju4Wh7t8ypiuzZEVANW6XdB2iF3/O8odUJXeqWXPu A82tUvE7dRtR3ajUjOK0A4MGffpznMa1saB53tyhcAdrthmf+vCp/YZLa3lFTV+muufvNLhGdDyV t9SNSl0CcGefyXmx7/ptCdZBVe8Uu8/f8lkm3lHbfUb9nitCjEG/dn8Gn2fta5t/eeL6BLkeIusU 241+YFx+8dfE5Q41gJ/QJdh+vlgV+m5WsY6poK++VT/a6m+bU3lHwySPtYJBbNGc23wknooxjS1h fwy9HQBuXg3kRj46J06l7/mxreKUk+YLsnAu1i6LzHT9VDlNw9cwbYc5LFDfm5IVK6c9szaSoUIV XSCl8Q+abzEh0YJuab6mRxVYVkrBP5VrLSqOEqOoFH8MTdQReWvbkGgaJsPfqE241mHOJ7AAPhNe a3tcHtw2M+n6SgCnJwwAbQNnUjesylsEGVrXch/KTII1PZCaOz3lXSEXM0qaaAp/1ZEqtVTb4gMe orvcyC/I671paDcXwGiO2gqrUqVT5gNhfPDCXCQyRkykP8hV3aSGDJ8b8ew1ZnP6uUY537dz+MlB rke65IRG0/iHeXEnM3slhszddALKMmy8Z8disUA+5c0QpsH+yX24mdz9mtKIStszMHdJK1bJsjAl eprB7+FR43JNt5+QXy9Ld7OP3ndt8G2jcK57zABOq/98SYKPr1OZ3S05X69vG9Msg+yOdM5bEl1j mWvyp9x9a29NQRdMjyfrDSXSeLpQjGhJ/HwRysiSpgEYAyhO3DWYTXIgu4CAaVOUG1ubucvKp216 1rzmYxuOsQxl95rvCXhNJzXl/bV6EzGctKjFWhtVvXw/EB5ZTkb94QAZde/8uPlgcP5ueD4YjIfn 75ic3uR3cTIaI0QcDyf9097wbCJ6p6fiY2887p1fDgeTthj842JM+HQ0hre8OB0OjtuYsH96dWxn eXvFF3nE6fBseDk4phav3vknN8cnUNC7ZDKuJgOBSGQowrJnvUugXJri/WA8GJ6Lj0OsTVPhMdE4 4InGw3fvL3l9+mZpCEjEnDTH2WDcf49fXDkB40+Gl+dE+gm9y8WDYf/qtDcWF1fji9Hkf+cK2XxO xVrHAljrAABQSwECFAAUAAIACAAcltgmKXALBaoXAAC3QgAAGgAQAAAAAAABAAAApIEAAAAAZHJh ZnQtZW1hLXZwaW0taW1hcC0wMS50eHQFJwwAWlBJVFRFWFRNU1dEUEsFBgAAAAABAAEAWAAAAPIX AAA0AFppcHBlZCBpbiBjYXNlIE91dGxvb2sgbWVzc2VzIHdpdGggdGhlIFRleHQgZmlsZSA6LSk= ------_=_NextPart_000_01BEC019.32A0DD92-- From owner-ietf-imap-voice Thu Nov 4 09:39:56 1999 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA09699 for ietf-imap-voice-bks; Thu, 4 Nov 1999 09:39:56 -0800 (PST) Received: from tes1a600.um.icomverse.com ([194.90.178.67]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA09694 for ; Thu, 4 Nov 1999 09:39:46 -0800 (PST) From: dimrub@icomverse.com Received: from dmitrypc (iIM01600 [194.90.178.82]) by tes1a600.um.icomverse.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 4QK5J8NQ; Thu, 4 Nov 1999 19:52:45 +0200 To: Subject: Codec specification alternatives? Date: Thu, 4 Nov 1999 19:40:53 +0200 Message-ID: <71EDE7D51B8CD31196700050DA0EFA491BFC36@GOOFY_EX.QUANTUM.icomverse.com> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-imap-voice@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Greetings! The IMAP Voice extensions presents numerous alternatives for client's specification of the codec, it wishes to receive from the server. I'd like to learn of the current situation, namely: 1) Is there any work being done in order to elliminate some options and standardize other(s)? 2) Has anybody implemented one of the alternatives listed, and if so, which one? After some thought, we decided to use the client capability mechanism for codec specification. Assuming we're not the only ones, we'd like to coordinate the effort of specifying this extension formally in order to create a sort of 'de facto' standard which may (or may not) be adapted at later stage by additional parties. Also, what is the status of the rest of the draft? Any work planned to be done during the next IETF meeting? -- Dmitry Rubinstein From owner-ietf-imap-voice Wed Jul 19 17:55:59 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA04525 for ietf-imap-voice-bks; Wed, 19 Jul 2000 17:55:59 -0700 (PDT) Received: from yahoo.com (216-164-132-57.s311.tnt2.lnhva.md.dialup.rcn.com [216.164.132.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA04430; Wed, 19 Jul 2000 17:55:29 -0700 (PDT) From: Subject: Tuition-Free Computer and IT Training for Non-Profit Employees Date: Wed, 19 Jul 2000 21:01:39 Message-Id: <714.828941.257890@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tuition-Free Computer and IT Training for Non-Profit Employees Dear Non-Profit Employee, Most non-profit employees want to improve their computer skills. However, high cost of training and a busy schedule have held them back. Now, the National Education Foundation (NEF) CyberLearning, a non-profit organization, dedicated to bridging the "Digital Divide," offers the Nation's non-profit employees a unique opportunity. With the support of Microsoft and others, NEF CyberLearning is now able to offer full tuition scholarships of $2,000 to the first 10,000 applicants, thus enabling them to take any or all of the 400+ Internet-based online personal computing and computer professional courses from anywhere at any time. The high-quality, user-friendly courses are either self-study or instructor-led. They cover all levels and almost all topics, including Computer Basics, Internet Basics, Web Design Basics, Networking Basics, Programming Basics, A+, Network+, MCSE, CNE, Microsoft Office, MOUS, WordPerfect, Lotus, Operating Systems, Windows, Windows 2000, Linux, Unix, Networking, WAN, LAN, Programming, Java, C++, Visual Basics, Internet, Web Design, Web Applications, Web Master, E-commerce, Databases, Oracle and Cisco. To sign up, just visit www.cyberlearning.org, click on "Free IT Training," complete the application and pay a nominal registration fee of $75 with an organization/personal credit card. This $75 is your only cost, since the tuition is free for you. Many non-profit organizations reimburse the $75. You can receive immediate access to all 400+ online courses, an online library of the latest 1,000+ computer/information technology books, instructor assistance, course-specific chat areas and round the clock technical support. Please feel free to forward this information to interested colleagues and others in non-profit organizations. If your department or division wants to sign up a group of employees, please indicate so in your reply and provide contact information. If you received this e-mail, it is because you are listed as a contact person or employee of a non-profit organization. If you do not wish to receive any further scholarship information from us, please reply with the message, "remove" in the Subject line. Thank you. The non-profit National Education Foundation (NEF) CyberLearning has provided tuition-free IT training to thousands of students, teachers, government and non-profit employees and disadvantaged individuals. It has earned many distinctions including "The Ivy League of IT Training," "1995 Fairfax Human Rights Award Winner," and " A Leader in Bridging the Digital Divide." "You are helping to empower America. I salute you for your ongoing commitment to creating a better America," --- President Clinton "This is an awesome opportunity." --- Washingtonjobs.com "Microsoft is pleased to play a part ... NEF can make a positive difference in the lives of a great number of individuals." --- Microsoft "I have found the CyberLearning online courses to be extremely easy and useful. I liked pre-course self-assessment and IT books online and available 24/7. The course screens were interactive and made me feel as if I was in the application itself. The site looks and feels very professional. The list of courses is huge. It includes something for almost everyone. I find this to be a very worthy cause." --- Ken Horowitz, IT Training Coordinator. From owner-ietf-imap-voice Tue Nov 21 14:08:19 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA13512 for ietf-imap-voice-bks; Tue, 21 Nov 2000 14:08:19 -0800 (PST) Received: from gollum.esys.ca (dhcp198-59.esys.ca [198.161.92.59]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA13507; Tue, 21 Nov 2000 14:08:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gollum.esys.ca (8.11.1/8.11.1) with ESMTP id eALM8o803996; Tue, 21 Nov 2000 15:08:50 -0700 (MST) (envelope-from lyndon@gollum.esys.ca) Message-Id: <200011212208.eALM8o803996@gollum.esys.ca> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Mark Crispin cc: IMAP Extensions WG , ietf-imap-voice@imc.org Subject: Re: draft-nerenberg-imap-binary-00.txt In-Reply-To: Message from Mark Crispin of "Tue, 21 Nov 2000 12:58:19 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Nov 2000 15:08:50 -0700 From: Lyndon Nerenberg Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > The subject draft attempts to fufill a needed requirement for the VPIM folks. Initially that was the case, although I certainly think this extension has a use outside of that context. > However, I object strongly to the "BODY[x.y.BINARY]" syntax. Unlike other > section specifiers, this one would stipulate a transformation of a section > rather than identify a unique section. It also adds complexity (the "terminal > MIME body part" rule) as a side effect of overloading location syntax (the > section specifier) with transformation instructions ("BINARY"). I'll agree with that. I'm not particularly happy with that syntax either. I needed something as a starting point (and was under the gun to meet the submission deadline, so I didn't have a chance to work out anything better), so I went with the syntax in the original VPIM proposal. > Furthermore, this extension does not really address the complete need, which > is a general ability to transform/deliver message data in extended forms. For > example, a streaming application may wish to specify a separate host/port for > delivery of the data. It may be desireable to request the server to transform > text data to UTF-8. And this is something VPIM originally requested (general conversions). I don't like overloading (or combining, I guess) BINARY with data conversion. BINARY provides a single piece of functionality: undoing of content transfer encodings. This is neutral to the actual content. If there is a need to do actual conversion of the underlying data, that should be handled separately. Character set conversions (such as your UTF8 example) are a bit fuzzy, sitting in between BINARY and general data conversions. I'm not sure where that actually fits in, but again I think that's a separate issue from BINARY itself. > I believe therefore that this functionality belongs in a new command, e.g. > something like > tag XFETCH (BINARY) 1 BODY[x.y] > tag XFETCH (CHARSET=UTF-8) 1 BODY[x.y] > tag XFETCH (BINARY CHANNEL=[1.2.3.4]:432) 1 BODY[x.y] > etc. These examples are to demonstrate the concept; the exact syntax to be > determined. I hadn't realized that you and Steve had been discussing this, otherwise I would have held off with BINARY for a bit. I like the XFETCH architecture, however I'm not convinced (yet) that a server should have to implement external channel support just to get BINARY. At this point I think the two are really distinct issues, and should be separate extensions. I don't think implementing channel necessarily requires the BINARY extensions be present. The external channel may already be 8bit clean, and the specification for that profile of the channel target mechanism could explicitly state that the channel is 8bit clean, therefore there's no need for the server to also implement BINARY if the implementer doesn't feel it adds significant value. It's still very early in the game, though, so I don't consider any of this cast in stone. I'm looking forward to seeing a more complete specification for XFETCH. > We should also have a syntax for literal8s that are output in the case of an > XFETCH that would output on the IMAP channel, so the client can distinguish a > literal8 from an ordinary literal. Otherwise there would be an ambiguity due > to the unsolicited data model of IMAP, and the client would have to depend > upon a command modality that IMAP espressly forbids. This shouldn't be necessary. The server will only send a literal8 at the specific request of the client, and they will never show up in an unsolicited response. It's not a big deal, though. If concensus is for a unique syntax for literal8 that's an easy change to make. --lyndon From owner-ietf-imap-voice Tue Nov 21 14:13:27 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA13653 for ietf-imap-voice-bks; Tue, 21 Nov 2000 14:13:27 -0800 (PST) Received: from gollum.esys.ca (dhcp198-59.esys.ca [198.161.92.59]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA13649; Tue, 21 Nov 2000 14:13:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gollum.esys.ca (8.11.1/8.11.1) with ESMTP id eALMDw804079; Tue, 21 Nov 2000 15:13:58 -0700 (MST) (envelope-from lyndon@gollum.esys.ca) Message-Id: <200011212213.eALMDw804079@gollum.esys.ca> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Alexey Melnikov cc: Mark Crispin , IMAP Extensions WG , ietf-imap-voice@imc.org Date: Tue, 21 Nov 2000 15:13:58 -0700 From: Lyndon Nerenberg Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Subject: Re: draft-nerenberg-imap-binary-00.txt In-Reply-To: Your message of "Tue, 21 Nov 2000 14:46:09 MST." <3A1AED20.68CE1CC@messagingdirect.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii -------- > To the best of my knowledge Lyndon will be writing another draft (superset of the > current) that will address VPIM stuff (general ability to transform/deliver message > in a different format or over a different channel). No. The intent was to explicitly address only the content-transfer-encoding issue. General conversion of body content is a large can of fish bait that I'm not going to go anywhere near. I think channel is very useful, but it's a separate issue from that which BINARY addresses. --lyndon From owner-ietf-imap-voice Tue Nov 21 14:21:10 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA13900 for ietf-imap-voice-bks; Tue, 21 Nov 2000 14:21:10 -0800 (PST) Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA13889; Tue, 21 Nov 2000 14:21:03 -0800 (PST) Received: from mailhost1.u.washington.edu (mailhost1.u.washington.edu [140.142.32.2]) by mxout1.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW99.09) with ESMTP id OAA28380; Tue, 21 Nov 2000 14:21:51 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (foo@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost1.u.washington.edu (8.9.3+UW00.02/8.9.3+UW00.01) with ESMTP id OAA13943; Tue, 21 Nov 2000 14:21:50 -0800 Date: Tue, 21 Nov 2000 14:10:31 -0800 (PST) From: Mark Crispin Subject: Re: draft-nerenberg-imap-binary-00.txt To: Lyndon Nerenberg cc: IMAP Extensions WG , ietf-imap-voice@imc.org In-Reply-To: <200011212208.eALM8o803996@gollum.esys.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 21 Nov 2000 15:08:50 -0700, Lyndon Nerenberg wrote: > > However, I object strongly to the "BODY[x.y.BINARY]" syntax. > I'll agree with that. I'm not particularly happy with that syntax either. > I needed something as a starting point OK, good. I'm happy with a stipulation that we're going to fix that. I don't want to stand in the way of the functionality, but that particular syntax has got to go. > And this is something VPIM originally requested (general conversions). I > don't like overloading (or combining, I guess) BINARY with data conversion. Isn't converting QP and BASE64 to BINARY a form of data conversion? > I hadn't realized that you and Steve had been discussing this, otherwise > I would have held off with BINARY for a bit. That's why I was a bit surprised to see your document! :-) > I like the XFETCH architecture, > however I'm not convinced (yet) that a server should have to implement > external channel support just to get BINARY. At this point I think the > two are really distinct issues, and should be separate extensions. OK with me. My guiding principle (consider XLIST) is that if it's trivial to bundle two things together and less work than having them separate, then bundle them; but if there's a reason why someone may want one and not the other, then keep them separate. If you feel that BINARY vs. external channel support is the latter, I won't squawk. [I'd appreciate the return favor when we talk about XLIST vs. subscriptions........] > > XFETCH that would output on the IMAP channel, so the client can > > distinguish a literal8 from an ordinary literal. > This shouldn't be necessary. The server will only send a literal8 at > the specific request of the client, and they will never show up in > an unsolicited response. It's not a big deal, though. If concensus is > for a unique syntax for literal8 that's an easy change to make. Mr. IMAP Architecture says that it's presumptious to say that "they will never show up in an unsolicited responses." The presumption may be valid for literal8 (and certainly right now it is), but it isn't for literal; and that's what creates the ambiguity. We don't want the situation where a client gets a literal and thinks that it's a literal8. I suggest some added little token in literal8, perhaps {###}~ instead of {###} to indicate its special nature. From owner-ietf-imap-voice Tue Nov 21 14:37:44 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA14274 for ietf-imap-voice-bks; Tue, 21 Nov 2000 14:37:44 -0800 (PST) Received: from gollum.esys.ca (dhcp198-59.esys.ca [198.161.92.59]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14269; Tue, 21 Nov 2000 14:37:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gollum.esys.ca (8.11.1/8.11.1) with ESMTP id eALMcK804217; Tue, 21 Nov 2000 15:38:20 -0700 (MST) (envelope-from lyndon@gollum.esys.ca) Message-Id: <200011212238.eALMcK804217@gollum.esys.ca> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Mark Crispin cc: IMAP Extensions WG , ietf-imap-voice@imc.org Subject: Re: draft-nerenberg-imap-binary-00.txt In-Reply-To: Message from Mark Crispin of "Tue, 21 Nov 2000 14:10:31 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Nov 2000 15:38:20 -0700 From: Lyndon Nerenberg Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Isn't converting QP and BASE64 to BINARY a form of data conversion? No, it's a change of transport encoding. The contents of the body part at the client matches the contents of what the sender sent regardless of where the transport encoding is undone (i.e. at the client vs. at the server). The decoded data is the same, so it's not a data conversion. If, however, the server _also_ does character set manipulations on the way through, the decoded data at the client might not match what the sender initially sent. _That_ I consider to be data conversion. > > I hadn't realized that you and Steve had been discussing this, otherwise > > I would have held off with BINARY for a bit. > That's why I was a bit surprised to see your document! :-) So was Steve :-) I apologise for starting all this confusion. > I suggest some added little token in literal8, perhaps {###}~ instead of {###} > to indicate its special nature. I can live with that. If people are okay with the syntax I'll incorporate that into the next draft. Any suggestions for a modified FETCH...BINARY syntax while we're at it? --lyndon From owner-ietf-imap-voice Wed Nov 22 13:53:44 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA03368 for ietf-imap-voice-bks; Wed, 22 Nov 2000 13:53:44 -0800 (PST) Received: from zrtps06s.us.nortel.com ([47.140.48.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA03345; Wed, 22 Nov 2000 13:53:36 -0800 (PST) Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Wed, 22 Nov 2000 16:40:00 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Wed, 22 Nov 2000 16:38:17 -0500 Message-ID: <488891341182D4118A870000F80822E782B74B@zcard00p.ca.nortel.com> From: "Glenn Parsons" To: "'Lyndon Nerenberg'" Cc: IMAP Extensions WG , ietf-imap-voice@imc.org Subject: RE: draft-nerenberg-imap-binary-00.txt Date: Wed, 22 Nov 2000 16:38:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C054CC.83B8ECD0" X-Orig: Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C054CC.83B8ECD0 Content-Type: text/plain > > > I hadn't realized that you and Steve had been discussing this, > otherwise > > > I would have held off with BINARY for a bit. > > > That's why I was a bit surprised to see your document! :-) > > So was Steve :-) I apologise for starting all this confusion. > So is Steve still planning to do a draft on this :-) > > I like the XFETCH architecture, > > however I'm not convinced (yet) that a server should have to implement > > external channel support just to get BINARY. At this point I think the > > two are really distinct issues, and should be separate extensions. > > OK with me. > The other VPIM requirements from the expired draft-ema-vpim-imap-01.txt (but still on www.vpim.org) are: This document is an overview of proposals for various extensions to IMAP to meet the requirements of voice mail systems. The topics included are - Binary Attachment transfer - External Reference - Alternate Codec Request - Streaming audio attachments - Message length Indicator - Body part read indicator Steve indicated to me last week that he would combine the first two into one proposal. Do we expect two proposals now? Thanks, Glenn. ------_=_NextPart_001_01C054CC.83B8ECD0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: draft-nerenberg-imap-binary-00.txt

    > > I hadn't realized that you = and Steve had been discussing this, otherwise
    > > I would have held off with = BINARY for a bit.

    > That's why I was a bit surprised = to see your document!  :-)

    So was Steve :-)  I apologise = for starting all this confusion.

So is Steve still planning to = do a draft on this :-)

    > I like the XFETCH = architecture,
    > however I'm not convinced (yet) = that a server should have to implement
    > external channel support just = to get BINARY. At this point I think the
    > two are really distinct issues, = and should be separate extensions.

    OK with me.

The other VPIM requirements = from the expired draft-ema-vpim-imap-01.txt (but still on www.vpim.org) = are:

        This document is an overview = of proposals for various extensions to =0D     IMAP = to meet the requirements of voice mail systems.  The topics = =0D     included are =0D     - = Binary Attachment transfer=0D     - External = Reference =0D     - Alternate Codec = Request=0D     - Streaming audio = attachments=0D     - Message length = Indicator=0D     - Body part read = indicator

Steve indicated to me last = week that he would combine the first two into one proposal.  Do we = expect two proposals now?

Thanks,
Glenn.

------_=_NextPart_001_01C054CC.83B8ECD0-- From owner-ietf-imap-voice Wed Nov 22 14:40:26 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA05027 for ietf-imap-voice-bks; Wed, 22 Nov 2000 14:40:26 -0800 (PST) Received: from gollum.esys.ca (dhcp198-59.esys.ca [198.161.92.59]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA05022; Wed, 22 Nov 2000 14:40:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gollum.esys.ca (8.11.1/8.11.1) with ESMTP id eAMMaZl44204; Wed, 22 Nov 2000 15:36:35 -0700 (MST) (envelope-from lyndon@messagingdirect.com) Date: Wed, 22 Nov 2000 15:36:35 -0700 (MST) From: Lyndon Nerenberg X-Sender: lyndon@gollum.esys.ca To: Glenn Parsons cc: IMAP Extensions WG , ietf-imap-voice@imc.org Subject: RE: draft-nerenberg-imap-binary-00.txt In-Reply-To: <488891341182D4118A870000F80822E782B74B@zcard00p.ca.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Steve indicated to me last week that he would combine the first two into one > proposal. Do we expect two proposals now? Steve's proposal for XFETCH includes support for both binary fetch and specifying external transfer channels for a fetch. (Among other things.) My proposal provides binary fetch (only) for servers that don't want/need to support XFETCH. The two can live side-by-side. Time will show if BINARY has enough support (in the presence of XFETCH) to move forward. --lyndon From owner-ietf-imap-voice Wed Nov 22 16:22:09 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id QAA07483 for ietf-imap-voice-bks; Wed, 22 Nov 2000 16:22:09 -0800 (PST) Received: from mail.connectedsystems.com (host16.connectedsystems.com [205.227.183.113]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA07457; Wed, 22 Nov 2000 16:22:03 -0800 (PST) Received: from software-caleb (red.hq.connsys.com [192.168.0.32]) by mail.connectedsystems.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id WMN2D8WF; Wed, 22 Nov 2000 16:19:37 -0800 From: "Caleb Clausen" To: IMAP Extensions WG , ietf-imap-voice@imc.org Date: Wed, 22 Nov 2000 16:24:35 -0800 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: RE: draft-nerenberg-imap-binary-00.txt Message-ID: <3A1BF343.14592.1866F6A@localhost> References: <488891341182D4118A870000F80822E782B74B@zcard00p.ca.nortel.com> In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.12c) Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From: Lyndon Nerenberg > > Steve indicated to me last week that he would combine the first two into one > > proposal. Do we expect two proposals now? > > Steve's proposal for XFETCH includes support for both binary fetch and > specifying external transfer channels for a fetch. (Among other > things.) > > My proposal provides binary fetch (only) for servers that don't want/need > to support XFETCH. > > The two can live side-by-side. Time will show if BINARY has enough > support (in the presence of XFETCH) to move forward. since everyone likes the XFETCH syntax so much better, why not do this: have separate capabilities for XFETCH itself, as well as all of it's options. so, the XFETCH document would define the following capabilities: XFETCH XFETCH-BINARY XFETCH-CHANNEL XFETCH-CHARSET etc. that way, servers which just want to provide a binary version of fetch could declare just XFETCH and XFETCH-BINARY. servers that want all of it would declare all the XFETCH capabilities. or is this too great a proliferation of capabilities? one question: will XFETCH work with the UID command? ie, will i be able to say, tag UID XFETCH (BINARY) 1009 etc... "The battle for mental territory is glory. End of story." --KRS-ONE From owner-ietf-imap-voice Wed Nov 22 16:22:15 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id QAA07513 for ietf-imap-voice-bks; Wed, 22 Nov 2000 16:22:15 -0800 (PST) Received: from mail.connectedsystems.com (host16.connectedsystems.com [205.227.183.113]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA07493; Wed, 22 Nov 2000 16:22:12 -0800 (PST) Received: from software-caleb (red.hq.connsys.com [192.168.0.32]) by mail.connectedsystems.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id WMN2D8WD; Wed, 22 Nov 2000 16:19:37 -0800 From: "Caleb Clausen" To: IMAP Extensions WG , ietf-imap-voice@imc.org Date: Wed, 22 Nov 2000 16:24:35 -0800 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: draft-nerenberg-imap-binary-00.txt Message-ID: <3A1BF343.30676.1866F93@localhost> In-reply-to: <200011212208.eALM8o803996@gollum.esys.ca> References: Message from Mark Crispin of "Tue, 21 Nov 2000 12:58:19 PST." X-mailer: Pegasus Mail for Win32 (v3.12c) Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From: Lyndon Nerenberg > > I believe therefore that this functionality belongs in a new command, e.g. > > something like > > tag XFETCH (BINARY) 1 BODY[x.y] > > tag XFETCH (CHARSET=UTF-8) 1 BODY[x.y] > > tag XFETCH (BINARY CHANNEL=[1.2.3.4]:432) 1 BODY[x.y] > > etc. These examples are to demonstrate the concept; the exact syntax to be > > determined. > > I hadn't realized that you and Steve had been discussing this, otherwise > I would have held off with BINARY for a bit. I like the XFETCH architecture, > however I'm not convinced (yet) that a server should have to implement > external channel support just to get BINARY. At this point I think the i would like to go on the record as one imap client implementor that would be very much interested in a BINARY FETCH. we have no use for CHANNEL at the moment... so i think these 2 concepts definitely should be separated. i'd also like to enumerate some of the problems i see with CHANNEL as sketched out in the example above. transport protocol it isn't too clear from the example whether udp or tcp transport is envisioned. i think that the original impetus for this proposal within vpim was to enable the voice data to be delivered via voip (that is, rtp over udp.) in that context, tcp transport doesn't gain anything. if udp is used for delivery, you then have to consider what happens when a packet gets dropped. voip uses fancy error-tolerant codecs to handle this case. the codec currently on the table for ivm (gsm) has no such abilities, so when a packet gets dropped, the rest of the file will be corrupted. of course, you could have the server translate the voice data into a fancy error-tolerant codec on the fly. probably a good use for the data-conversion feature of XFETCH? nat embedding ip addresses and port numbers within tcp payload is a sure way to break network address translators. it also makes imap dependant on ipv4, complicating the transition to ipv6. these are two reasons to avoid it altogether. if ip addresses and ports must be embedded, you should at least try to avoid the minor disaster that ftp creates for nat by always 0- padding the ip address octets and the port so that they always come out to exactly the same length. for example, instead of: tag XFETCH (BINARY CHANNEL=[1.2.3.4]:432) 1 BODY[x.y] you'd have: tag XFETCH (BINARY CHANNEL=[001.002.003.004]:00432) 1 BODY[x.y] (sorry about the line wrap.) this will still break nat, of course, but at least it will be easier to write a custom nat protocol handler for imap. "The battle for mental territory is glory. End of story." --KRS-ONE From owner-ietf-imap-voice Fri Nov 24 10:56:22 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA11899 for ietf-imap-voice-bks; Fri, 24 Nov 2000 10:56:22 -0800 (PST) Received: from gollum.esys.ca (dhcp198-59.esys.ca [198.161.92.59]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA11893; Fri, 24 Nov 2000 10:56:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gollum.esys.ca (8.11.1/8.11.1) with ESMTP id eAOIvDg00977; Fri, 24 Nov 2000 11:57:13 -0700 (MST) (envelope-from lyndon@gollum.esys.ca) Message-Id: <200011241857.eAOIvDg00977@gollum.esys.ca> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Lyndon Nerenberg To: IMAP Extensions WG , ietf-imap-voice@imc.org Subject: IMAP BINARY -01 draft available X-URL: http://www.messagingdirect.com/ Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_-19606496970" Date: Fri, 24 Nov 2000 11:57:13 -0700 Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart MIME message. --==_Exmh_-19606496970 Content-Type: text/plain; charset=us-ascii I've upodated the draft to include this weeks feedback. I also fleshed out the missing pieces. At this point I consider it pretty much complete. The I-D submission autoreponder message isn't clear (to me) about whether this will get published before the San Diego meeting. Meanwhile, you can grab a copy from: ftp://ftp.esys.ca/pub/staff/lyndon/drafts/draft-nerenberg-imap-binary-01.txt --lyndon --==_Exmh_-19606496970 Content-Type: message/external-body; name="draft-nerenberg-imap-binary-01.txt"; site="ftp.messagingdirect.com"; access-type=ANON-FTP; directory="/pub/staff/lyndon/drafts"; mode="ascii" Content-Description: draft-nerenberg-imap-binary-01.txt Content-Disposition: attachment; filename="imap-binary-extref" Content-Type: text/plain Content-ID: --==_Exmh_-19606496970-- From owner-ietf-imap-voice Mon Nov 27 09:21:54 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA17134 for ietf-imap-voice-bks; Mon, 27 Nov 2000 09:21:54 -0800 (PST) Received: from chi6-1.relay.mail.uu.net (chi6-1.relay.mail.uu.net [199.171.54.98]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17128; Mon, 27 Nov 2000 09:21:51 -0800 (PST) Received: from mcnc-mdm1-ex07.marriott.com by chi6sosrv11.alter.net with ESMTP (peer crosschecked as: host036.marriott.com [162.130.1.36]) id QQjrdl02155; Mon, 27 Nov 2000 17:23:01 GMT Received: by mcnc-mdm1-ex07.marriott.com with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Nov 2000 12:23:01 -0500 Message-ID: <7B1963F06D7FD411A9AA00508B66D2A007A6A6@mcncmdm1exis10.marriott.com> From: "Zirkle, Michelle" To: "'Lyndon Nerenberg'" , Glenn Parsons Cc: IMAP Extensions WG , ietf-imap-voice@imc.org Subject: RE: draft-nerenberg-imap-binary-00.txt Date: Mon, 27 Nov 2000 12:22:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Is this some sort of internet list? I am sure that I am not supposed to be receiving this email. -----Original Message----- From: Lyndon Nerenberg [mailto:lyndon@messagingdirect.com] Sent: Wednesday, November 22, 2000 5:37 PM To: Glenn Parsons Cc: IMAP Extensions WG; ietf-imap-voice@imc.org Subject: RE: draft-nerenberg-imap-binary-00.txt > Steve indicated to me last week that he would combine the first two into one > proposal. Do we expect two proposals now? Steve's proposal for XFETCH includes support for both binary fetch and specifying external transfer channels for a fetch. (Among other things.) My proposal provides binary fetch (only) for servers that don't want/need to support XFETCH. The two can live side-by-side. Time will show if BINARY has enough support (in the presence of XFETCH) to move forward. --lyndon From owner-ietf-imap-voice Tue Nov 28 16:20:07 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA18632 for ietf-imap-voice-bks; Tue, 28 Nov 2000 16:20:07 -0800 (PST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA18598; Tue, 28 Nov 2000 16:19:27 -0800 (PST) Received: from westmail2.West.Sun.COM ([129.153.100.30]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11817; Tue, 28 Nov 2000 16:20:54 -0800 (PST) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA14702; Tue, 28 Nov 2000 16:20:53 -0800 (PST) Date: Tue, 28 Nov 2000 16:20:14 -0800 From: Chris Newman To: Lyndon Nerenberg cc: IMAP Extensions WG , ietf-imap-voice@imc.org Subject: Re: draft-nerenberg-imap-binary-00.txt Message-ID: <2540808.3184417214@nifty-jr.west.sun.com> In-Reply-To: <200011212238.eALMcK804217@gollum.esys.ca> X-Mailer: Mulberry/2.0.5 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Issues with the binary extension: (1) I concur with Mark's comments about syntax. The current proposed syntax is unacceptable, the XFETCH strawman seems workable (with associated XFETCH response). I could also deal with a fetch-item modifier as an alternative to a new command: C: A002 FETCH 1:5 BODY[1] S: * 1 FETCH (BODY[1] {#}...) or C: A002 FETCH 1:5 BODY[1] S: * 1 FETCH (BODY[1] {#}...) With that syntax, each modifier would have to describe how it interacts with various fetch items, for example, SIZE would return the size after removal of base64/QP encoding. (2) I am currently opposed to a distinguished syntax for binary literals on the grounds that it introduces two silly states: a binary literal with non-binary content and a non-binary literal with binary content. (In unextended IMAP, the latter is simply a protocol violation which robust implementations should detect.) I would much prefer the statement that if the server advertises XFETCH BINARY, then the prohibition on the client sending binary literals for message content is lifted, and if the client issues the XFETCH command with BINARY option, then the prohibition on the server sending binary message content is lifted. (3) If the concensus is against me on point 2, then I object to using a suffix to indicate a binary literal on the grounds that it breaks existing LITERAL+ detectors. That objection would not apply to a prefix character. (4) If a server advertises XFETCH BINARY, that should permit the use of binary CTE and binary literal content in APPEND. (5) An unextended IMAP server is required to convert a body part with a binary CTE to base64. An IMAP message store could receive a binary body part via the binary SMTP extension or an APPEND command (it is currently illegal protocol to have a true binary CTE in an APPEND). If we ever want to support binary body parts signed by PGP or S/MIME, then we need a way to distinguish the canonical CTE from the requested/supplied CTE. I don't have a strong opinion one way or the other, but the issue needs to be considered. (6) BINARY and CHARSET=UTF8 conversions are no brainers (since an IMAP server with a halfway decent SEARCH command already implements them internally). But the CHANNEL model is both very important for conversions not likely to be built into an IMAP server and rather tricky to get right due to security/firewall issues. (7) I suggest we have an XFETCH (MD5) modifier, which computes the MD5 hash of the specified fetch BODY item -- MD5 is just a content conversion which happens to have a fixed size output. May make channel security issues simpler, and could permit verification of PGP or S/MIME signatures without fetching all parts. Note that I believe the CHANNEL mechanism in combination with an extension to the SMTP-SUBMIT protocol is the correct way to provide the ability to forward/resend an attachment without downloading it. - Chris From owner-ietf-imap-voice Wed Nov 29 10:33:09 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA01511 for ietf-imap-voice-bks; Wed, 29 Nov 2000 10:33:09 -0800 (PST) Received: from gollum.esys.ca (dhcp198-59.esys.ca [198.161.92.59]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA01503; Wed, 29 Nov 2000 10:33:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gollum.esys.ca (8.11.1/8.11.1) with ESMTP id eATIXXT01603; Wed, 29 Nov 2000 11:33:33 -0700 (MST) (envelope-from lyndon@gollum.esys.ca) Message-Id: <200011291833.eATIXXT01603@gollum.esys.ca> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Lyndon Nerenberg To: Chris Newman cc: IMAP Extensions WG , ietf-imap-voice@imc.org Subject: Re: draft-nerenberg-imap-binary-00.txt In-reply-to: Your message of "Tue, 28 Nov 2000 16:20:14 PST." <2540808.3184417214@nifty-jr.west.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Nov 2000 11:33:33 -0700 Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Chris, have you seen the -01 version of the draft? It contains two substantial changes: 1) The command syntax was changed to "FETCH n BINARY[x.y]" 2) The literal8 syntax is now "~{nnn}CRLF..." The -01 document was submitted last week but isn't yet in the repository. For now you can FTP it from: ftp://ftp.messagingdirect.com/pub/staff/lyndon/drafts/draft-nerenberg-imap-bina ry-01.txt --lyndon From owner-ietf-imap-voice Wed Nov 29 15:36:31 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA18893 for ietf-imap-voice-bks; Wed, 29 Nov 2000 15:36:31 -0800 (PST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA18869; Wed, 29 Nov 2000 15:36:18 -0800 (PST) Received: from westmail2.West.Sun.COM ([129.153.100.30]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA18254; Wed, 29 Nov 2000 15:37:51 -0800 (PST) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA01239; Wed, 29 Nov 2000 15:37:50 -0800 (PST) Date: Wed, 29 Nov 2000 15:37:09 -0800 From: Chris Newman To: Lyndon Nerenberg cc: IMAP Extensions WG , ietf-imap-voice@imc.org Subject: Re: draft-nerenberg-imap-binary-00.txt Message-ID: <3867275.3184501029@nifty-jr.west.sun.com> In-Reply-To: <200011291833.eATIXXT01603@gollum.esys.ca> X-Mailer: Mulberry/2.0.5 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I read that spec. It addresses point 3 from my previous post, and partially addresses point 1. However, it introduces additional syntax issues: (1a) I'm not convinced that the syntax model is appropriately general for similar conversion operations. While I'm not opposed to binary moving forward by itself, it shouldn't move forward until we are confident that we're not creating lots of special case syntax variants. (1b) I'm not convinced the restriction to leaf nodes is a good idea. For example, a disconnected client which is caching entire messages could recognize a significant performance benefit if it fetched the entire message with all base64/QP encoding that's not in a security multipart removed. (1c) It does not specify a syntax to request the size of a decoded body part. A minor nit -- I wouldn't call a binary literal "literal8". Vanilla IMAP literals already support 8-bit (when appropriately labelled). - Chris --On Wednesday, November 29, 2000 11:33 -0700 Lyndon Nerenberg wrote: > Chris, have you seen the -01 version of the draft? It contains two > substantial changes: > > 1) The command syntax was changed to "FETCH n BINARY[x.y]" > > 2) The literal8 syntax is now "~{nnn}CRLF..." > > The -01 document was submitted last week but isn't yet in the > repository. For now you can FTP it from: > > ftp://ftp.messagingdirect.com/pub/staff/lyndon/drafts/draft-nerenberg-ima > p-bina ry-01.txt > > --lyndon > From owner-ietf-imap-voice Wed Dec 6 20:58:55 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id UAA23750 for ietf-imap-voice-bks; Wed, 6 Dec 2000 20:58:55 -0800 (PST) Received: from bsd.gymparnr.sk (bsd.gymparnr.sk [195.168.176.67]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA23732 for ; Wed, 6 Dec 2000 20:58:52 -0800 (PST) From: hjghjgjh@yahoo.com Received: (qmail 16827 invoked from network); 6 Dec 2000 00:18:40 -0000 Received: from 1cust62.tnt1.los-angeles.ca.da.uu.net (HELO qZ43dC99W?) (63.57.183.62) by bsd.gymparnr.sk with SMTP; 6 Dec 2000 00:18:40 -0000 DATE: 05 Dec 00 4:38:16 PM Message-ID: <0B7w21I282m6H7> SUBJECT: 1+1=2 Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The Internet's Finest and Most Reliable Bulk Email Provider! Since 1996, Tech Data Technologies has provided bulk email service to thousands of well-satisfied customers. We offer the most competitive prices in the industry, made possible by our high percentage of repeat business. We have the most advanced, direct email technology, employed by only a knowledgeable few in the world. Our expert programmers have made it possible for us to penetrate any email blocking filter in use. We have over 120 million active email addresses, increasing our list at the rate of half a million to one million a month. We will put your product or service instantly and directly into the hands of millions of prospects! You will have instant, guaranteed results, something no other form of marketing can claim. Our turn around time is a remarkable 24 hours. Our email addresses are sorted by country, state and target. Your marketing campaign will speed with pinpoint accuracy to your desired audience! Your message can be presented in any language you wish, as plain text if you desire simplicity, or in html with color and graphics. Call us for a free consultation at (323)- 851- 8386 [U.S.A.]. We are open 24 hours a day, 7 days a week. No one understands the global market like we do. For a limited time, take advantage of our holiday special -- two million general U.S. emails for just $450 per million! We include, at no cost, a bullet proof email address for 30 days, a $400 value! BULK EMAIL PRICES 500,000........................$375 750,000........................$562 1,200,000........................$720 1,600,000.................. ...$960 3,000,000......................$1,500 3,000,000+ ...................PLEASE CALL FOR A QUOTE Resellers welcome. We accept Visa, MasterCard and check by FAX. DON'T WAIT! LET TECH DATA TECHNOLOGIES BE YOUR PARTNER!! Under Bill s.1618 TITLE III passed by the 105th U.S. Congress this letter is not considered "spam" as long as we include: 1) contact information and, 2) the way to be removed from future mailings (see below).To Remove Yourself From This List: reply to this email with the email address that you would like removed and the word REMOVE in the subject heading. From owner-ietf-imap-voice Mon Dec 25 00:05:32 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id AAA25915 for ietf-imap-voice-bks; Mon, 25 Dec 2000 00:05:32 -0800 (PST) Received: from sem_mail.smkb.ac.il (skbb3.skb2.macam.ac.il [192.115.171.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA25885; Mon, 25 Dec 2000 00:05:29 -0800 (PST) From: hj4hj6@yahoo.com Received: from SvTSkm01R (1Cust34.tnt21.lax3.da.uu.net [63.28.123.34]) by sem_mail.smkb.ac.il with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id Y4M7R6BY; Thu, 21 Dec 2000 23:32:20 +0200 DATE: 21 Dec 00 1:39:21 PM Message-ID: <3L1Z7626c2BB96> SUBJECT: Improve your stepfamily life Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Does your stepfamily life resemble a soap opera more than it does the Brady Bunch? The Stepfamily Association of America invites you to participate in THE NATIONAL CONFERENCE FOR STEPFAMILIES, Feb. 23-24, 2001, at the New Orleans Marriott Hotel. This is an opportunity, designed by knowledgeable professionals, in stepfamilies themselves, to help you: * Make your remarriage a success * Create bonds with your stepchildren * Help your children adjust emotionally * Manage money matters unique to your family * Get more help from legal, financial, psychological advisors * Overcome stepfather and stepmother stereotypes * Elicit cooperation from your children's schools * Bring more harmony into family life Complete conference details at http://www.edupr.com REGISTER ONLINE! Attend, and also enjoy Mardi Gras week in New Orleans! Special discounts for couples, students, groups. HOTEL IS BOOKING UP FAST. ACT NOW BEFORE ROOM BLOCK AND AIRLINE SEATS FILL Special rates for conference attendees. Visit http://www.edupr.com for discounts. Childcare available through a bonded local service. Up to 17 professional development credits available if you are an educator, clinician, financial planner, social worker. Questions? Email stepfamilyconf@mail.com If you would like to be removed, please email us back with the word "Remove" in the subject line. We apologize for any inconvenience. From owner-ietf-imap-voice Tue Jan 16 18:57:32 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id SAA10072 for ietf-imap-voice-bks; Tue, 16 Jan 2001 18:57:32 -0800 (PST) Received: from webserver.onlineevents.com.au ([203.111.80.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA10064; Tue, 16 Jan 2001 18:57:25 -0800 (PST) From: bk12bk27@yahoo.com Received: from max1-34.losangeles.corecomm.net by webserver.onlineevents.com.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1459.44) id C0CGL6NT; Wed, 17 Jan 2001 14:54:31 +1100 DATE: 16 Jan 01 6:44:42 PM Message-ID: SUBJECT: RE; THANK YOU Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear Friend and Partner, Think of all the things you could do if you had more free time and money wasn't an object What kind of car would you be driving? Where would you live? Where would you go on vacation? Now, for a limited time, 300+ money making and saving secrets can be yours for less than $10.00. Click here http://www.300moneysecrets.com/ and ORDER NOW!!!!!!!!!!!!!! Get information now, that could make you millions!!!! ** REMOVE ** REMOVE ** REMOVE ** REMOVE ** REMOVE ** To be removed from our mailing list, please email sandywho1212@yahoo.com All REMOVE requests AUTOMATICALLY honored upon receipt. PLEASE understand that any effort to disrupt, close or block this REMOVE account can only result in difficulties for others wanting to be removed from our mailing list as it will be impossible to take anyone off the list if the remove instruction can not be received. From owner-ietf-imap-voice Wed Mar 21 12:19:49 2001 Received: by above.proper.com (8.9.3/8.9.3) id MAA26727 for ietf-imap-voice-bks; Wed, 21 Mar 2001 12:19:49 -0800 (PST) Received: from nss.esys.ca (nss.esys.ca [198.161.92.34]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA26723; Wed, 21 Mar 2001 12:19:48 -0800 (PST) Received: (from uucp@localhost) by nss.esys.ca (8.11.0/8.11.1) with UUCP id f2LKIxU91614; Wed, 21 Mar 2001 13:18:59