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 -0700 (MST) (envelope-from lyndon@gollum.esys.ca) Received: from localhost (localhost [127.0.0.1]) by gollum.esys.ca (8.11.3/8.11.3) with ESMTP id f2LKIiV10799; Wed, 21 Mar 2001 13:18:44 -0700 (MST) (envelope-from lyndon@gollum.esys.ca) Message-Id: <200103212018.f2LKIiV10799@gollum.esys.ca> From: Lyndon Nerenberg To: vpim@lists.neystadt.org, ietf-imapext@imc.org cc: ietf-imap-voice@imc.org Subject: IMAP CHANNEL discussion list X-URL: http://www.aciworldwide.com/ Organization: ACI Worldwide MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10796.985205924.1@localhost> Date: Wed, 21 Mar 2001 13:18:44 -0700 Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At the VPIM lunch BOF today we decided that, since both the IMAP and the VPIM communities have interest in this extension, we will use the ietf-imap-voice@imc.org mailing list for further discussions. This eliminates the need for VPIM folks to subscribe to the IMAP lists, and vice versa. To subscribe: echo subscribe | mail ietf-imap-voice-request@imc.org --lyndon From owner-ietf-imap-voice Thu May 10 09:29:37 2001 Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id JAA12881 for ietf-imap-voice-bks; Thu, 10 May 2001 09:29:37 -0700 (PDT) Received: from pavilion (a24b31n80client230.hawaii.rr.com [24.31.80.230]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA12856 for ; Thu, 10 May 2001 09:29:32 -0700 (PDT) Message-ID: <1647620015410162122340@pavilion> X-EM-Version: 5, 0, 0, 19 X-EM-Registration: #01B0530810E603002D00 X-Priority: 3 X-MSMail-Priority: Normal From: "Mitchell" To: ietf-imap-voice@imc.org Subject: Business/Employment Opportunity Date: Thu, 10 May 2001 06:21:22 -1000 MIME-Version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id JAA12862 Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear Friend: "Making over half million dollars every 4 to 5 months from your home for an investment of only $25 U.S. Dollars expense one time" THANKS TO THE COMPUTER AGE AND THE INTERNET! =============================================== BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR !! Before you say "Bull" , please read the following. This is the letter you have been hearing about on the news lately. Due to the popularity of this letter on the internet, a national weekly news program recently devoted an entire show to the investigation of this program described below , to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are "absolutely no laws prohibiting the participation in the program and if people can follow the simple instructions, they are bound to make some mega bucks with only $25 out of pocket cost". DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING BETTER THAN EVER. This is what one had to say: "Thanks to this profitable opportunity. I was approached many times before but each time I passed on it. I am so glad I finally joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received total $ 610,470.00 in 21 weeks, with money still coming in". Pam Hedland, Fort Lee, New Jersey. ------------------------------------------------------------------------- Here is another testimonial: "This program has been around for a long time but I never believed in it. But one day when I received this again in the mail I decided to gamble my $25 on it. I followed thesimple instructions and walaa ..... 3 weeks later the money started to come in. First month I only made $240.00 but the next 2 months after that I made a total of $290,000.00. So far, in the past 8 months by re-entering the program,I have made over $710,000.00 and I am playing it again. The key to success in this program is to follow the simple steps and NOT change anything ." More testimonials later but first, ****** PRINT THIS NOW FOR YOUR FUTURE REFERENCE ******* $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least $500,000 every 4 to 5 months easily and comfortably, please read the following...THEN READ IT AGAIN and AGAIN !!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL DREAMS WILL COME TRUE, GUARANTEED! INSTRUCTIONS: **** Order all 5 reports shown on the list below. **** For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORT YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose name appears ON THAT LIST next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail problems. **** When you place your order, make sure you order each of the 5 reports. You will need all 5 reports so that you can save them on your computer and resell them. YOUR TOTAL COST $5 X 5 = $25.00. **** Within a few days you will receive, via e-mail, each of the 5 reports from these 5 different individuals. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. Also make a floppy of these reports and keep it on your desk in case something happen to your computer. ****.IMPORTANT - DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than what is instructed below in steps 1 through6 or you will loose out on majority of your profits. Once you understand the way this works, you will also see how it does not work if you change it. Remember, this method has been tested, and if you alter, it will NOT work!!! People have tried to put their friends/relatives names on all five thinking they could get all the money. But it does not work this way. Believe us, we all have tried to be greedy and then nothing happened. So Do Not try to change anything other than what is instructed. Because if you do, it will not work for you. Remember, honesty reaps the reward!!! 1.. After you have ordered all 5 reports, take this advertisement and REMOVE the name & address of the person in REPORT # 5. This person has made it through the cycle and is no doubt counting their fortune. 2.... Move the name & address in REPORT # 4 down TO REPORT # 5. 3.... Move the name & address in REPORT # 3 down TO REPORT # 4. 4.... Move the name & address in REPORT # 2 down TO REPORT # 3. 5.... Move the name & address in REPORT # 1 down TO REPORT # 2 6.... Insert YOUR name & address in the REPORT # 1 Position. PLEASE MAKE SURE you copy every name & address ACCURATELY ! ========================================================= Take this entire letter, with the modified list of names, and save it on your computer. DO NOT MAKE ANY OTHER CHANGES. Save this on a disk as well just in case if you loose any data. To assist you with marketing your business on the internet, the 5 reports you purchase will provide you with invaluable marketing information which includes how to send bulk e-mails legally, where to find thousands of free classified ads and much more. There are 2 Primary methods to get this venture going: METHOD # 1 : BY SENDING BULK E-MAIL LEGALLY ============================================ let's say that you decide to start small, just to see how it goes, and we will assume You and those involved send out only 5,000 e-mails each. Let's also assume that the mailing receive only a0.2% response (the response could be much better but lets just say it is only 0.2% . Also many people will send out hundreds of thousands e-mails instead of only 5,000 each). Continuing with this example, you send out only 5,000 e-mails. With a 0.2% response, that is only 10 orders for report # 1. Those 10 people responded by sending out 5,000 e-mail each for a total of 50,000. Out of those 50,000 e-mails only 0.2% responded with orders. That's = 100 people responded and ordered Report # 2. Those 100 people mail out 5,000 e-mails each for a total of 500,000 e-mails. The 0.2% response to that is 1000 orders for Report # 3. Those 1000 people send out 5,000 e-mails each for a total of 5 million e-mails sent out. The 0.2% response to that is 10,000 orders for Report # 4. Those 10,000 people send out 5,000 e-mails each for a total of 50,000,000 (50 million) e-mails. The 0.2% response to that is 100,000 orders for Report # 5. THAT'S 100,000 ORDERS TIMES $5 EACH = $500,000.00 (half million). Your total income in this example is: 1..... $50 + 2..... $500 + 3..... $5,000 + 4..... $50,000 + 5..... $500,000 ......... Grand Total = $555,550.00 NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE OUT THE WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU CALCULATE IT, YOU WILL STILL MAKE A LOT OF MONEY ! ------------------------------------------------------------------------------ REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING OUT OF 5,000 YOU MAILED TO. Dare to think for a moment what would happen if everyone, or half or even one 4th of those people mailed 100,000 e-mails each or more? There are over 250 million people on the internet worldwide and counting. Believe me, many people will do just that, and more! METHOD # 2 : BY PLACING FREE ADS ON THE INTERNET =================================================== Advertising on the net is very very inexpensive and there are hundreds of FREE places to advertise. Placing a lot of free adson the internet will easily get a larger response. We strongly suggest you start with Method # 1 and add METHOD # 2 as you go along. For every $5 you receive, all you must do is e-mail them the Report they ordered. That's it . Always provide same day service on all orders. This will guarantee that the e-mail they send out, with your name and address on it, will be prompt because they can not advertise until they receive the report. _____________________ AVAILABLE REPORTS_____________________ ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes: Always send $5 cash (U.S. CURRENCY) for each Report. Checks NOT accepted. Make sure the cash is concealed by wrapping it in at least 2 sheets of paper. On one of those sheets of paper, Write the NUMBER & the NAME of the Report you are ordering, YOUR E-MAIL ADDRESS and your name and postal address. PLACE YOUR ORDER FOR THESE REPORTS NOW : ============================================== REPORT #1, "The Insider's Guide to Sending Bulk E-mail on the Internet" ORDER REPORT #1 FROM: G. Mitchell P.O. Box 25884 Honolulu, Hawaii 96825-0884 don't forget to provide a permanent e-mail address in clear writing (better typed) to receive the reports. We had problems in delivery e-mails before!!! ============================================== REPORT #2 "The Insider's Guide to Advertising for Free on the Internet" ORDER REPORT #2 FROM: Vijay Paul C-291, Second Floor Defence Colony New Delhi - 110024 INDIA ============================================== REPORT #3 "The Secrets to Multilevel Marketing on the Internet" ORDER REPORT #3 FROM: JD P.O.Box 1114 Des Plaines, IL 60017 USA ============================================== REPORT #4 "How to become a Millionaire utilizing the Power of Multilevel Marketing and the Internet" ORDER REPORT #4 FROM: J Santi 833 Walter Ave Des Plaines, IL 60016 USA ============================================== REPORT #5 "How to SEND 1,000,000 e-mails for FREE" ORDER REPORT #5 FROM: Elaine Rix 138 Dundas Street, West, #243 Toronto, Ontario Canada M5G 1C3 ============================================== There are currently more than 250,000,000 people online worldwide! $$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$ Follow these guidelines to guarantee your success: If you do not receive at least 10 orders for Report #1 within 2 weeks, continue sending e-mails until you do. After you have received 10 orders, 2 to 3 weeks after that you should receive 100 orders or more for REPORT # 2. If you did not, continue advertising or sending e-mails until you do. Once you have received 100 or more orders for Report # 2, YOU CAN RELAX, because the system is already working for you , and the cash will continue to roll in ! THIS IS IMPORTANT TO REMEMBER : Every time your name is moved down on the list, you are placed in front of a different report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. IF YOU WANT TO GENERATE MORE INCOME SEND ANOTHER BATCH OF E-MAILS AND START THE WHOLE PROCESS AGAIN. There is NO LIMIT to the income you can generate from this business !!! ____________________________________________________ FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS PROGRAM: You have just received information that can give you financial freedom for the rest of your life, with NO RISK and JUST A LITTLE BIT OF EFFORT. You can make more money in the next few weeks and months than you have ever imagined. Follow the program EXACTLY AS INSTRUCTED. Do Not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report after you have put your name and address in Report #1 and moved others to #2...........# 5 as instructed above. One of the people you send this to may send out 100,000 or more e-mails and your name will be on everyone of them. Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU NOW ! ************** MORE TESTIMONIALS **************** "My name is Mitchell. My wife , Jody and I live in Chicago. I am an accountant with a major U.S. Corporation and I make pretty good money. When I received this program I grumbled to Jody about receiving ''junk mail''. I made fun of the whole thing, spouting my knowledge of the population and percentages involved. I ''knew'' it wouldn't work. Jody totally ignored my supposed intelligence and few days later she jumped in with both feet. I made merciless fun of her, and was ready to lay the old ''I told you so'' on her when the thing didn'twork. Well, the laugh was on me! Within 3 weeks she had received 50 responses. Within the next 45 days she had received a total of $ 147,200.00 all cash! I was shocked. I have joined Jody in her ''hobby''." Mitchell Wolf, Chicago, Illinois ------------------------------------------------------------ "Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back. I was surprised when I found my medium size post office box crammed with orders. I made $319,210.00 in the first 12 weeks. The nice thing about this deal is that it does not matter where people live. There simply isn't a better investment with a faster return and so big." Dan Sondstrom, Alberta, Canada ----------------------------------------------------------- "I had received this program before. I deleted it, but later I wondered if I should have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed again by someone else.........11 months passed then it luckily came again...... I did not delete this one! I made more than $490,000 on my first try and all the money came within 22 weeks". Susan De Suza, New York, N.Y. ---------------------------------------------------- "It really is a great opportunity to make relatively easy money with little cost to you. I followed the simple instructions carefully and within 10 days the money started to come in. My first month I made $ 20,560.00 and by the end of third month my total cash count was $ 362,840.00. Life is beautiful, Thanx to internet". Fred Dellaca, Westport, New Zealand ------------------------------------------------------------ ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL FREEDOM ! ======================================================= If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection, Washington, D.C. Under Bill s.1618 TITLE III passed by the 105th US Congress this letter cannot be considered spam as long as the sender includes contact information and a method of removal. This is one time e-mail transmission. No request for removal is necessary. ------------------------------------------------------------ This message is sent in compliance of the new email Bill HR 1910. Under Bill HR 1910 passed by the 106th US Congress on May 24, 1999, this message cannot be considered Spam as long as we include the way to be removed. Per Section HR 1910, Please type "REMOVE" in the subject line and reply to this email. All removal requests are handled personally an immediately once received. From owner-ietf-imap-voice Tue May 15 14:23:19 2001 Received: by above.proper.com (8.9.3/8.9.3) id OAA16612 for ietf-imap-voice-bks; Tue, 15 May 2001 14:23:19 -0700 (PDT) Received: from commserver.iperia.com ([63.84.167.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA16601 for ; Tue, 15 May 2001 14:23:12 -0700 (PDT) Received: by commserver.iperia.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 May 2001 17:22:39 -0400 Message-ID: <5143F854B82ED211B05E00104B235F649E23CB@commserver.iperia.com> From: Steve Gardell To: "'ietf-imap-voice@imc.org'" Subject: draft-nerenberg-imap-channel-00.txt Date: Tue, 15 May 2001 17:22:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I followed the link that Lyndon posted to ietf-imapext mailing list to this list for discussions of streaming. A quick (maybe too quick) scan of the archive didn't turn up any discussion of this draft. So hopefully I am not treading on a well-beaten path. I believe that the Channel Transport mechanism described in the draft is good step towards integrating IMAP message stores with other next generation elements such as SIP and VoiceXML that also have a heavy "URI" focus. There appears to be particularly good synergy with the VoiceXML "document-centric" model. It seems that the capability identification would ideally include additional information to specify the actually encoding of voice. I agree with some other discussion that I have seen on a couple of the BINARY threads that issues of streaming and binary data access are best kept fairly separate. Steven Gardell Principal Engineer, Iperia Inc. 781-993-3544 From owner-ietf-imap-voice Tue May 15 15:58:42 2001 Received: by above.proper.com (8.9.3/8.9.3) id PAA25434 for ietf-imap-voice-bks; Tue, 15 May 2001 15:58:42 -0700 (PDT) Received: from gollum.esys.ca (dhcp198-52.esys.ca [198.161.92.52]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA25422 for ; Tue, 15 May 2001 15:58:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gollum.esys.ca (8.12.0.Beta5/8.11.3) with ESMTP id f4FMwNho009425; Tue, 15 May 2001 16:58:24 -0600 (MDT) (envelope-from lyndon@gollum.esys.ca) Message-Id: <200105152258.f4FMwNho009425@gollum.esys.ca> From: Lyndon Nerenberg Organization: ACI Worldwide X-URL: http://www.aciworldwide.com/ To: Steve Gardell cc: "'ietf-imap-voice@imc.org'" Subject: Re: draft-nerenberg-imap-channel-00.txt In-Reply-To: Message from Steve Gardell of "Tue, 15 May 2001 17:22:38 EDT." <5143F854B82ED211B05E00104B235F649E23CB@commserver.iperia.com> Date: Tue, 15 May 2001 16:58:23 -0600 Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Steve" == Steve Gardell writes: Steve> I followed the link that Lyndon posted to ietf-imapext Steve> mailing list to this list for discussions of streaming. A Steve> quick (maybe too quick) scan of the archive didn't turn up Steve> any discussion of this draft. So hopefully I am not Steve> treading on a well-beaten path. Actually, there hasn't been any discussion to date, and I was just about to ping this list to see if anyone had any comments. At the last IETF we had a brief discussion about the draft, with the initial outstanding issue being the semantics of the URIs. The VPIM folks were going to stew that over and come back with their thoughts. Glenn, have you heard any further discussion on this? London approaches, and I would like to get another rev of the draft out that better describes the URI semantics. We should also start thinking about whether we want to meet in London to talk about moving this forward. I haven't heard yet if the IMAP Extensions group is meeting, so I think we can just plan for a pub-BOF. (I can't think of any reason we would need to consume IMAPext WG time, anyway.) Can we have a show of hands from those who want to meet and discuss in the pub during the London IETF? --lyndon From owner-ietf-imap-voice Wed May 16 04:42:13 2001 Received: by above.proper.com (8.9.3/8.9.3) id EAA17691 for ietf-imap-voice-bks; Wed, 16 May 2001 04:42:13 -0700 (PDT) Received: from flyingfox.snowshore.com (flyingfox.snowshore.com [216.57.133.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA17680 for ; Wed, 16 May 2001 04:42:07 -0700 (PDT) Received: from eburger (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id f4GBgEb02320 for ; Wed, 16 May 2001 07:42:14 -0400 (EDT) Message-Id: <200105161142.f4GBgEb02320@flyingfox.snowshore.com> From: Eric Burger To: ietf-imap-voice@imc.org Subject: London CHANNEL Pub BOF (was RE: draft-nerenberg-imap-channel-00.txt) Date: Wed, 16 May 2001 07:41:00 GMT X-Mailer: CorporateTime Outlook Connector 3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id EAA17683 Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I raise my beer glass for a pub BOF! -----Original Message----- [snip] Can we have a show of hands from those who want to meet and discuss in the pub during the London IETF? --lyndon From owner-ietf-imap-voice Mon Aug 6 07:24:40 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f76EOeZ04199 for ietf-imap-voice-bks; Mon, 6 Aug 2001 07:24:40 -0700 (PDT) Received: from atg.aciworldwide.com (atg.aciworldwide.com [207.167.22.33]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f76EOdN04195 for ; Mon, 6 Aug 2001 07:24:39 -0700 (PDT) Received: from atg.aciworldwide.com (atg.aciworldwide.com [207.167.22.33]) by atg.aciworldwide.com (8.12.0.Beta14/8.12.0.Beta14) with ESMTP id f76EOQpI054180 for ; Mon, 6 Aug 2001 08:24:26 -0600 (MDT) Date: Mon, 6 Aug 2001 08:24:26 -0600 (MDT) From: Lyndon Nerenberg To: Subject: CHANNEL Bar BOF? Message-ID: <20010806082105.U53536-100000@atg.aciworldwide.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: So folks, do we have enough interest to hold a bar BOF? I don't have anything specific to discuss (read: I haven't had time to do any further work on the draft), however I wouldn't mind spending a bit of time exploring URL semantics a bit more. This was also the main outstanding topic from our last get together in Minneapolis. --lyndon From owner-ietf-imap-voice Mon Aug 6 12:22:39 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f76JMd116446 for ietf-imap-voice-bks; Mon, 6 Aug 2001 12:22:39 -0700 (PDT) Received: from flyingfox.snowshore.com (flyingfox.snowshore.com [216.57.133.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f76JMcN16442 for ; Mon, 6 Aug 2001 12:22:38 -0700 (PDT) Received: from eburger (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id f76JMZQ11845; Mon, 6 Aug 2001 15:22:36 -0400 (EDT) Reply-To: From: "Eric Burger" To: "Lyndon Nerenberg" , Subject: RE: CHANNEL Bar BOF? Date: Mon, 6 Aug 2001 15:22:35 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <20010806082105.U53536-100000@atg.aciworldwide.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I know I've been bad and I haven't written the I-D I promised in Minneapolis. I can discuss what I was planning to write up, but other than that, I don't have anything, either. -----Original Message----- From: owner-ietf-imap-voice@mail.imc.org [mailto:owner-ietf-imap-voice@mail.imc.org]On Behalf Of Lyndon Nerenberg Sent: Monday, August 06, 2001 10:24 AM To: ietf-imap-voice@imc.org Subject: CHANNEL Bar BOF? So folks, do we have enough interest to hold a bar BOF? I don't have anything specific to discuss (read: I haven't had time to do any further work on the draft), however I wouldn't mind spending a bit of time exploring URL semantics a bit more. This was also the main outstanding topic from our last get together in Minneapolis. --lyndon From owner-ietf-imap-voice Mon Aug 6 14:14:41 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f76LEfi18280 for ietf-imap-voice-bks; Mon, 6 Aug 2001 14:14:41 -0700 (PDT) Received: from zcars0m9.ca.nortel.com ([47.129.242.157]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f76LEeN18275 for ; Mon, 6 Aug 2001 14:14:40 -0700 (PDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f76LE3910911 for ; Mon, 6 Aug 2001 17:14:03 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Mon, 6 Aug 2001 17:13:58 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Aug 2001 17:13:59 -0400 Message-ID: From: "Glenn Parsons" To: Lyndon Nerenberg , ietf-imap-voice , "'eburger'" Subject: RE: CHANNEL Bar BOF? Date: Mon, 6 Aug 2001 17:13:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11EBC.B44C2AA0" 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_01C11EBC.B44C2AA0 Content-Type: text/plain So perhaps we should have a chat then? When is a good time for you? After lunch tomorrow? Glenn. > ---------- > From: Eric Burger > Reply To: eburger > Sent: Monday, August 6, 2001 3:22 pm > To: Lyndon Nerenberg; ietf-imap-voice > Subject: RE: CHANNEL Bar BOF? > > > I know I've been bad and I haven't written the I-D I promised in > Minneapolis. I can discuss what I was planning to write up, but other > than > that, I don't have anything, either. > > -----Original Message----- > From: owner-ietf-imap-voice@mail.imc.org > [mailto:owner-ietf-imap-voice@mail.imc.org]On Behalf Of Lyndon Nerenberg > Sent: Monday, August 06, 2001 10:24 AM > To: ietf-imap-voice@imc.org > Subject: CHANNEL Bar BOF? > > > > So folks, do we have enough interest to hold a bar BOF? I don't have > anything specific to discuss (read: I haven't had time to do any further > work on the draft), however I wouldn't mind spending a bit of time > exploring URL semantics a bit more. This was also the main outstanding > topic from our last get together in Minneapolis. > > --lyndon > > > ------_=_NextPart_001_01C11EBC.B44C2AA0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: CHANNEL Bar BOF?

So perhaps we should have a = chat then?  When is a good time for you?  After lunch = tomorrow?

Glenn.

    ----------
    From:   Eric Burger
    Reply To: =       eburger
    Sent:   Monday, August 6, 2001 3:22 pm
    To:     = Lyndon Nerenberg; ietf-imap-voice
    Subject: =        RE: = CHANNEL Bar BOF?


    I know I've been bad and I haven't = written the I-D I promised in
    Minneapolis.  I can discuss = what I was planning to write up, but other than
    that, I don't have anything, = either.

    -----Original Message-----
    From: = owner-ietf-imap-voice@mail.imc.org
    [mailto:owner-ietf-ima= p-voice@mail.imc.org]On = Behalf Of Lyndon Nerenberg
    Sent: Monday, August 06, 2001 10:24 = AM
    To: ietf-imap-voice@imc.org
    Subject: CHANNEL Bar BOF?



    So folks, do we have enough interest = to hold a bar BOF? I don't have
    anything specific to discuss (read: = I haven't had time to do any further
    work on the draft), however I = wouldn't mind spending a bit of time
    exploring URL semantics a bit more. = This was also the main outstanding
    topic from our last get together in = Minneapolis.

    --lyndon



------_=_NextPart_001_01C11EBC.B44C2AA0-- From owner-ietf-imap-voice Tue Aug 7 03:05:56 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f77A5uD24625 for ietf-imap-voice-bks; Tue, 7 Aug 2001 03:05:56 -0700 (PDT) Received: from zcars0m9.ca.nortel.com ([47.129.242.157]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77A5tN24621 for ; Tue, 7 Aug 2001 03:05:55 -0700 (PDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f77A5G900685 for ; Tue, 7 Aug 2001 06:05:18 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Tue, 7 Aug 2001 06:05:26 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Aug 2001 06:05:27 -0400 Message-ID: From: "Glenn Parsons" To: Lyndon Nerenberg , ietf-imap-voice , eburger Subject: RE: CHANNEL Bar BOF? Date: Tue, 7 Aug 2001 06:05:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11F28.75D8F430" 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_01C11F28.75D8F430 Content-Type: text/plain So then perhaps we should discuss? After lunch on Wednesday? Glenn. > ---------- > From: Eric Burger > Reply To: eburger > Sent: Monday, August 6, 2001 3:22 pm > To: Lyndon Nerenberg; ietf-imap-voice > Subject: RE: CHANNEL Bar BOF? > > > I know I've been bad and I haven't written the I-D I promised in > Minneapolis. I can discuss what I was planning to write up, but other > than > that, I don't have anything, either. > > -----Original Message----- > From: owner-ietf-imap-voice@mail.imc.org > [mailto:owner-ietf-imap-voice@mail.imc.org]On Behalf Of Lyndon Nerenberg > Sent: Monday, August 06, 2001 10:24 AM > To: ietf-imap-voice@imc.org > Subject: CHANNEL Bar BOF? > > > > So folks, do we have enough interest to hold a bar BOF? I don't have > anything specific to discuss (read: I haven't had time to do any further > work on the draft), however I wouldn't mind spending a bit of time > exploring URL semantics a bit more. This was also the main outstanding > topic from our last get together in Minneapolis. > > --lyndon > > > ------_=_NextPart_001_01C11F28.75D8F430 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: CHANNEL Bar BOF?

So then perhaps we should = discuss?  After lunch on Wednesday?

Glenn.

    ----------
    From:   Eric Burger
    Reply To: =       eburger
    Sent:   Monday, August 6, 2001 3:22 pm
    To:     = Lyndon Nerenberg; ietf-imap-voice
    Subject: =        RE: = CHANNEL Bar BOF?


    I know I've been bad and I haven't = written the I-D I promised in
    Minneapolis.  I can discuss = what I was planning to write up, but other than
    that, I don't have anything, = either.

    -----Original Message-----
    From: = owner-ietf-imap-voice@mail.imc.org
    [mailto:owner-ietf-ima= p-voice@mail.imc.org]On = Behalf Of Lyndon Nerenberg
    Sent: Monday, August 06, 2001 10:24 = AM
    To: ietf-imap-voice@imc.org
    Subject: CHANNEL Bar BOF?



    So folks, do we have enough interest = to hold a bar BOF? I don't have
    anything specific to discuss (read: = I haven't had time to do any further
    work on the draft), however I = wouldn't mind spending a bit of time
    exploring URL semantics a bit more. = This was also the main outstanding
    topic from our last get together in = Minneapolis.

    --lyndon



------_=_NextPart_001_01C11F28.75D8F430-- From owner-ietf-imap-voice Tue Aug 7 03:20:08 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f77AK8h26189 for ietf-imap-voice-bks; Tue, 7 Aug 2001 03:20:08 -0700 (PDT) Received: from flyingfox.snowshore.com (flyingfox.snowshore.com [216.57.133.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77AK7N26181 for ; Tue, 7 Aug 2001 03:20:07 -0700 (PDT) Received: from eburger (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id f77AK6Q16547 for ; Tue, 7 Aug 2001 06:20:06 -0400 (EDT) Reply-To: From: "Eric Burger" To: "ietf-imap-voice" Subject: RE: CHANNEL Bar BOF? Date: Tue, 7 Aug 2001 06:20:05 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sounds OK. I've got a WG meeting at 1pm on Wednesday. -----Original Message----- From: Glenn Parsons [mailto:gparsons@nortelnetworks.com] Sent: Tuesday, August 07, 2001 6:05 AM To: Lyndon Nerenberg; ietf-imap-voice; eburger Subject: RE: CHANNEL Bar BOF? So then perhaps we should discuss? After lunch on Wednesday? Glenn. ---------- From: Eric Burger Reply To: eburger Sent: Monday, August 6, 2001 3:22 pm To: Lyndon Nerenberg; ietf-imap-voice Subject: RE: CHANNEL Bar BOF? I know I've been bad and I haven't written the I-D I promised in Minneapolis. I can discuss what I was planning to write up, but other than that, I don't have anything, either. -----Original Message----- From: owner-ietf-imap-voice@mail.imc.org [mailto:owner-ietf-imap-voice@mail.imc.org]On Behalf Of Lyndon Nerenberg Sent: Monday, August 06, 2001 10:24 AM To: ietf-imap-voice@imc.org Subject: CHANNEL Bar BOF? So folks, do we have enough interest to hold a bar BOF? I don't have anything specific to discuss (read: I haven't had time to do any further work on the draft), however I wouldn't mind spending a bit of time exploring URL semantics a bit more. This was also the main outstanding topic from our last get together in Minneapolis. --lyndon From owner-ietf-imap-voice Tue Aug 7 04:31:40 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f77BVeh00305 for ietf-imap-voice-bks; Tue, 7 Aug 2001 04:31:40 -0700 (PDT) Received: from relay2.bt.net (relay2.bt.net [194.72.6.62]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77BVcN00301 for ; Tue, 7 Aug 2001 04:31:38 -0700 (PDT) Received: from [217.33.138.245] (helo=smtp.bt.net) by relay2.bt.net with smtp (Exim 3.15 #1) id 15U554-0007Jb-00; Tue, 07 Aug 2001 12:31:27 +0100 Date: Tue, 7 Aug 2001 11:38 -0000 From: To: "Glenn Parsons" , "ietf-imap-voice" , "eburger" Subject: CHANNEL BOF: Thursday 1745 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_unique-boundary-1" Content-Transfer-Encoding: 7bit Message-Id: Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ------=_unique-boundary-1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT >So then perhaps we should discuss? After lunch on Wednesday? Wednesday will conflict for me. Let's do it Thursday. Meet at the message board at 1745 and we'll search out a pub and dinner. --lyndon ------=_unique-boundary-1-- From owner-ietf-imap-voice Tue Aug 7 07:18:26 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f77EIQA03675 for ietf-imap-voice-bks; Tue, 7 Aug 2001 07:18:26 -0700 (PDT) Received: from zcars0m9.ca.nortel.com ([47.129.242.157]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77EHnN03662 for ; Tue, 7 Aug 2001 07:17:53 -0700 (PDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f77EHM911061 for ; Tue, 7 Aug 2001 10:17:22 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 7 Aug 2001 10:17:24 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Aug 2001 10:17:27 -0400 Message-ID: From: "Glenn Parsons" To: ietf-imap-voice Cc: eburger , "'lyndon'" Subject: RE: CHANNEL BOF: Thursday 1745 Date: Tue, 7 Aug 2001 10:17:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11F4B.AC3642D0" 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_01C11F4B.AC3642D0 Content-Type: text/plain We were planning a general discussion VPIM dinner for Thursday. Would you mind if discussed Channel as part of that? There is an Apps chairs meeting until 1800 (I think) on Thursday. Could we delay until then? Cheers, Glenn. > ---------- > From: lyndon > Sent: Tuesday, August 7, 2001 7:38 am > To: Parsons, Glenn [CAR:6L81:EXCH]; ietf-imap-voice; eburger > Subject: CHANNEL BOF: Thursday 1745 > > > >So then perhaps we should discuss? After lunch on Wednesday? > > Wednesday will conflict for me. Let's do it Thursday. Meet at the > message board at 1745 and we'll search out a pub and dinner. > > --lyndon > > ------_=_NextPart_001_01C11F4B.AC3642D0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: CHANNEL BOF: Thursday 1745

We were planning a general = discussion VPIM dinner for Thursday.  Would you mind if discussed = Channel as part of that?

There is an Apps chairs = meeting until 1800 (I think) on Thursday.  Could we delay until = then?

Cheers,
Glenn. 


    ----------
    From:   lyndon
    Sent:   Tuesday, August 7, 2001 7:38 am
    To:     = Parsons, Glenn [CAR:6L81:EXCH]; = ietf-imap-voice; eburger
    Subject: =        CHANNEL BOF: Thursday 1745


    >So then perhaps we should = discuss?  After lunch on Wednesday?

    Wednesday will conflict for me. Let's = do it Thursday. Meet at the
    message board at 1745 and we'll = search out a pub and dinner.

    --lyndon 


------_=_NextPart_001_01C11F4B.AC3642D0-- From owner-ietf-imap-voice Tue Aug 7 08:58:32 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f77FwWu03479 for ietf-imap-voice-bks; Tue, 7 Aug 2001 08:58:32 -0700 (PDT) Received: from relay1.bt.net (relay1.bt.net [194.72.6.100]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77FwVN03475 for ; Tue, 7 Aug 2001 08:58:31 -0700 (PDT) Received: from [217.33.138.245] (helo=smtp.bt.net) by relay1.bt.net with smtp (Exim 3.15 #1) id 15U995-0005tT-00; Tue, 07 Aug 2001 16:51:52 +0100 Date: Tue, 7 Aug 2001 15:58 -0000 From: To: "Glenn Parsons" , "ietf-imap-voice" Cc: "eburger" Subject: RE: CHANNEL BOF: Thursday 1815 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_unique-boundary-2" Content-Transfer-Encoding: 7bit Message-Id: Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ------=_unique-boundary-2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT >We were planning a general discussion VPIM dinner for Thursday. Would you >mind if discussed Channel as part of that? I don't have a problem with that, although depending on who shows up we might want to break out (later) to discuss some technical issues about the protocol. >There is an Apps chairs meeting until 1800 (I think) on Thursday. Could we >delay until then? Fine. 1815 at the message board. --lyndon ------=_unique-boundary-2-- From owner-ietf-imap-voice Tue Aug 7 09:15:38 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f77GFcA03926 for ietf-imap-voice-bks; Tue, 7 Aug 2001 09:15:38 -0700 (PDT) Received: from lotus2.lotus.com (lotus2.lotus.com [129.42.241.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77GFZN03922; Tue, 7 Aug 2001 09:15:35 -0700 (PDT) Received: from internet2.lotus.com (internet2 [172.16.131.236]) by lotus2.lotus.com (8.11.4/8.11.4) with ESMTP id f77FwI510449; Tue, 7 Aug 2001 12:03:08 -0400 (EDT) Received: from a3mail.lotus.com (a3mail.lotus.com [9.95.5.66]) by internet2.lotus.com (8.11.4/8.11.2) with ESMTP id f77FvMw27051; Tue, 7 Aug 2001 11:57:22 -0400 (EDT) To: Cc: "ietf-imap-voice" , owner-ietf-imap-voice@mail.imc.org Subject: RE: CHANNEL Bar BOF? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 From: "Stuart McRae/STA/Lotus" X-MIMETrack: S/MIME Sign by Notes Client on Stuart McRae/STA/Lotus(Release 5.0.6a |January 17, 2001) at 07/08/2001 15:09:30, Serialize by Notes Client on Stuart McRae/STA/Lotus(Release 5.0.6a |January 17, 2001) at 07/08/2001 15:09:30, Serialize complete at 07/08/2001 15:09:30, S/MIME Sign failed at 07/08/2001 15:09:30: The cryptographic key was not found, Serialize by Router on A3MAIL/CAM/H/Lotus(Release 5.0.8 |June 18, 2001) at 08/07/2001 11:57:22 AM, Serialize complete at 08/07/2001 11:57:22 AM Message-ID: Date: Tue, 7 Aug 2001 16:55:58 +0100 Content-Type: multipart/alternative; boundary="=_alternative 004DC5FF80256AA1_=" Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 004DC5FF80256AA1_= Content-Type: text/plain; charset="us-ascii" I'll be here on Weds. I also need to be finished by 1pm. Perhaps we could get a small group together to discuss it over lunch? Stuart "Eric Burger" Sent by: owner-ietf-imap-voice@mail.imc.org 07/08/01 11:20 Please respond to eburger To: "ietf-imap-voice" cc: (bcc: Stuart McRae/STA/Lotus) Subject: RE: CHANNEL Bar BOF? Sounds OK. I've got a WG meeting at 1pm on Wednesday. -----Original Message----- From: Glenn Parsons [mailto:gparsons@nortelnetworks.com] Sent: Tuesday, August 07, 2001 6:05 AM To: Lyndon Nerenberg; ietf-imap-voice; eburger Subject: RE: CHANNEL Bar BOF? So then perhaps we should discuss? After lunch on Wednesday? Glenn. ---------- From: Eric Burger Reply To: eburger Sent: Monday, August 6, 2001 3:22 pm To: Lyndon Nerenberg; ietf-imap-voice Subject: RE: CHANNEL Bar BOF? I know I've been bad and I haven't written the I-D I promised in Minneapolis. I can discuss what I was planning to write up, but other than that, I don't have anything, either. -----Original Message----- From: owner-ietf-imap-voice@mail.imc.org [mailto:owner-ietf-imap-voice@mail.imc.org]On Behalf Of Lyndon Nerenberg Sent: Monday, August 06, 2001 10:24 AM To: ietf-imap-voice@imc.org Subject: CHANNEL Bar BOF? So folks, do we have enough interest to hold a bar BOF? I don't have anything specific to discuss (read: I haven't had time to do any further work on the draft), however I wouldn't mind spending a bit of time exploring URL semantics a bit more. This was also the main outstanding topic from our last get together in Minneapolis. --lyndon --=_alternative 004DC5FF80256AA1_= Content-Type: text/html; charset="us-ascii"
I'll be here on Weds. I also need to be finished by 1pm. Perhaps we could get a small group together to discuss it over lunch?
Stuart



"Eric Burger" <eburger@snowshore.com>
Sent by: owner-ietf-imap-voice@mail.imc.org

07/08/01 11:20
Please respond to eburger

       
        To:        "ietf-imap-voice" <ietf-imap-voice@imc.org>
        cc:        (bcc: Stuart McRae/STA/Lotus)
        Subject:        RE: CHANNEL Bar BOF?




Sounds OK.  I've got a WG meeting at 1pm on Wednesday.

-----Original Message-----
From: Glenn Parsons [mailto:gparsons@nortelnetworks.com]
Sent: Tuesday, August 07, 2001 6:05 AM
To: Lyndon Nerenberg; ietf-imap-voice; eburger
Subject: RE: CHANNEL Bar BOF?


So then perhaps we should discuss?  After lunch on Wednesday?
Glenn.
----------
From:   Eric Burger
Reply To:       eburger
Sent:   Monday, August 6, 2001 3:22 pm
To:     Lyndon Nerenberg; ietf-imap-voice
Subject:        RE: CHANNEL Bar BOF?


I know I've been bad and I haven't written the I-D I promised in
Minneapolis.  I can discuss what I was planning to write up, but other than
that, I don't have anything, either.
-----Original Message-----
From: owner-ietf-imap-voice@mail.imc.org
[mailto:owner-ietf-imap-voice@mail.imc.org]On Behalf Of Lyndon Nerenberg
Sent: Monday, August 06, 2001 10:24 AM
To: ietf-imap-voice@imc.org
Subject: CHANNEL Bar BOF?



So folks, do we have enough interest to hold a bar BOF? I don't have
anything specific to discuss (read: I haven't had time to do any further
work on the draft), however I wouldn't mind spending a bit of time
exploring URL semantics a bit more. This was also the main outstanding
topic from our last get together in Minneapolis.
--lyndon

--=_alternative 004DC5FF80256AA1_=-- From owner-ietf-imap-voice Tue Aug 7 09:52:21 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f77GqLq04827 for ietf-imap-voice-bks; Tue, 7 Aug 2001 09:52:21 -0700 (PDT) Received: from flyingfox.snowshore.com (flyingfox.snowshore.com [216.57.133.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77GqKN04823 for ; Tue, 7 Aug 2001 09:52:20 -0700 (PDT) Received: from eburger (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id f77GqLQ21470; Tue, 7 Aug 2001 12:52:21 -0400 (EDT) Reply-To: From: "Eric Burger" To: "ietf-imap-voice" , "Vpim" Subject: RE: CHANNEL BOF: Thursday 1815 Date: Tue, 7 Aug 2001 12:52:20 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've got a conference call from 1800 - 1830. Can we either delay or just leave me a message at the message board? Thanks. -----Original Message----- From: lyndon@atg.aciworldwide.com [mailto:lyndon@atg.aciworldwide.com] Sent: Tuesday, August 07, 2001 11:58 AM To: Glenn Parsons; ietf-imap-voice Cc: eburger Subject: RE: CHANNEL BOF: Thursday 1815 >We were planning a general discussion VPIM dinner for Thursday. Would you >mind if discussed Channel as part of that? I don't have a problem with that, although depending on who shows up we might want to break out (later) to discuss some technical issues about the protocol. >There is an Apps chairs meeting until 1800 (I think) on Thursday. Could we >delay until then? Fine. 1815 at the message board. --lyndon From owner-ietf-imap-voice Thu Aug 9 07:37:13 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f79EbDN17756 for ietf-imap-voice-bks; Thu, 9 Aug 2001 07:37:13 -0700 (PDT) Received: from relay3.bt.net (relay3.bt.net [194.72.6.50]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79EbBN17751 for ; Thu, 9 Aug 2001 07:37:11 -0700 (PDT) Received: from [217.33.138.245] (helo=smtp.bt.net) by relay3.bt.net with smtp (Exim 3.22 #1) id 15Uqvl-0005Me-00 for ietf-imap-voice@imc.org; Thu, 09 Aug 2001 15:37:01 +0100 Date: Thu, 9 Aug 2001 14:37 -0000 From: To: Subject: CHANNEL BOF -- yet another schedule update MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_unique-boundary-1" Content-Transfer-Encoding: 7bit Message-Id: Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ------=_unique-boundary-1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Okay, the meeting scheduling is getting unwieldy. I will be in the east lobby bar at 1730. For those who can make it, we'll spend an hour or so discussing CHANNEL before the VPIM folks head out for dinner. --lyndon ------=_unique-boundary-1-- From owner-ietf-imap-voice Thu Nov 29 15:48:02 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fATNm2x28443 for ietf-imap-voice-bks; Thu, 29 Nov 2001 15:48:02 -0800 (PST) Received: from atg.aciworldwide.com (atg-gw.esys.ca [139.142.180.4] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id fATNlk828431; Thu, 29 Nov 2001 15:47:46 -0800 (PST) Received: from atg.aciworldwide.com (atg.aciworldwide.com [139.142.180.33]) by atg.aciworldwide.com (8.12.0/8.12.0) with ESMTP id fATNlm5I015507; Thu, 29 Nov 2001 16:47:48 -0700 (MST) Message-Id: <200111292347.fATNlm5I015507@atg.aciworldwide.com> To: ietf-imap-voice@imc.org, ietf-imapext@imc.org Subject: New Channel Draft Is Out X-URL: http://www.aciworldwide.com/ X-Notes-Item: Just say NO to Notes! Organization: ACI Worldwide - Advanced Technology Group Date: Thu, 29 Nov 2001 16:47:48 -0700 From: Lyndon Nerenberg Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: draft-nerenberg-imap-channel-01.txt is now in the I-D repositories. I've changed the syntax of the body part specifiers and added a grammar. --lyndon From owner-ietf-imap-voice Wed Mar 6 21:10:27 2002 Received: by above.proper.com (8.11.6/8.11.3) id g275ARh04545 for ietf-imap-voice-bks; Wed, 6 Mar 2002 21:10:27 -0800 (PST) Received: from atg.aciworldwide.com (atg.aciworldwide.com [139.142.180.4] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g275AP804541 for ; Wed, 6 Mar 2002 21:10:25 -0800 (PST) Received: from atg.aciworldwide.com (atg.aciworldwide.com [139.142.180.33]) by atg.aciworldwide.com (8.12.0/8.12.0) with ESMTP id g275ATsN032026 for ; Wed, 6 Mar 2002 22:10:29 -0700 (MST) Message-Id: <200203070510.g275ATsN032026@atg.aciworldwide.com> To: ietf-imap-voice@imc.org Subject: UID for IMAP Channel? X-URL: http://www.aciworldwide.com/ X-Notes-Item: Just say NO to Notes! Organization: ACI Worldwide - Advanced Technology Group X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Wed, 06 Mar 2002 22:10:29 -0700 From: Lyndon Nerenberg Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey has raised the issue of using UID with channel. I am agnostic on this, and would like to hear from the client folks about whether UID CHANNEL would be a useful addition to this extension. If there is an IMAP BOF this time around perhaps this can be discussed, and the results reported back to the list. --lyndon From owner-ietf-imap-voice Wed Mar 6 21:53:55 2002 Received: by above.proper.com (8.11.6/8.11.3) id g275rt105390 for ietf-imap-voice-bks; Wed, 6 Mar 2002 21:53:55 -0800 (PST) Received: from episteme-software.com (champdsl-25-66.mcleodusa.net [216.43.25.66]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g275rr805386 for ; Wed, 6 Mar 2002 21:53:53 -0800 (PST) Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.1) for ; Wed, 6 Mar 2002 23:53:51 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: X-Mailer: Eudora [Macintosh version 5.1fc3] Date: Wed, 6 Mar 2002 23:53:50 -0600 To: ietf-imap-voice@imc.org From: Pete Resnick Subject: Interesting (gross?) use of CHANNEL Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: OK, I may get flack for this, but I can think of a bunch of good reasons to do this: What do people think of using "mailto" in CHANNEL? That is, if I have a message in a mailbox, I can CHANNEL it using a mailto URL in order to effect the sending of the message. My thought is that the target of the mailto should only be the envelope recipient and should not change the contents of the message header in anyway. In my ideal picture, the server would take the message and prepend Resent-* fields using the destination and whatever other fields are specified in the URL. You would, of course, only be able to CHANNEL to mailto for an entire message or for a subpart which was itself of type message/rfc822. This seems to me an ideal way to implement the Resend command in many clients, and could even be used to send draft messages out for the first time. I'm guessing that I know some server vendors who would be willing to implement this and it would be a nice proof-of-concept of CHANNEL without having to get a bunch of much fancier clients up and running. Thoughts? Does this need a separate I-D? pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From owner-ietf-imap-voice Wed Mar 6 22:35:06 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g276Z6406253 for ietf-imap-voice-bks; Wed, 6 Mar 2002 22:35:06 -0800 (PST) Received: from atg.aciworldwide.com (atg.aciworldwide.com [139.142.180.4] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g276Z5806249 for ; Wed, 6 Mar 2002 22:35:05 -0800 (PST) Received: from atg.aciworldwide.com (atg.aciworldwide.com [139.142.180.33]) by atg.aciworldwide.com (8.12.0/8.12.0) with ESMTP id g276Z9sN032814; Wed, 6 Mar 2002 23:35:09 -0700 (MST) Message-Id: <200203070635.g276Z9sN032814@atg.aciworldwide.com> Organization: ACI Worldwide - Advanced Technology Group X-URL: http://www.aciworldwide.com/ X-Notes-Item: Just say NO to Notes! To: Pete Resnick cc: ietf-imap-voice@imc.org Subject: Re: Interesting (gross?) use of CHANNEL In-Reply-To: Message from Pete Resnick of "Wed, 06 Mar 2002 23:53:50 CST." Date: Wed, 06 Mar 2002 23:35:09 -0700 From: Lyndon Nerenberg Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > What do people think of using "mailto" in CHANNEL? That is, if I have > a message in a mailbox, I can CHANNEL it using a mailto URL in order > to effect the sending of the message. My thought is that the target > of the mailto should only be the envelope recipient and should not > change the contents of the message header in anyway. Urgh. If you mailto:, I would expect the server to simply BARF the request back to you. Unless, in some bizarre circumstance, it made sense to honour the request. The bottom line is that the server has to interpret the presented URI in whatever form makes sense to it. If the URI that's presented is absurd, the server gets to deal with it as such. > In my ideal > picture, the server would take the message and prepend Resent-* > fields using the destination and whatever other fields are specified > in the URL. No! The draft does not mention it, but the (my) intent is that the server (or anything else in the data path) canNOT mess with the data content in any way. > You would, of course, only be able to CHANNEL to mailto > for an entire message or for a subpart which was itself of type > message/rfc822. This seems to me an ideal way to implement the Resend > command in many clients, and could even be used to send draft > messages out for the first time. Yuk. No. Again, CHANNEL is NOT alowwed to modify the data content in ANY way. I will spell this out loudly in the next draft. --lyndon From owner-ietf-imap-voice Wed Mar 6 23:33:24 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g277XOV14848 for ietf-imap-voice-bks; Wed, 6 Mar 2002 23:33:24 -0800 (PST) Received: from il-tlv-smtpout1.icomverse.com (comversegw.icomverse.com [192.118.48.248]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g277XL814829 for ; Wed, 6 Mar 2002 23:33:21 -0800 (PST) Received: from il-tlv-mbdg1.icomverse.com (il-tlv-mbdg1.icomverse.com [10.116.200.32]) by il-tlv-smtpout1.icomverse.com (8.11.6/8.11.6) with ESMTP id g277RHU24183 for ; Thu, 7 Mar 2002 09:27:22 +0200 Received: by il-tlv-mbdg1.icomverse.com with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Mar 2002 09:33:13 +0200 Message-ID: <7D4344E32B34D511A6500002A560C60202FC0E5B@IL-TLV-MAIL4> From: "Erev, Ari" To: "'ietf-imap-voice@imc.org'" Subject: RE: UID for IMAP Channel? Date: Thu, 7 Mar 2002 09:33:08 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C5AA.53B13880" 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_01C1C5AA.53B13880 Content-Type: text/plain; charset="iso-8859-1" I second Alexey's suggestion to support UID with CHANNEL. When Notification scenarios are considered, it may be that the client gets some indication about a specific message for which it then issues a CHANNEL command (i.e, the client did not necessarily received all sequence numbers in the mailbox before issuing the CHANNEL command, so it can't map between UID and sequence number). So, Provided that in the initial notification the UID was referenced, the client can use UID CHANNEL directly. Regards, Ari Erev -----Original Message----- From: Lyndon Nerenberg [mailto:lyndon@atg.aciworldwide.com] Sent: Thursday, March 07, 2002 7:10 AM To: ietf-imap-voice@imc.org Subject: UID for IMAP Channel? Alexey has raised the issue of using UID with channel. I am agnostic on this, and would like to hear from the client folks about whether UID CHANNEL would be a useful addition to this extension. If there is an IMAP BOF this time around perhaps this can be discussed, and the results reported back to the list. --lyndon ------_=_NextPart_001_01C1C5AA.53B13880 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: UID for IMAP Channel?

I second Alexey's suggestion to support UID with = CHANNEL.

When Notification scenarios are considered, it may be = that the client gets some indication about a specific message for which = it then issues a CHANNEL command (i.e, the client did not necessarily = received all sequence numbers in the mailbox before issuing the CHANNEL = command, so it can't map between UID and sequence number).

So, Provided that in the initial notification the UID = was referenced, the client can use UID CHANNEL directly.

Regards,
Ari Erev

-----Original Message-----
From: Lyndon Nerenberg [mailto:lyndon@atg.aciworldwi= de.com]
Sent: Thursday, March 07, 2002 7:10 AM
To: ietf-imap-voice@imc.org
Subject: UID for IMAP Channel?



Alexey has raised the issue of using UID with = channel. I am
agnostic on this, and would like to hear from the = client folks
about whether UID CHANNEL would be a useful addition = to this
extension. If there is an IMAP BOF this time around = perhaps
this can be discussed, and the results reported back = to the
list.

--lyndon

------_=_NextPart_001_01C1C5AA.53B13880-- From owner-ietf-imap-voice Wed Mar 6 23:48:28 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g277mSJ17596 for ietf-imap-voice-bks; Wed, 6 Mar 2002 23:48:28 -0800 (PST) Received: from atg.aciworldwide.com (atg.aciworldwide.com [139.142.180.4] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g277mQ817588 for ; Wed, 6 Mar 2002 23:48:26 -0800 (PST) Received: from atg.aciworldwide.com (atg.aciworldwide.com [139.142.180.33]) by atg.aciworldwide.com (8.12.0/8.12.0) with ESMTP id g277mIsN033473; Thu, 7 Mar 2002 00:48:18 -0700 (MST) Message-Id: <200203070748.g277mIsN033473@atg.aciworldwide.com> Organization: ACI Worldwide - Advanced Technology Group X-URL: http://www.aciworldwide.com/ X-Notes-Item: Just say NO to Notes! To: "Erev, Ari" cc: "'ietf-imap-voice@imc.org'" Subject: Re: UID for IMAP Channel? In-Reply-To: Message from "Erev, Ari" of "Thu, 07 Mar 2002 09:33:08 +0200." <7D4344E32B34D511A6500002A560C60202FC0E5B@IL-TLV-MAIL4> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Thu, 07 Mar 2002 00:48:18 -0700 From: Lyndon Nerenberg Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > When Notification scenarios are considered, it may be that the client gets > some indication about a specific message for which it then issues a CHANNEL > command (i.e, the client did not necessarily received all sequence numbers > in the mailbox before issuing the CHANNEL command, so it can't map between > UID and sequence number). When would a client issue a CHANNEL request when it did not know the sequence number of the message in question? --lyndon From owner-ietf-imap-voice Thu Mar 7 00:06:16 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2786G020569 for ietf-imap-voice-bks; Thu, 7 Mar 2002 00:06:16 -0800 (PST) Received: from il-tlv-smtpout2.icomverse.com (comversegw.icomverse.com [192.118.48.248]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2786E820564 for ; Thu, 7 Mar 2002 00:06:15 -0800 (PST) Received: from il-tlv-mbdg2.icomverse.com (il-tlv-mbdg2.icomverse.com [10.115.244.42]) by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id g27818211364 for ; Thu, 7 Mar 2002 10:01:08 +0200 Received: by IL-TLV-MBDG2 with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Mar 2002 10:06:09 +0200 Message-ID: <7D4344E32B34D511A6500002A560C60202FC0E5D@IL-TLV-MAIL4> From: "Erev, Ari" To: "'ietf-imap-voice@imc.org'" Subject: RE: UID for IMAP Channel? Date: Thu, 7 Mar 2002 10:06:06 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C5AE.EF0B6F90" 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_01C1C5AE.EF0B6F90 Content-Type: text/plain; charset="iso-8859-1" An example: 1. A new message is deposited in the mailbox. 2. With some notification mechanism (e.g. SNAP), a notification is sent to the notification agent in the client (this can be a wireless phone, a PDA etc.) If using SNAP, the UID of the new message is contained in the notification packet. 3. The E-mail client at the PDA can now LOGIN, SELECT INBOX and do a UID CHANNEL to get (for example) a streaming URL - and then by using it, downstream the message (or parts of it). Note that 3 may occur some time after 2 (not necessarily immediately after). So the sequence number of the message at the time the notification was sent, may be different at the time in which 3 is issued. Regards, Ari Erev -----Original Message----- From: Lyndon Nerenberg [mailto:lyndon@atg.aciworldwide.com] Sent: Thursday, March 07, 2002 9:48 AM To: Erev, Ari Cc: 'ietf-imap-voice@imc.org' Subject: Re: UID for IMAP Channel? > When Notification scenarios are considered, it may be that the client gets > some indication about a specific message for which it then issues a CHANNEL > command (i.e, the client did not necessarily received all sequence numbers > in the mailbox before issuing the CHANNEL command, so it can't map between > UID and sequence number). When would a client issue a CHANNEL request when it did not know the sequence number of the message in question? --lyndon ------_=_NextPart_001_01C1C5AE.EF0B6F90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: UID for IMAP Channel?

An example:

1. A new message is deposited in the mailbox.
2. With some notification mechanism (e.g. SNAP), a = notification is sent to the notification agent in the client (this can = be

    a wireless phone, a PDA etc.) If = using SNAP, the UID of the new message is contained in the notification = packet.
3. The E-mail client at the PDA can now LOGIN, = SELECT INBOX and do a UID CHANNEL to get (for example) a
    streaming URL - and then by using = it, downstream the message (or parts of it).

Note that 3 may occur some time after 2 (not = necessarily immediately after). So the sequence number of the message = at the time the notification was sent, may be different at the time in = which 3 is issued.

Regards,
Ari Erev

-----Original Message-----
From: Lyndon Nerenberg [mailto:lyndon@atg.aciworldwi= de.com]
Sent: Thursday, March 07, 2002 9:48 AM
To: Erev, Ari
Cc: 'ietf-imap-voice@imc.org'
Subject: Re: UID for IMAP Channel?


> When Notification scenarios are considered, it = may be that the client gets
> some indication about a specific message for = which it then issues a CHANNEL
> command (i.e, the client did not necessarily = received all sequence numbers
> in the mailbox before issuing the CHANNEL = command, so it can't map between
> UID and sequence number).

When would a client issue a CHANNEL request when it = did not know the
sequence number of the message in question?

--lyndon

------_=_NextPart_001_01C1C5AE.EF0B6F90-- From owner-ietf-imap-voice Thu Mar 7 00:13:04 2002 Received: by above.proper.com (8.11.6/8.11.3) id g278D4x21857 for ietf-imap-voice-bks; Thu, 7 Mar 2002 00:13:04 -0800 (PST) Received: from atg.aciworldwide.com (atg.aciworldwide.com [139.142.180.4] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g278D3821850 for ; Thu, 7 Mar 2002 00:13:03 -0800 (PST) Received: from atg.aciworldwide.com (atg.aciworldwide.com [139.142.180.33]) by atg.aciworldwide.com (8.12.0/8.12.0) with ESMTP id g278CusN033885; Thu, 7 Mar 2002 01:12:56 -0700 (MST) Message-Id: <200203070812.g278CusN033885@atg.aciworldwide.com> Organization: ACI Worldwide - Advanced Technology Group X-URL: http://www.aciworldwide.com/ X-Notes-Item: Just say NO to Notes! to: "Erev, Ari" , "'ietf-imap-voice@imc.org'" Subject: Re: UID for IMAP Channel? In-Reply-To: Message from Lyndon Nerenberg of "Thu, 07 Mar 2002 00:48:18 MST." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Thu, 07 Mar 2002 01:12:56 -0700 From: Lyndon Nerenberg Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > When Notification scenarios are considered, it may be that the client gets > > some indication about a specific message for which it then issues a CHANNEL > > command (i.e, the client did not necessarily received all sequence numbers > > in the mailbox before issuing the CHANNEL command, so it can't map between > > UID and sequence number). IMAP has no "notification scenarios" as this describes. It's a common misconception that UIDs have an equivalence map to IMAP sequence numbers. There are no asynchronous events that map between the two. A client that issues an IMAP CHANNEL request simply asks the server to perform a task on its behalf. The server itself decides if the request is valid, let alone if it is a reasonable idea. --lyndon From owner-ietf-imap-voice Thu Mar 7 00:33:59 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g278XxC24800 for ietf-imap-voice-bks; Thu, 7 Mar 2002 00:33:59 -0800 (PST) Received: from il-tlv-smtpout2.icomverse.com (comversegw.icomverse.com [192.118.48.248]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g278Xv824796 for ; Thu, 7 Mar 2002 00:33:57 -0800 (PST) Received: from il-tlv-mbdg1.icomverse.com (il-tlv-mbdg1.icomverse.com [10.116.200.32]) by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id g278Sq212198 for ; Thu, 7 Mar 2002 10:28:53 +0200 Received: by il-tlv-mbdg1.icomverse.com with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Mar 2002 10:33:54 +0200 Message-ID: <7D4344E32B34D511A6500002A560C60202FC0E5E@IL-TLV-MAIL4> From: "Erev, Ari" To: "'ietf-imap-voice@imc.org'" Subject: RE: UID for IMAP Channel? Date: Thu, 7 Mar 2002 10:33:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C5B2.CF4B6580" 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_01C1C5B2.CF4B6580 Content-Type: text/plain; charset="iso-8859-1" Lyndon, I agree that IMAP has no "notification scenarios". The main scenario of IMAP is mailbox and message access. However, in the messaging world there IS a need for "notification scenarios". This is why SNAP and other protocols are proposed. There are actual (shipping) products and services that issue notifications to end users based on the contents of their e-mail mailbox. Since IMAP is the only practical standard for accessesing messages in a mailbox, these scenarios do use IMAP as part of their sequence. In the example I gave, the scenario is to "directly-access" a specific message (rather than forcing the user to select a messasge from a list in the mailbox). UIDs are not firstly introduced by the "notification scenario". They are part of the IMAP protocol for a long time and are supported in many (if not all?) commands that reference a message or a message set. UIDs are used by E-mail clients as some form of "long-term" id of a message in a mailbox, which persists across IMAP sessions. As far as I know, E-mail clients that cache messages use UIDs to synchonize between their local cache and the remote IMAP mailbox. So, if UIDs exist and are used for "long-term" message identification (across IMAP sessions) - why can't the same mechanism be used in a "notification scenario"? I did not understand your last sentence - "The server itself decides if the request is valid, let alone if it is a reasonable idea." Did I suggest something else? Best Regards, Ari Erev -----Original Message----- From: Lyndon Nerenberg [mailto:lyndon@atg.aciworldwide.com] Sent: Thursday, March 07, 2002 10:13 AM To: Erev, Ari; 'ietf-imap-voice@imc.org' Subject: Re: UID for IMAP Channel? > > When Notification scenarios are considered, it may be that the client gets > > some indication about a specific message for which it then issues a CHANNEL > > command (i.e, the client did not necessarily received all sequence numbers > > in the mailbox before issuing the CHANNEL command, so it can't map between > > UID and sequence number). IMAP has no "notification scenarios" as this describes. It's a common misconception that UIDs have an equivalence map to IMAP sequence numbers. There are no asynchronous events that map between the two. A client that issues an IMAP CHANNEL request simply asks the server to perform a task on its behalf. The server itself decides if the request is valid, let alone if it is a reasonable idea. --lyndon ------_=_NextPart_001_01C1C5B2.CF4B6580 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: UID for IMAP Channel?

Lyndon,

I agree that IMAP has no "notification = scenarios". The main scenario of IMAP is mailbox and message = access.

However, in the messaging world there IS a need for = "notification scenarios". This is why SNAP and other = protocols are proposed. There are actual (shipping) products and = services that issue notifications to end users based on the contents of = their e-mail mailbox.

Since IMAP is the only practical standard for = accessesing messages in a mailbox,  these scenarios do use IMAP as = part of their sequence. In the example I gave, the scenario is to = "directly-access" a specific message (rather than forcing the = user to select a messasge from a list in the mailbox).

UIDs are not firstly introduced by the = "notification scenario". They are part of the IMAP protocol = for a long time and are supported in many (if not all?) commands that = reference a message or a message set.

UIDs are used by E-mail clients as some form of = "long-term" id of a message in a mailbox, which persists = across IMAP sessions. As far as I know, E-mail clients that cache = messages use UIDs to synchonize between their local cache and the = remote IMAP mailbox.

So, if UIDs exist and are used for = "long-term" message identification (across IMAP sessions) - = why can't the same mechanism be used in a "notification = scenario"?


I did not understand your last sentence - "The = server itself decides if the request is valid, let alone if it is a = reasonable idea."

Did I suggest something else?

Best Regards,
Ari Erev

-----Original Message-----
From: Lyndon Nerenberg [mailto:lyndon@atg.aciworldwi= de.com]
Sent: Thursday, March 07, 2002 10:13 AM
To: Erev, Ari; 'ietf-imap-voice@imc.org'
Subject: Re: UID for IMAP Channel?


> > When Notification scenarios are considered, = it may be that the client gets
> > some indication about a specific message = for which it then issues a CHANNEL
> > command (i.e, the client did not = necessarily received all sequence numbers
> > in the mailbox before issuing the CHANNEL = command, so it can't map between
> > UID and sequence number).

IMAP has no "notification scenarios" as = this describes.  It's a common
misconception that UIDs have an equivalence map to = IMAP sequence
numbers. There are no asynchronous events that map = between the two. A
client that issues an IMAP CHANNEL request simply = asks the server to
perform a task on its behalf. The server itself = decides if the request
is valid, let alone if it is a reasonable = idea.

--lyndon

------_=_NextPart_001_01C1C5B2.CF4B6580-- From owner-ietf-imap-voice Thu Mar 7 06:59:55 2002 Received: by above.proper.com (8.11.6/8.11.3) id g27Ext728886 for ietf-imap-voice-bks; Thu, 7 Mar 2002 06:59:55 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g27Exr828882 for ; Thu, 7 Mar 2002 06:59:53 -0800 (PST) Received: from PLATO (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id JAA08454; Thu, 7 Mar 2002 09:57:07 -0500 (EST) Date: Thu, 07 Mar 2002 09:59:14 -0500 From: Cyrus Daboo To: Lyndon Nerenberg , "Erev, Ari" cc: "'ietf-imap-voice@imc.org'" Subject: Re: UID for IMAP Channel? Message-ID: <2051400988.1015495154@PLATO> In-Reply-To: <200203070748.g277mIsN033473@atg.aciworldwide.com> References: <200203070748.g277mIsN033473@atg.aciworldwide.com> X-Mailer: Mulberry/3.0.0d3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, --On Thursday, March 07, 2002 12:48 AM -0700 Lyndon Nerenberg wrote: |> When Notification scenarios are considered, it may be that the client |> gets some indication about a specific message for which it then issues a |> CHANNEL command (i.e, the client did not necessarily received all |> sequence numbers in the mailbox before issuing the CHANNEL command, so |> it can't map between UID and sequence number). | | When would a client issue a CHANNEL request when it did not know the | sequence number of the message in question? It seems to me perfectly reasonable for a disconnected client to use channel. A user may 'queue up' channel requests whilst in disconnected mode and then play those back to the server when connecting. Obviously UIDs have to be used to ensure proper synchronisation in that case. Also, given that every other command that manages message data has a UID equivalent (for the same reason) I think it only right that CHANNEL have it too. I can't see any reason why this would be an extra burden on the server, either. -- Cyrus Daboo From owner-ietf-imap-voice Thu Mar 7 07:21:33 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g27FLXF00182 for ietf-imap-voice-bks; Thu, 7 Mar 2002 07:21:33 -0800 (PST) Received: from episteme-software.com (champdsl-25-66.mcleodusa.net [216.43.25.66]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g27FLV800177 for ; Thu, 7 Mar 2002 07:21:31 -0800 (PST) Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.1); Thu, 7 Mar 2002 09:21:26 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: <200203070635.g276Z9sN032814@atg.aciworldwide.com> References: <200203070635.g276Z9sN032814@atg.aciworldwide.com> X-Mailer: Eudora [Macintosh version 5.1fc3] Date: Thu, 7 Mar 2002 09:21:27 -0600 To: Lyndon Nerenberg From: Pete Resnick Subject: Re: Interesting (gross?) use of CHANNEL Cc: ietf-imap-voice@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 3/6/02 at 11:35 PM -0700, Lyndon Nerenberg wrote: >Urgh. If you mailto:, I would expect the server to simply BARF the >request back to you. The scenario assumes that the server has advertised "CHANNEL=mailto" in the capabilities. >Unless, in some bizarre circumstance, it made sense to honour the request. Why would this request be absurd? >>In my ideal picture, the server would take the message and prepend >>Resent-* fields using the destination and whatever other fields are >>specified in the URL. > >No! The draft does not mention it, but the (my) intent is that the >server (or anything else in the data path) canNOT mess with the data >content in any way. Um, this is just nonsense. Of course when you send the data to RTSP, for example, you're going to send all of the appropriate RTSP commands and then you send the data down the pipe. If it helps, make believe that you are channeling the message to a process that handles the mailto, and that process is the one that prepends Resent-* fields. Remember, what comes after the Resent-* fields is the original data, completely unmodified. >>You would, of course, only be able to CHANNEL to mailto for an >>entire message or for a subpart which was itself of type >>message/rfc822. This seems to me an ideal way to implement the >>Resend command in many clients, and could even be used to send >>draft messages out for the first time. > >Yuk. No. Again, CHANNEL is NOT alowwed to modify the data content in ANY way. What data content is being modified here? You are simply sending the data (unchanged) to another process which is going to do something with it. In some cases, that will be "Play the sounds to the user using a speaker". In my case, it will be "Send this data via SMTP". What's the problem? pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From owner-ietf-imap-voice Thu Mar 7 09:23:58 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g27HNwI08562 for ietf-imap-voice-bks; Thu, 7 Mar 2002 09:23:58 -0800 (PST) Received: from atg.aciworldwide.com (atg.aciworldwide.com [139.142.180.4] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g27HNv808558 for ; Thu, 7 Mar 2002 09:23:57 -0800 (PST) Received: from atg.aciworldwide.com (atg.aciworldwide.com [139.142.180.33]) by atg.aciworldwide.com (8.12.0/8.12.0) with ESMTP id g27HNwsN036750; Thu, 7 Mar 2002 10:23:58 -0700 (MST) Message-Id: <200203071723.g27HNwsN036750@atg.aciworldwide.com> Organization: ACI Worldwide - Advanced Technology Group X-URL: http://www.aciworldwide.com/ X-Notes-Item: Just say NO to Notes! To: Pete Resnick cc: ietf-imap-voice@imc.org Subject: Re: Interesting (gross?) use of CHANNEL In-Reply-To: Message from Pete Resnick of "Thu, 07 Mar 2002 09:21:27 CST." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Thu, 07 Mar 2002 10:23:58 -0700 From: Lyndon Nerenberg Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Okay, I thought you were talking about the IMAP server itself modifying the body content. Yes, it's perfectly reasonable for an external process to modify the body content in order to satisfy the channel request. --lyndon From owner-ietf-imap-voice Sat Mar 9 10:45:33 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g29IjXf19388 for ietf-imap-voice-bks; Sat, 9 Mar 2002 10:45:33 -0800 (PST) Received: from episteme-software.com (champdsl-25-66.mcleodusa.net [216.43.25.66]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g29IjV819384 for ; Sat, 9 Mar 2002 10:45:32 -0800 (PST) Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.1); Sat, 9 Mar 2002 12:45:26 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: <200203071723.g27HNwsN036750@atg.aciworldwide.com> References: <200203071723.g27HNwsN036750@atg.aciworldwide.com> X-Mailer: Eudora [Macintosh version 5.1fc3] Date: Sat, 9 Mar 2002 12:45:24 -0600 To: Lyndon Nerenberg From: Pete Resnick Subject: Re: Interesting (gross?) use of CHANNEL Cc: ietf-imap-voice@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: OK, so now I have a couple of questions: - Am I allowed to get the entire message instead of just a part? - The document says (in a comment) You cannot ask for .HEADERS or .MIME data with CHANNEL. Why not? -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From owner-ietf-imap-voice Sun Mar 10 08:46:20 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2AGkKS19770 for ietf-imap-voice-bks; Sun, 10 Mar 2002 08:46:20 -0800 (PST) Received: from il-tlv-smtpout1.icomverse.com (comversegw.icomverse.com [192.118.48.248]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2AGkG819754 for ; Sun, 10 Mar 2002 08:46:16 -0800 (PST) Received: from il-tlv-mbdg1.icomverse.com (il-tlv-mbdg1.icomverse.com [10.116.200.32]) by il-tlv-smtpout1.icomverse.com (8.11.6/8.11.6) with ESMTP id g2AGdCU14976; Sun, 10 Mar 2002 18:39:12 +0200 Received: by il-tlv-mbdg1.icomverse.com with Internet Mail Service (5.5.2650.21) id ; Sun, 10 Mar 2002 18:46:04 +0200 Message-ID: <7D4344E32B34D511A6500002A560C6020343FCA3@IL-TLV-MAIL4> From: "Giat, Hana" To: "'Pete Resnick'" , Lyndon Nerenberg Cc: ietf-imap-voice@imc.org Subject: RE: Interesting (gross?) use of CHANNEL Date: Sun, 10 Mar 2002 18:45:56 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C853.0CC78E50" 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_01C1C853.0CC78E50 Content-Type: text/plain; charset="iso-8859-1" >- Am I allowed to get the entire message instead of just a part? This seems to be reasonable: I can think about an implementation where a "thin" client on a cellular phone asks only for a message channel, and sends it to a server that will allow it fetch the data in another format. For example, an Email to Speech system. >- The document says (in a comment) > You cannot ask for .HEADERS or .MIME data with CHANNEL. >Why not? I think that CHANNEL is mainly a shortcut to the data. This is not reasonable to ask for a 250 bytes shortcut to a 200 bytes response. That's why. Hana Giat Comverse -----Original Message----- From: Pete Resnick [mailto:presnick@qualcomm.com] Sent: Saturday, March 09, 2002 8:45 PM To: Lyndon Nerenberg Cc: ietf-imap-voice@imc.org Subject: Re: Interesting (gross?) use of CHANNEL OK, so now I have a couple of questions: - Am I allowed to get the entire message instead of just a part? - The document says (in a comment) You cannot ask for .HEADERS or .MIME data with CHANNEL. Why not? -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ------_=_NextPart_001_01C1C853.0CC78E50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Interesting (gross?) use of CHANNEL

>- Am I allowed to get the entire message instead = of just a part?
This seems to be reasonable: I can think about an = implementation where a "thin" client on a cellular phone asks = only for a message channel, and sends it to a server that will allow it = fetch the data in another format. For example, an Email to Speech = system.

 
>- The document says (in a comment)

>         = You cannot ask for .HEADERS or .MIME data with CHANNEL.

>Why not?
I think that CHANNEL is mainly a shortcut to the = data. This is not reasonable to ask for a 250 bytes shortcut to a 200 = bytes response. That's why.

Hana Giat
Comverse

-----Original Message-----
From: Pete Resnick [mailto:presnick@qualcomm.com]<= /FONT>
Sent: Saturday, March 09, 2002 8:45 PM
To: Lyndon Nerenberg
Cc: ietf-imap-voice@imc.org
Subject: Re: Interesting (gross?) use of = CHANNEL



OK, so now I have a couple of questions:

- Am I allowed to get the entire message instead of = just a part?

- The document says (in a comment)

         You = cannot ask for .HEADERS or .MIME data with CHANNEL.

Why not?
--
Pete Resnick <mailto:presnick@qualcomm.com&g= t;
QUALCOMM Incorporated - Direct phone: (858)651-4478, = Fax: (858)651-1102

------_=_NextPart_001_01C1C853.0CC78E50-- From owner-ietf-imap-voice Sun Mar 10 20:10:31 2002 Received: by above.proper.com (8.11.6/8.11.3) id g2B4AVS11311 for ietf-imap-voice-bks; Sun, 10 Mar 2002 20:10:31 -0800 (PST) Received: from episteme-software.com (champdsl-25-66.mcleodusa.net [216.43.25.66]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2B4AT811299 for ; Sun, 10 Mar 2002 20:10:29 -0800 (PST) Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.1); Sun, 10 Mar 2002 22:10:25 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: <7D4344E32B34D511A6500002A560C6020343FCA3@IL-TLV-MAIL4> References: <7D4344E32B34D511A6500002A560C6020343FCA3@IL-TLV-MAIL4> X-Mailer: Eudora [Macintosh version 5.1fc3] Date: Sun, 10 Mar 2002 22:10:24 -0600 To: "Giat, Hana" From: Pete Resnick Subject: RE: Interesting (gross?) use of CHANNEL Cc: Lyndon Nerenberg , ietf-imap-voice@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 3/10/02 at 6:45 PM +0200, Hana Giat wrote: >>- The document says (in a comment) >> >> You cannot ask for .HEADERS or .MIME data with CHANNEL. >> >>Why not? > >I think that CHANNEL is mainly a shortcut to the data. This is not >reasonable to ask for a 250 bytes shortcut to a 200 bytes response. >That's why. Let's say (for example) that I've got some sort of process that does a summary printout of all of the messages I've gotten for the day, listing who they're from, the date, the subject, the content-type, and some other info. Why shouldn't I be able to CHANNEL the headers of a large number of messages to that process to make my report? This, of course, assumes that I've got a URL scheme for which this makes sense, but I don't see a reason to limit the functionality of CHANNEL by not allowing certain kinds of requests. The idea of CHANNEL (as I understood it) was to provide a way for an IMAP client to push some data from an IMAP server straight to some other kind of process without the client having to download the info or the other process having to authorize to the IMAP server. I think keeping that model as general as we can could provide for more functionality than just playing sounds through RTSP. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From owner-ietf-imap-voice Mon Mar 11 10:31:30 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2BIVUm20802 for ietf-imap-voice-bks; Mon, 11 Mar 2002 10:31:30 -0800 (PST) Received: from atg.aciworldwide.com (atg.aciworldwide.com [139.142.180.4] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2BIVT820797 for ; Mon, 11 Mar 2002 10:31:29 -0800 (PST) Received: from atg.aciworldwide.com (atg.aciworldwide.com [139.142.180.33]) by atg.aciworldwide.com (8.12.0/8.12.0) with ESMTP id g2BIVUsN003706; Mon, 11 Mar 2002 11:31:30 -0700 (MST) Message-Id: <200203111831.g2BIVUsN003706@atg.aciworldwide.com> Organization: ACI Worldwide - Advanced Technology Group X-URL: http://www.aciworldwide.com/ X-Notes-Item: Just say NO to Notes! To: Pete Resnick cc: ietf-imap-voice@imc.org Subject: Re: Interesting (gross?) use of CHANNEL In-Reply-To: Message from Pete Resnick of "Sat, 09 Mar 2002 12:45:24 CST." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Mon, 11 Mar 2002 11:31:30 -0700 From: Lyndon Nerenberg Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > - Am I allowed to get the entire message instead of just a part? No, you can only grab things that can be indentified by MIME section numbers. This is an artifact of the syntax, and not necessarily a deliverate retriction. Channel was intended to provide alternative processing of specific body sections. The idea of sending the entire message somewhere never even came up. > - The document says (in a comment) > You cannot ask for .HEADERS or .MIME data with CHANNEL. It didn't seem to be a useful thing to do. At least, not useful enough to justify adding complexity to the parsers to handle it. (Which admittedly isn't a lot of complexity. However I don't like adding "features" to protocols unless there is a compelling need for them. If there's a consensus that fetching .HEADERS and .MIME From owner-ietf-imap-voice Mon Mar 11 10:39:24 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2BIdOY21078 for ietf-imap-voice-bks; Mon, 11 Mar 2002 10:39:24 -0800 (PST) Received: from atg.aciworldwide.com (atg.aciworldwide.com [139.142.180.4] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2BIdN821073 for ; Mon, 11 Mar 2002 10:39:23 -0800 (PST) Received: from atg.aciworldwide.com (atg.aciworldwide.com [139.142.180.33]) by atg.aciworldwide.com (8.12.0/8.12.0) with ESMTP id g2BIdPsN003919; Mon, 11 Mar 2002 11:39:25 -0700 (MST) Message-Id: <200203111839.g2BIdPsN003919@atg.aciworldwide.com> Organization: ACI Worldwide - Advanced Technology Group X-URL: http://www.aciworldwide.com/ X-Notes-Item: Just say NO to Notes! to: Pete Resnick cc: ietf-imap-voice@imc.org Subject: CHANNEL usage X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Mon, 11 Mar 2002 11:39:25 -0700 From: Lyndon Nerenberg Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [Here's the *complete* response -- sorry about the last one that got away early.] > - Am I allowed to get the entire message instead of just a part? No, you can only grab things that can be indentified by MIME section numbers. This is an artifact of the syntax, and not necessarily a deliberate retriction. Channel was intended to provide alternative processing of specific body sections. The idea of sending the entire message somewhere never even came up during the initial design discussions. > - The document says (in a comment) > You cannot ask for .HEADERS or .MIME data with CHANNEL. It didn't seem to be a useful thing to do. At least, not useful enough to justify adding complexity to the parsers to handle it. (Which admittedly isn't a lot of complexity. However I don't like adding features to protocols unless there is a compelling need for them. If there's a consensus that fetching .HEADERS and .MIME is a useful addition, in they go.) The scope of this extension seems to be taking on a life of it's own -- certainly one that's much broader than what Steve and Barry and I originally envisioned. It would be useful to hear what other ways people see themselves using CHANNEL. It may be that we have to revisit some of the original design assumptions we made. --lyndon From owner-ietf-imap-voice Wed Mar 13 16:17:58 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2E0HwP25521 for ietf-imap-voice-bks; Wed, 13 Mar 2002 16:17:58 -0800 (PST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2E0Hu425516 for ; Wed, 13 Mar 2002 16:17:56 -0800 (PST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2E0GYj21480; Wed, 13 Mar 2002 19:16:34 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Mar 2002 19:16:36 -0500 Message-ID: From: "Glenn Parsons" To: IETF VPIM List Cc: "'agenda@ietf.org'" , ietf-imap-voice@imc.org Subject: VPIM WG Agenda Date: Wed, 13 Mar 2002 19:16:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1CAED.84103880" 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_01C1CAED.84103880 Content-Type: text/plain; charset="iso-8859-1" Folks, Here is what I propose for our agenda. Note that our discussion of some of these documents may take a few seconds (e.g., in RFC Editors queue :-) -- while others may take a bit longer... Cheers, Glenn. IETF VPIM WG - 52nd IETF Chair: Glenn Parsons THURSDAY, March 21, 2002 1530-1730 Afternoon Sessions II Duluth Agenda Bashing - 5 minutes VPIM Charter & Milestones review - 5 minutes VPIM v2 r2 - 5 minutes Voice Profile for Internet Mail - version 2 (RFC Editor) (Greg Vaudreuil) draft-ietf-vpim-vpimv2r2-05.txt Feb 18, 2002 draft-ietf-vpim-vpimv2r2-32k-03.txt Feb 15, 2002 draft-ietf-vpim-vpimv2r2-dur-03.txt Feb 15, 2002 MDN drafts (Tony Hansen/Greg Vaudreuil ) draft-vaudreuil-mdnbis-01.txt Nov 4, 2001 DSN drafts (Greg Vaudreuil) draft-moore-1891bis-00.txt June 21, 2001 draft-vaudreuil-1892bis-00.txt June 15, 2001 draft-vaudreuil-1893bis-00.txt June 15, 2001 draft-vaudreuil-1893ext-01.txt Nov 6, 2001 VPIM Addressing (IESG review) - 5 minutes (Glenn Parsons) VPIM Addressing draft-ietf-vpim-address-02.txt Oct 26, 2001 VPIM Directory - 10 minutes (Greg Vaudreuil) Voice Messaging Directory Service (schema) draft-ietf-vpim-vpimdir-02.txt Feb 15, 2002 Voice Message Routing Service draft-ietf-vpim-routing-02.txt Oct 29, 2001 IVM - 45 minutes Goals for Internet Voice Mail (IESG review) (Emily Candell) draft-ietf-vpim-ivm-goals-03.txt June 15, 2001 Internet Voice Messaging (Stuart McRae) draft-ietf-vpim-ivm-03.txt Nov 29, 2001 Critical Content of Internet Mail (IESG review) (Eric Burger) draft-ietf-vpim-cc-05.txt March 1, 2002 Message Context for Internet Mail (IESG review) (Eric Burger) draft-ietf-vpim-hint-07.txt June 5, 2001 (expired) audio/wav with MS-GSM vs. audio/basic with mu-law (Charles Eliot) draft-ema-vpim-msgsm-00.txt April 1, 1999 (deleted) draft-ema-vpim-wav-00.txt June 20, 1999 (deleted) VPIM Addenda - 20 minutes Binary & channel IMAP extensions for VPIM Messages (Lyndon Nerenberg) draft-nerenberg-imap-binary-05.txt Sept 20, 2001 draft-nerenberg-imap-channel-01.txt Nov 27, 2001 draft-burger-imap-chanuse-00.txt Feb 27, 2002 draft-segmuller-imap-structure-00.txt April, 2001 Calling Line Identification for VPIM Messages (Glenn Parsons) draft-ema-vpim-clid-03.txt Mar 7, 2002 Voice Messaging IMAP Client Behaviour (Glenn Parsons) draft-ema-vpim-cb-02.txt July 18, 2001 SIP MWI (Rohan Mahy) draft-sipping-message-waiting-00.txt Nov 14, 2001 SNAP (Noam Shapira) draft-shapira-snap-03.txt Mar 1, 2002 VPIM Re-Charter discussion - 20 minutes draft-vaudreuil-um-issues-00.txt Feb 21, 2002 draft-burger-um-reqts-00.txt Feb 21, 2002 Wrap Up - 5 minutes ------_=_NextPart_001_01C1CAED.84103880 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable VPIM WG Agenda

Folks,

Here is what I propose for = our agenda.=A0=20

Note that our discussion of = some of these documents may take a few seconds (e.g., in RFC Editors = queue :-) -- while others may take a bit longer...

Cheers,
Glenn.
=A0
=A0

IETF VPIM WG - 52nd = IETF
Chair: = =A0 Glenn Parsons = <gparsons@nortelnetworks.com>

THURSDAY, March 21, 2002
1530-1730 Afternoon Sessions = II    Duluth

Agenda Bashing - 5 minutes

VPIM Charter & Milestones = review - 5 minutes

VPIM v2 r2=A0 - 5 minutes

=A0=A0=A0=A0=A0=A0=A0 Voice Profile for Internet Mail - version = 2 (RFC Editor)=A0 (Greg Vaudreuil) =

        draft-ietf-vpim-vpimv2r2-05.txt = =A0=A0=A0=A0=A0=A0=A0 Feb 18, 2002

    draft-ietf-vpim-vpimv2r2-32k-03.txt=A0=A0=A0=A0 Feb 15, = 2002
    draft-ietf-vpim-vpimv2r2-dur-03.txt=A0=A0=A0=A0 Feb 15, = 2002

=A0=A0=A0=A0=A0=A0=A0 MDN drafts = (Tony Hansen/Greg Vaudreuil )

        draft-vaudreuil-mdnbis-01.txt=A0=A0=A0=A0 Nov = 4, 2001

=A0=A0=A0=A0=A0=A0=A0 DSN drafts = (Greg Vaudreuil)

        draft-moore-1891bis-00.txt=A0=A0=A0=A0 June = 21, 2001

    draft-vaudreuil-1892bis-00.txt=A0=A0=A0=A0 June 15, = 2001
    draft-vaudreuil-1893bis-00.txt=A0=A0=A0=A0 June 15, = 2001
    draft-vaudreuil-1893ext-01.txt=A0=A0=A0=A0 Nov 6, = 2001

VPIM Addressing (IESG review) - 5 minutes (Glenn Parsons)

=A0=A0=A0=A0=A0=A0=A0 VPIM Addressing

=A0=A0=A0=A0=A0=A0=A0 draft-ietf-vpim-address-02.txt=A0 =A0=A0=A0=A0=A0=A0=A0 Oct 26, = 2001

VPIM Directory - 10 minutes (Greg Vaudreuil)

=A0=A0=A0=A0=A0=A0=A0 Voice Messaging Directory Service=A0 = (schema)

=A0=A0=A0=A0=A0=A0=A0 draft-ietf-vpim-vpimdir-02.txt=A0 =A0=A0=A0=A0=A0=A0=A0 Feb 15, = 2002

=A0=A0=A0=A0=A0=A0=A0 Voice Message Routing Service

=A0=A0=A0=A0=A0=A0=A0 draft-ietf-vpim-routing-02.txt=A0 =A0=A0=A0=A0=A0=A0=A0 Oct 29, = 2001

IVM=A0 - 45 minutes

=A0=A0=A0=A0=A0=A0=A0 Goals for Internet Voice Mail (IESG = review)=A0 (Emily Candell)

=A0=A0=A0=A0=A0=A0=A0 draft-ietf-vpim-ivm-goals-03.txt=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 June 15, 2001 =

=A0=A0=A0=A0=A0=A0=A0 Internet Voice Messaging=A0 (Stuart McRae)

=A0=A0=A0=A0=A0=A0=A0 draft-ietf-vpim-ivm-03.txt=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 = Nov 29, 2001

=A0=A0=A0=A0=A0=A0=A0 Critical Content of Internet = Mail=A0(IESG review) (Eric Burger)

=A0=A0=A0=A0=A0=A0=A0 draft-ietf-vpim-cc-05.txt = =A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0 March 1, 2002

=A0=A0=A0=A0=A0=A0=A0 Message Context for Internet = Mail=A0(IESG review) (Eric Burger)

=A0=A0=A0=A0=A0=A0=A0 draft-ietf-vpim-hint-07.txt = =A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 June 5, 2001 (expired)

=A0=A0=A0=A0=A0=A0=A0 audio/wav with MS-GSM vs. audio/basic with = mu-law=A0=A0 (Charles Eliot)

            draft-ema-vpim-msgsm-00.txt =A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0 April 1, 1999=A0 (deleted)

            draft-ema-vpim-wav-00.txt=A0 =A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0 June 20, 1999 (deleted)

VPIM Addenda - 20 minutes

=A0=A0=A0=A0=A0=A0=A0 Binary & channel IMAP extensions for VPIM = Messages=A0 (Lyndon Nerenberg)

=A0=A0=A0=A0=A0=A0=A0 draft-nerenberg-imap-binary-05.txt=A0 =A0=A0=A0 Sept 20, 2001

=A0=A0=A0=A0=A0=A0=A0 draft-nerenberg-imap-channel-= 01.txt=A0 =A0=A0 Nov 27, 2001
 
=A0=A0=A0=A0=A0=A0=A0 draft-burger-imap-chanuse-00.txt=A0 = =A0=A0=A0 Feb = 27, 2002

=A0=A0=A0=A0=A0=A0=A0 draft-segmuller-imap-structure-00.txt=A0 =A0=A0=A0 April, 2001

=A0=A0=A0=A0=A0=A0=A0 Calling Line Identification for VPIM = Messages=A0 (Glenn Parsons)

=A0=A0=A0=A0=A0=A0=A0 draft-ema-vpim-clid-03.txt = =A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 Mar 7, 2002 =

=A0=A0=A0=A0=A0=A0=A0 Voice Messaging IMAP Client = Behaviour=A0 (Glenn Parsons)

=A0=A0=A0=A0=A0=A0=A0 draft-ema-vpim-cb-02.txt=A0 = =A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 July 18, 2001 =

=A0=A0=A0=A0=A0=A0=A0 SIP MWI=A0 = (Rohan Mahy)

=A0=A0=A0=A0=A0=A0=A0 draft-sipping-message-waiting-00.txt=A0=A0 Nov 14, 2001

=A0=A0=A0=A0=A0=A0=A0 SNAP (Noam = Shapira)

=A0=A0=A0=A0=A0=A0=A0 draft-shapira-snap-03.txt=A0=A0 Mar 1, 2002

VPIM Re-Charter = discussion - 20 = minutes

=A0=A0=A0=A0=A0=A0=A0 draft-vaudreuil-um-issues-00.txt=A0 = =A0=A0=A0 Feb = 21, 2002

=A0=A0=A0=A0=A0=A0=A0 draft-burger-um-reqts-00.txt=A0 = =A0=A0=A0 Feb = 21, 2002

Wrap Up - 5 minutes




------_=_NextPart_001_01C1CAED.84103880-- From owner-ietf-imap-voice Sun Mar 17 20:24:24 2002 Received: by above.proper.com (8.11.6/8.11.3) id g2I4OO125651 for ietf-imap-voice-bks; Sun, 17 Mar 2002 20:24:24 -0800 (PST) Received: from noc-e.ietf53.cw.net (noc-e.ietf53.cw.net [166.63.177.40]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2I4ON425647 for ; Sun, 17 Mar 2002 20:24:23 -0800 (PST) Received: from eburger (unknown [166.63.189.43]) by noc-e.ietf53.cw.net (Postfix) with SMTP id 2443A6A928; Mon, 18 Mar 2002 00:08:58 +0000 (GMT) Reply-To: From: "Eric Burger" To: "Pete Resnick" , "Lyndon Nerenberg" Cc: , "IETF UM" Subject: RE: Interesting (gross?) use of CHANNEL Date: Sun, 17 Mar 2002 23:24:09 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I have to hop in here: Is CHANNEL sensible if the end-system does not get "transformed" data? Transcoding *HAS* to be a legitimate use of CHANNEL. Filtering *HAS* to be a legitimate use of CHANNEL. Why? If the bytes/packets are not modified, why use anything other than IMAP? The WHOLE POINT of CHANNEL is to get the data in a "more useful" form, possibly from an "easier" place. I do agree that the semantic content of the data may not be altered. However, almost by definition the client is requesting alternate format, possibly done on the fly. CHANNEL transformations are (1) by client request and (2) do not change the semantic value of the data. What is the basis for the objection? -- - Eric -------------------------------------------- Lyndon Said, and Pete Replied: [snip] >Yuk. No. Again, CHANNEL is NOT alowwed to modify the data content in ANY way. What data content is being modified here? You are simply sending the data (unchanged) to another process which is going to do something with it. In some cases, that will be "Play the sounds to the user using a speaker". In my case, it will be "Send this data via SMTP". What's the problem? pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From owner-ietf-imap-voice Mon Mar 18 07:31:29 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2IFVT421303 for ietf-imap-voice-bks; Mon, 18 Mar 2002 07:31:29 -0800 (PST) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2IFVR421299; Mon, 18 Mar 2002 07:31:28 -0800 (PST) Received: from co7040exch001p.wins.lucent.com (h135-39-1-40.lucent.com [135.39.1.40]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g2IFVNB16047; Mon, 18 Mar 2002 10:31:23 -0500 (EST) Received: by co7040exch001p.milehi.lucent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Mar 2002 08:31:22 -0700 Message-ID: <0096D8500C92D211BAEB0008C7F4906C05DAD101@co7040exch002u.milehi.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: "Zmolek, Andrew (Andrew)" , dcrocker@brandenburg.com, gparsons@nortelnetworks.com, eburger@snowshore.com, vpim@lists.neystadt.org, ietf-fax@imc.org, um@snowshore.com, ietf-imap-voice@imc.org Subject: Mail Extensions for Unified Messaging / TUI Access to Email BOF Date: Mon, 18 Mar 2002 08:31:18 -0700 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: I would like to have the first meeting of the TUI/UM extensions Bar BOF meeting TODAY in the 1-3 PM timeslot. Let's meet at the message board. If you arrive and there are no people there, check the board for a forward location pointer. Greg V. -----Original Message----- From: Vaudreuil, Greg M (Greg) Sent: Wednesday, March 06, 2002 2:04 PM To: Zmolek, Andrew (Andrew); dcrocker@brandenburg.com; gparsons@nortelnetworks.com; eburger@snowshore.com; vpim@lists.neystadt.org Subject: [VPIM] RE: Rolling BoF? Lets set a first session from 1-3 Monday, and pick up additional timeslots from there if we find a productive track. The goal is to determine if we have a topic of sufficient interest and contributors priority to pursue chartering as a formal IETF work-group. I am particularly interested in soliciting attendance by folks tuned into the latest 3GPP MMS work and standards needs. I can't guess accurately a location. I will pick a spot and post it on the IETF message board by Monday morning. I am sure many of us may gather in the hallway after the Apps area meeting for lunch. Greg V. -----Original Message----- From: Zmolek, Andrew (Andrew) [mailto:zmolek@avaya.com] Sent: Tuesday, March 05, 2002 2:49 PM To: Vaudreuil, Greg M (Greg); dcrocker@brandenburg.com; gparsons@nortelnetworks.com; eburger@snowshore.com; vpim@lists.neystadt.org Subject: RE: Rolling BoF? I agree with Greg that a "Rolling BoF" would be a good thing, particularly since the WG is double-scheduled with midcom and I need to cover at least some part of both. But I'm not sure what a "Rolling BoF" means (scheduled vs. spontaneous, etc.). What did you have in mind, Greg? --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 ---------------------------------------------------------- This message was sent to you, since you are subscribed to vpim@lists.neystadt.org. You can manage your subscription at http://www.neystadt.org/cgi-bin/majordomo From owner-ietf-imap-voice Mon Mar 18 08:38:20 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2IGcKx28482 for ietf-imap-voice-bks; Mon, 18 Mar 2002 08:38:20 -0800 (PST) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2IGcI428477; Mon, 18 Mar 2002 08:38:18 -0800 (PST) Received: from messagingdirect.com (gagarin.win.esys.ca [166.63.188.140] (may be forged)) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g2IGf6j22847; Mon, 18 Mar 2002 09:41:06 -0700 Message-ID: <3C9618A2.FBBF3129@messagingdirect.com> Date: Mon, 18 Mar 2002 09:41:06 -0700 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: IMAP Extensions WG , IMAP VPIM Mailing List Subject: [Fwd: IMAPEXT bar BOF in Minneapolis] Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As we just discussed with Pere, we should also discuss CHANNEL and BINARY. -------- Original Message -------- Subject: IMAPEXT bar BOF in Minneapolis Date: Sun, 17 Mar 2002 18:36:38 -0700 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect To: IMAP Extensions WG Monday around 16.30 near the message board. (This should start after SASL bar BOF, I believe a lot of people interested in IMAPEXT will attend SASL as well). Tentative agenda: IMAP ACL2 issues (in no particular order): 1). REPLACEACL 2). Setting an ACL on a mailbox hierarchy. 3). How to encode user names starting with "-" and "$". 4). 'r' to read QUOTA and ACL? 5). 'a' to read ACL as well. 6). Which set of rights correspond to READ-WRITE? Cyrus and our MessagingDirect server: if either "w" or "t" are allowed for the current user Communigate: when only "s" allowed. 7). Subscription and listing: LIST - 'l' right LSUB - 'l'? (if subscription is not an attribute of a mailbox?) SUBSCRIBE: Cyrus requires either 'l' or 'r'. Communigate requires no rights. UNSUBSCRIBE - always allowed? 8). COPY MUST check 'w'/'t'/'s' when copying flags? (Make it SHOULD as no known implementation check for 'w'/'d'/'s'?) 9). ACL and LISTEXT/ANNOTATEMORE: Cyrus wrote: The other option would be to allow status with only the 'l' bit, which currently allows LIST/LSUB for a mailbox. If we ever get around to extending list, I believe one of the proposals did have list returning the equivalent of status information, so there might be some awkward interaction with ACL on that. 10). Replace "anonymous" with $anonymous? 11). Separate "world" vs. "anonymous" access There are more questions but I have to dig them out. CONDSTORE issues: 1). How user defined flags (keywords) map to annotations? (Currently draft suggests to use "-" as prefix). 2). I had to extend the syntax for FETCH/SEARCH/STORE to allow to specify whether private or shared flag should be used for the conditional operation. This is a result of a change in one of the latest ANNOTATE revisions. The change removed default annotation type for STORE operation. 3). What entry-type-resp (i.e. "private" or "shared") should be used in unsolicited flag responses? What about STORE/UID STORE on flags? 4). SEARCH: MODSEQ XXX OR KEYWORDS $Fff Return MODSEQ response code for all found messages (simplest, but requires that modsequence of every found message is obtained, no optimizations allowed)? What about SEARCH NOT MODSEQ YYY? ANNOTATE/ANNOTATEMORE issues. Regards, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 I speak for myself only, not for my employer. __________________________________________ From owner-ietf-imap-voice Mon Mar 18 15:29:25 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2INTPA14177 for ietf-imap-voice-bks; Mon, 18 Mar 2002 15:29:25 -0800 (PST) Received: from episteme-software.com (champdsl-25-66.mcleodusa.net [216.43.25.66]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2INTN414173 for ; Mon, 18 Mar 2002 15:29:23 -0800 (PST) Received: from [166.63.185.240] (166.63.185.240) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.1); Mon, 18 Mar 2002 17:29:16 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: References: X-Mailer: Eudora [Macintosh version 5.1b21-04.02] Date: Mon, 18 Mar 2002 17:28:44 -0600 To: From: Pete Resnick Subject: RE: Interesting (gross?) use of CHANNEL Cc: "Lyndon Nerenberg" , , "IETF UM" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 3/17/02 at 11:24 PM -0500, Eric Burger wrote: >I have to hop in here: Is CHANNEL sensible if the end-system does >not get "transformed" data? Lyndon actually backed off of his original position; it can certainly be transformed, but it shouldn't be changed while it's still on the IMAP server. However, there is a perfectly legitimate use of untransformed data: >Why? If the bytes/packets are not modified, why use anything other >than IMAP? The WHOLE POINT of CHANNEL is to get the data in a "more >useful" form, possibly from an "easier" place. You've said it yourself: You might want to get the data from an "easier place". That is, you don't want to have to tell another system to go to an IMAP server and go through all of the authentication and IMAP overhead that you've already dealt with. You want to push the data to another process. I'd like to write up the mailto: use of CHANNEL. Would you be willing to include it in draft-burger-imap-chanuse-00.txt? pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From owner-ietf-imap-voice Mon Mar 18 15:51:26 2002 Received: by above.proper.com (8.11.6/8.11.3) id g2INpQp14775 for ietf-imap-voice-bks; Mon, 18 Mar 2002 15:51:26 -0800 (PST) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2INpP414771; Mon, 18 Mar 2002 15:51:25 -0800 (PST) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.1/8.12.1/1.0) with ESMTP id g2INpL2x004881; Mon, 18 Mar 2002 15:51:21 -0800 (PST) Received: from [166.63.185.167] (vpnap-g1-012015.qualcomm.com [10.13.12.15]) by magus.qualcomm.com (8.12.1/8.12.1/1.0) with ESMTP id g2INpFYB014999; Mon, 18 Mar 2002 15:51:19 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <3C9618A2.FBBF3129@messagingdirect.com> References: <3C9618A2.FBBF3129@messagingdirect.com> X-Mailer: Eudora v5.1 for Macintosh Date: Mon, 18 Mar 2002 17:51:13 -0600 To: Alexey Melnikov , IMAP Extensions WG , IMAP VPIM Mailing List From: Randall Gellens Subject: Re: [Fwd: IMAPEXT bar BOF in Minneapolis] Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 9:41 AM -0700 3/18/02, Alexey Melnikov wrote: > 1). How user defined flags (keywords) map to annotations? (Currently > draft suggests to use "-" as prefix). Seems reasonable. > > 2). I had to extend the syntax for FETCH/SEARCH/STORE to allow to > specify whether private or shared flag should be used > for the conditional operation. This is a result of a change in one > of the latest ANNOTATE revisions. > The change removed default annotation type for STORE operation. I like the idea of not having a default for shared/private on STORE operations. Make the client know what it is doing. > > 3). What entry-type-resp (i.e. "private" or "shared") should be used in > unsolicited flag responses? Both if they exist? > What about STORE/UID STORE on flags? From owner-ietf-imap-voice Mon Mar 18 18:21:46 2002 Received: by above.proper.com (8.11.6/8.11.3) id g2J2LkU18405 for ietf-imap-voice-bks; Mon, 18 Mar 2002 18:21:46 -0800 (PST) Received: from noc-e.ietf53.cw.net (noc-e.ietf53.cw.net [166.63.177.40]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2J2Lj418401 for ; Mon, 18 Mar 2002 18:21:45 -0800 (PST) Received: from eburger (eburger.ietf53.cw.net [166.63.188.46]) by noc-e.ietf53.cw.net (Postfix) with SMTP id A8B316A901; Mon, 18 Mar 2002 20:21:48 -0600 (CST) Reply-To: From: "Eric Burger" To: "Pete Resnick" Cc: "Lyndon Nerenberg" , , "IETF UM" Subject: RE: Interesting (gross?) use of CHANNEL Date: Mon, 18 Mar 2002 21:21:31 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Actually, you're right on the "non-transforming" use of CHANNEL. I can put a mailto: CHANNEL scenario into the next draft. I know Greg really wants it. -----Original Message----- From: Pete Resnick [mailto:presnick@qualcomm.com] Sent: Monday, March 18, 2002 6:29 PM To: eburger@snowshore.com Cc: Lyndon Nerenberg; ietf-imap-voice@imc.org; IETF UM Subject: RE: Interesting (gross?) use of CHANNEL On 3/17/02 at 11:24 PM -0500, Eric Burger wrote: >I have to hop in here: Is CHANNEL sensible if the end-system does >not get "transformed" data? Lyndon actually backed off of his original position; it can certainly be transformed, but it shouldn't be changed while it's still on the IMAP server. However, there is a perfectly legitimate use of untransformed data: >Why? If the bytes/packets are not modified, why use anything other >than IMAP? The WHOLE POINT of CHANNEL is to get the data in a "more >useful" form, possibly from an "easier" place. You've said it yourself: You might want to get the data from an "easier place". That is, you don't want to have to tell another system to go to an IMAP server and go through all of the authentication and IMAP overhead that you've already dealt with. You want to push the data to another process. I'd like to write up the mailto: use of CHANNEL. Would you be willing to include it in draft-burger-imap-chanuse-00.txt? pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From owner-ietf-imap-voice Tue Mar 19 11:19:59 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2JJJx628288 for ietf-imap-voice-bks; Tue, 19 Mar 2002 11:19:59 -0800 (PST) Received: from lin2.andrew.cmu.edu (LIN2.ANDREW.CMU.EDU [128.2.6.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2JJJw428284 for ; Tue, 19 Mar 2002 11:19:58 -0800 (PST) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.121.100]) by lin2.andrew.cmu.edu (8.12.3.Beta0/8.12.2.Beta3) with ESMTP id g2JJJm4F017837; Tue, 19 Mar 2002 14:19:49 -0500 Date: Tue, 19 Mar 2002 14:19:48 -0500 Message-Id: <200203191919.g2JJJm4F017837@lin2.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: ietf-imap-voice@imc.org Subject: CHANNEL and proxy credentials Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Advanced authentication frameworks support proxy credentials. The most obvious example of this is Kerberos V. An extremely naive example is just sending your password to the server that you want to act on your behalf. There have also been discussions of this in the PKI world, though I'm not familiar with them. This is something that might be useful for channel. While there's no specification corresponding to SASL on how to ask for or transmit credentials, attempting to add such a thing to channel would be worthwhile so we can gain experience with it and see what's going on. It would probably be sufficient to have another paren'd list send as part of the channel command, so: a CHANNEL ("KERBEROS_V5" "PKIX509BLAH" ) ... for the client to transmit some sort of proxy credentials to the server which it thinks might be useful for the IMAP server to make the established channel. In the kerberos world the blob would be proxiable ticket (see 2.5 of draft-ietf-krb-wg-kerberos-clarifications-00 for instance). The server would decode the blob and stuff it into its kerberos (client) ticket cache. Larry From owner-ietf-imap-voice Tue Mar 19 13:59:57 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2JLxvf04311 for ietf-imap-voice-bks; Tue, 19 Mar 2002 13:59:57 -0800 (PST) Received: from noc-e.ietf53.cw.net (noc-e.ietf53.cw.net [166.63.177.40]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2JLxu404307 for ; Tue, 19 Mar 2002 13:59:56 -0800 (PST) Received: from eburger (eburger.ietf53.cw.net [166.63.189.43]) by noc-e.ietf53.cw.net (Postfix) with SMTP id 4253C6A922; Tue, 19 Mar 2002 15:59:58 -0600 (CST) Reply-To: From: "Eric Burger" To: "Lawrence Greenfield" Cc: Subject: RE: CHANNEL and proxy credentials Date: Tue, 19 Mar 2002 16:59:40 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <200203191919.g2JJJm4F017837@lin2.andrew.cmu.edu> Importance: Normal Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Whether it is Kerberos V or proxy challenge or S/MIME (?), CHANNEL must have some sort of authentication. Without it, we might have trouble progressing the draft. That said, this may be a non-solvable problem: what does the server pass back when the result is a rtsp: response? a sip: response? a http: response? etc... Remember, there is a liklihood that the response to CHANNEL will result in a physically separate node from the IMAP server. -----Original Message----- From: owner-ietf-imap-voice@mail.imc.org [mailto:owner-ietf-imap-voice@mail.imc.org]On Behalf Of Lawrence Greenfield Sent: Tuesday, March 19, 2002 2:20 PM To: ietf-imap-voice@imc.org Subject: CHANNEL and proxy credentials Advanced authentication frameworks support proxy credentials. The most obvious example of this is Kerberos V. An extremely naive example is just sending your password to the server that you want to act on your behalf. There have also been discussions of this in the PKI world, though I'm not familiar with them. This is something that might be useful for channel. While there's no specification corresponding to SASL on how to ask for or transmit credentials, attempting to add such a thing to channel would be worthwhile so we can gain experience with it and see what's going on. It would probably be sufficient to have another paren'd list send as part of the channel command, so: a CHANNEL ("KERBEROS_V5" "PKIX509BLAH" ) ... for the client to transmit some sort of proxy credentials to the server which it thinks might be useful for the IMAP server to make the established channel. In the kerberos world the blob would be proxiable ticket (see 2.5 of draft-ietf-krb-wg-kerberos-clarifications-00 for instance). The server would decode the blob and stuff it into its kerberos (client) ticket cache. Larry From owner-ietf-imap-voice Tue Mar 19 14:12:01 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2JMC1204708 for ietf-imap-voice-bks; Tue, 19 Mar 2002 14:12:01 -0800 (PST) Received: from atg.aciworldwide.com (atg.aciworldwide.com [139.142.180.4] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2JMBw404695 for ; Tue, 19 Mar 2002 14:11:59 -0800 (PST) Received: from atg.aciworldwide.com (atg.aciworldwide.com [139.142.180.33]) by atg.aciworldwide.com (8.12.0/8.12.0) with ESMTP id g2JMC1sN043530; Tue, 19 Mar 2002 15:12:01 -0700 (MST) Message-Id: <200203192212.g2JMC1sN043530@atg.aciworldwide.com> Organization: ACI Worldwide - Advanced Technology Group X-URL: http://www.aciworldwide.com/ X-Notes-Item: Just say NO to Notes! To: eburger@snowshore.com cc: ietf-imap-voice@imc.org Subject: Re: CHANNEL and proxy credentials In-Reply-To: Message from "Eric Burger" of "Tue, 19 Mar 2002 16:59:40 EST." Date: Tue, 19 Mar 2002 15:12:01 -0700 From: Lyndon Nerenberg Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: There is an underlying assumption that an IMAP server offering CHANNEL services is doing this by implementing the additional schemes internally, or with the cooperation of a trusted external service. Presumably these servers share an authentication namespace. The only way to override this is by specifying authentication information in the URI (where the scheme permits this). --lyndon From owner-ietf-imap-voice Tue Jun 18 15:28:10 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5IMSAX24502 for ietf-imap-voice-bks; Tue, 18 Jun 2002 15:28:10 -0700 (PDT) Received: from atg.aciworldwide.com ([139.142.180.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5IMS9n24498; Tue, 18 Jun 2002 15:28:09 -0700 (PDT) Received: from atg.aciworldwide.com (atg.aciworldwide.com [139.142.180.33]) by atg.aciworldwide.com (8.12.0/8.12.0) with ESMTP id g5IMSBgS052380; Tue, 18 Jun 2002 16:28:11 -0600 (MDT) Message-Id: <200206182228.g5IMSBgS052380@atg.aciworldwide.com> To: IMAP Interest Groups: ; Subject: IMAP Channel Draft version 2 released X-URL: http://www.aciworldwide.com/ X-Notes-Item: Just say NO to Notes! Organization: ACI Worldwide - Advanced Technology Group X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Tue, 18 Jun 2002 16:28:11 -0600 From: Lyndon Nerenberg Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've pushed version 02 of the Channel draft to the ID editor. Early access can be had at: http://atg.aciworldwide.com/draft-nerenberg-imap-channel-02.txt Diffs from version 01: Changed to use instead of . This allows retrieval of headers and MIME structure. returns a , not (to match syntax). Add missing SP tokens to grammar. Grammar fix to allow foo: as a valid URI in a request. Add UID CHANNEL. Clarify response when client issues a command with an unsupported scheme. Add section on command sequencing. Note arbitrary ordering of untagged responses. Replace URI-reference with absoluteURI. The IMAP server can't maintain the state required to deal with relative URIs. This also solves an ambiguity between parsing "NIL" as or as a relative URI. --lyndon _ 12 + 144 + 20 + 3(\/4) 2 ---------------------- + 5(11) = 9 + 0 7 A dozen, a gross and a score, Plus three times the square root of four, Divided by seven, Plus five times eleven, Equals nine squared plus zero, no more! From owner-ietf-imap-voice Thu Sep 27 09:49:38 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8RGncMO092421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Sep 2007 09:49:38 -0700 (MST) (envelope-from owner-ietf-imap-voice@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8RGnc7g092420; Thu, 27 Sep 2007 09:49:38 -0700 (MST) (envelope-from owner-ietf-imap-voice@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imap-voice@mail.imc.org using -f Received: from [200.24.41.3] ([200.24.41.3]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8RGnagM092413 for ; Thu, 27 Sep 2007 09:49:37 -0700 (MST) (envelope-from marking@tatanka.com) Received: from [200.24.41.3] by tatanka.com; Thu, 27 Sep 2007 11:49:35 -0500 Message-ID: <01c80126$62797090$032918c8@marking> From: "Dick Harrell" To: Subject: Your doctors advice Date: Thu, 27 Sep 2007 11:49:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-imap-voice@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: We will never dare to discredit our good name by trying to sell low-quality goods! We aim at establishing good healthy relations with our customers - and our generic brand-name products never let them down! http://bwccso.ixflintere.info/?kqwzgxhswisu