From owner-um@snowshore.com Sat Mar 1 00:01:24 2003 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id h2151HY01780 for um-outgoing; Sat, 1 Mar 2003 00:01:17 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id h2151F901776 for ; Sat, 1 Mar 2003 00:01:15 -0500 (EST) Received: from sdn-ap-007txhousP0129.dialsprint.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id VAA21418 for ; Fri, 28 Feb 2003 21:00:45 -0800 Date: Fri, 28 Feb 2003 16:48:28 -0600 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/4) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <715988931.20030228164828@brandenburg.com> To: "IETF LEMONADE (E-mail)" Subject: Re: [UM] Re: WG Review: Enhancements to Internet email to support diverse service environments (lemonade) In-Reply-To: <01KSWSOTZRMS002DEU@mauve.mrochek.com> References: <4A3384433CE2AB46A63468CB207E209D097BFB@zoe.office.snowshore.com> <5.1.0.14.2.20030225105642.00a777f8@mage.qualcomm.com> <6221153477.20030225132747@dcrocker.net> <1744588244.20030225195822@brandenburg.com> <11454940189.20030225225054@brandenburg.com> <01KSVK22FX2C007FVT@mauve.mrochek.com> <638399057.20030226214738@brandenburg.com> <01KSWSOTZRMS002DEU@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-um@snowshore.com Precedence: bulk Folks, First of all, I note that no one else seems particularly troubled by the draft charter language, so this will be my last posting on this thread, unless others wish to pursue it. Second, I suspect that the nature of the exchange about this has been completely missed: There are significant things about the framework of the working group that were not at all clear to an informed reader of the current text. And it took significant discussion to get to the stage of clarifying things. There is a myriad of spiffy enhancements we might choose to do. In fact I happen to like the ones that are listed and believe that Internet mail will be the better for having them. However if we do not have a clear statement of the reasons for doing this particular set of things -- and by that I mean a very clear and thorough statement of what problem needs to be solved, or what benefit needs to be obtained -- then we are expending millions of dollars -- the aggregate cost of pretty much any IETF standard -- on what is really a whim, or at least a blind market gamble. And that is one of the major problems stalking IETF work. For example, I'll claim that it has been one of the problems that led to the complexity of IMAP. And lastly: Thursday, February 27, 2003, 12:54:30 AM, you wrote: >> 1. Enhancements to Internet mail for better operation with >> resource-constrained devices and with channels that are high latency >> and/or low bandwidth Nummc> Deliverables 1, 2, and 3. >> 2. Specification of a gateway between existing Internet mail and >> other email services operating in such constrained environments. Nummc> Deliverable 5. The deliverables are the "what". What is missing is an unambiguous and concrete statement of "why". The current text is sufficiently vague as to be useless. (If fact I have no idea how the proposed work in any way pertains to memory constraints on the participating systems.) If my proposed text to overly precise, then it too needs to be fixed. And, by the way, The fact that #5 is a separate project, with a separate goal from the other deliverables, was something that I simply did not see from the current draft text. Nor the fact that the goal is to build a gateway. And these strike me seriously non-trivial failures to grog the purpose of the working group. Permit me the small arrogance of thinking that if I had that trouble understanding the charter, so will others. TH> Maybe I misunderstood you, but I thought you believed that the TH> deliverables were clear and constrained in the new version. Except for the last one, calling for gateway work, yes I do. And that is why I started to revert to treating the first paragraph concerns as secondary. However then it became apparent to me that other folks seemed unclear about the nature and reasons for the work. TH> I think we're back to the question TH> of the opening paragraph word smithing. There's really only so TH> much that can be done there; we shouldn't try to include all the deliverables I am trying to clear about the difference between needs/benefits, versus "means". This is not about citing the deliverables in the opening paragraph. It is about making the reasons for the work and the planned benefits clearer. The deliverables are specific things that will be done. What is not stated is why or how any of them are needed. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Mon Mar 3 20:00:48 2003 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id h2410Ea10843 for um-outgoing; Mon, 3 Mar 2003 20:00:14 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from oe-im1.bizmailsrvcs.net (oe-im1pub.managedmail.com [206.46.164.52]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id h2410Cx10839 for ; Mon, 3 Mar 2003 20:00:12 -0500 (EST) Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-im1.bizmailsrvcs.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP id <20030304010007.HVNH12408.oe-im1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Mon, 3 Mar 2003 19:00:07 -0600 Received: from AKSTEBBENS.mshome.net ([64.14.194.123]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP id <20030304010006.HGKT1545.oe-ismta1.bizmailsrvcs.net@AKSTEBBENS.mshome.net>; Mon, 3 Mar 2003 19:00:06 -0600 Date: Mon, 3 Mar 2003 17:00:05 -0800 From: "Alan K. Stebbens" X-Mailer: The Bat! (v1.62i) Personal Reply-To: "Alan K. Stebbens" Organization: Openwave Systems, Inc. X-Priority: 3 (Normal) Message-ID: <12779831962.20030303170005@openwave.com> To: IETF-Lemonade CC: Milt Roselinsky Subject: [UM] draft-stebrose-mmsarch-00.txt MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------85AC17761C613B" Sender: owner-um@snowshore.com Precedence: bulk ------------85AC17761C613B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Lemonade folks, Attached is a draft I-D: draft-stebrose-mmsarch-00.txt (which I've also submitted to the RFC Editor), for which the abstract follows: The increasing importance of messaging as a potential source of revenue for mobile networks has led operators to build or procure mobile messaging solutions. Some operators have built mobile messaging solutions using IETF standards (IMAP, SMTP, MIME). Another solution has been developed by consensus in the 3GPP and OMA groups, based on MIME, HTTP methods and WAP PUSH, which has been deployed by many operators. This document presents a taxonomy of messaging architecture components and models, providing a comparison of their feature sets. It also identifies the commonalities of these mobile messaging solutions and abstracts from these a set of mobile messaging requirements. The information is provided to inform and encourage future discussion of and improvements to Internet messaging in order to increase their applicability to mobile messaging systems. My colleague, Milt Roselinsky, and I will be presenting on this topic at LEMONADE WG at the upcoming IETF. I look forward to our ensuing discussions. -- Best regards, Alan K. Stebbens Messaging Architectures & Standards Openwave Systems, Inc. Cell: +1.805.886.8886 Voice/Fax: +1.866.579.0801 Desk: +1.805.884.3162 Yahoo IM: alan_stebbens AIM: akstebbens ------------85AC17761C613B Content-Type: text/plain; name="draft-stebrose-mmsarch-00.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-stebrose-mmsarch-00.txt" DQoNCiAgIExFTU9OQURFIFdHICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIA0KICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEFsYW4gSy4gU3RlYmJlbnMgDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1pbHQgUm9zZWxpbnNreSANCiAg IERvY3VtZW50OiBkcmFmdC1zdGVicm9zZS1tbXNhcmNoLTAwLnR4dCAgICAgICAgICAgICBPcGVu d2F2ZSBTeXN0ZW1zIA0KICAgRXhwaXJlczogU2VwdGVtYmVyIDIwMDMgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIE1hcmNoIDIwMDMgDQogICAgDQogICAgDQogICAgICAgICAgICAg IE1vYmlsZSBNZXNzYWdpbmcgQXJjaGl0ZWN0dXJlcyBhbmQgUmVxdWlyZW1lbnRzIA0KIA0KU3Rh dHVzIG9mIHRoaXMgTWVtbyANCiAgICANCiAgIFRoaXMgZG9jdW1lbnQgaXMgYW4gSW50ZXJuZXQt RHJhZnQgYW5kIGlzIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCANCiAgIGFsbCBwcm92aXNpb25z IG9mIFNlY3Rpb24gMTAgb2YgUkZDMjAyNiBbMV0uICANCiAgICANCiAgIEludGVybmV0LURyYWZ0 cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nIA0KICAg VGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5v dGUgdGhhdCAgICAgIA0KICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2lu ZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtDQogICBEcmFmdHMuIA0KICAgIA0KICAgSW50ZXJuZXQt RHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9u dGhzIA0KICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90 aGVyIGRvY3VtZW50cyBhdCBhbnkgDQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1 c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZSANCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUg dGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiIgDQogICAgDQogICBUaGUgbGlz dCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQgDQogICAgICAg IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dCANCiAgIFRoZSBsaXN0 IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQg DQogICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuIA0KIA0KICAgIA0KQWJz dHJhY3QgDQogICAgDQogICBUaGUgaW5jcmVhc2luZyBpbXBvcnRhbmNlIG9mIG1lc3NhZ2luZyBh cyBhIHBvdGVudGlhbCBzb3VyY2Ugb2YgDQogICByZXZlbnVlIGZvciBtb2JpbGUgbmV0d29ya3Mg aGFzIGxlZCBvcGVyYXRvcnMgdG8gYnVpbGQgb3IgcHJvY3VyZSANCiAgIG1vYmlsZSBtZXNzYWdp bmcgc29sdXRpb25zLiAgU29tZSBvcGVyYXRvcnMgaGF2ZSBidWlsdCBtb2JpbGUgDQogICBtZXNz YWdpbmcgc29sdXRpb25zIHVzaW5nIElFVEYgc3RhbmRhcmRzIChJTUFQLCBTTVRQLCBNSU1FKS4g IEFub3RoZXIgDQogICBzb2x1dGlvbiBoYXMgYmVlbiBkZXZlbG9wZWQgYnkgY29uc2Vuc3VzIGlu IHRoZSAzR1BQIGFuZCBPTUEgZ3JvdXBzLCANCiAgIGJhc2VkIG9uIE1JTUUsIEhUVFAgbWV0aG9k cyBhbmQgV0FQIFBVU0gsIHdoaWNoIGhhcyBiZWVuIGRlcGxveWVkIGJ5IA0KICAgbWFueSBvcGVy YXRvcnMuICANCiANCiAgIFRoaXMgZG9jdW1lbnQgcHJlc2VudHMgYSB0YXhvbm9teSBvZiBtZXNz YWdpbmcgYXJjaGl0ZWN0dXJlIA0KICAgY29tcG9uZW50cyBhbmQgbW9kZWxzLCBwcm92aWRpbmcg YSBjb21wYXJpc29uIG9mIHRoZWlyIGZlYXR1cmUgc2V0cy4gIA0KICAgSXQgYWxzbyBpZGVudGlm aWVzIHRoZSBjb21tb25hbGl0aWVzIG9mIHRoZXNlIG1vYmlsZSBtZXNzYWdpbmcgDQogICBzb2x1 dGlvbnMgYW5kIGFic3RyYWN0cyBmcm9tIHRoZXNlIGEgc2V0IG9mIG1vYmlsZSBtZXNzYWdpbmcg DQogICByZXF1aXJlbWVudHMuIA0KICAgIA0KICAgVGhlIGluZm9ybWF0aW9uIGlzIHByb3ZpZGVk IHRvIGluZm9ybSBhbmQgZW5jb3VyYWdlIGZ1dHVyZSBkaXNjdXNzaW9uIA0KICAgb2YgYW5kIGlt cHJvdmVtZW50cyB0byBJbnRlcm5ldCBtZXNzYWdpbmcgaW4gb3JkZXIgdG8gaW5jcmVhc2UgdGhl aXIgDQogICBhcHBsaWNhYmlsaXR5IHRvIG1vYmlsZSBtZXNzYWdpbmcgc3lzdGVtcy4gDQogDQog DQogDQpTdGViYmVucyAmIFJvc2VsaW5za3kgIEV4cGlyZXMgLSBTZXB0ZW1iZXIgMjAwMyAgICAg ICAgICAgICAgIFtQYWdlIDFdIA0KDCAgICAgICAgICAgIE1vYmlsZSBNZXNzYWdpbmcgQXJjaGl0 ZWN0dXJlcyAmIFJlcXVpcmVtZW50cyAgTWFyY2ggMjAwMyANCiANCiANCiAgICANCiAgICANCkNv bnZlbnRpb25zIHVzZWQgaW4gdGhpcyBkb2N1bWVudCANCiAgICANCiAgIEluIGV4YW1wbGVzLCAi QzoiIGFuZCAiUzoiIGluZGljYXRlIGxpbmVzIHNlbnQgYnkgdGhlIGNsaWVudCBhbmQgDQogICBz ZXJ2ZXIgcmVzcGVjdGl2ZWx5LiANCiAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1Qi LCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwgDQogICAiU0hPVUxEIiwgIlNIT1VM RCBOT1QiLCAiUkVDT01NRU5ERUQiLCAgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMgDQog ICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFJGQy0yMTE5 IFsyXS4gDQogICAgDQpUYWJsZSBvZiBDb250ZW50cyANCiAgICANCiAgIDEuIEludHJvZHVjdGlv bi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjIgDQog ICAyLiBDb21wb25lbnRzIGFuZCBNb2RlbHMgb2YgTW9iaWxlIE1lc3NhZ2luZy4uLi4uLi4uLi4u Li4uLi4uLi4uLi4zIA0KICAgICAgMi4xIE1vYmlsZSBNZXNzYWdpbmcgQ29tcG9uZW50cy4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMyANCiAgICAgIDIuMiBNb2JpbGUgTWVzc2FnaW5n IFRyYW5zYWN0aW9uIE1vZGVscy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjMgDQogICAgICAyLjMg TW9iaWxlIE1lc3NhZ2luZyBUcmFuc2FjdGlvbnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li40IA0KICAgICAgMi40IFN1Ym1pc3Npb24uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uNCANCiAgICAgIDIuNSBOb3RpZmljYXRpb24uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjUgDQogICAgICAyLjYgUmV0cmlldmFs Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi42IA0KICAg My4gTW9iaWxlIE1lc3NhZ2luZyBBcmNoaXRlY3R1cmVzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uNiANCiAgICAgIDMuMSBTaG9ydCBNZXNzYWdlIFNlcnZpY2UgKFNNUykuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjcgDQogICAgICAzLjIgTW9iaXRleC4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi43IA0KICAgICAgMy4zIEV4 dGVuZGVkIE1lc3NhZ2luZyBTZXJ2aWNlIChFTVMpLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u OCANCiAgICAgIDMuNCBXZWIvV0FQLWJhc2VkIE1lc3NhZ2luZy4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLjggDQogICAgICAzLjUgTW9iaWxlIE1lc3NhZ2luZyBCYXNlZCBvbiBJ TUFQNCBhbmQgU01UUC4uLi4uLi4uLi4uLi4uLi4uLi45IA0KICAgICAgMy42IE1NUyBNZXNzYWdp bmcuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMCANCiAgIDQu IE1lc3NhZ2luZyBDYWxsIEZsb3dzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uMTEgDQogICA1LiBBbmFseXNpcyBvZiBNb2JpbGUgTWVzc2FnaW5nIFJlcXVpcmVtZW50 cy4uLi4uLi4uLi4uLi4uLi4uLi4uLjEyIA0KICAgICAgNS4xIE1vYmlsZSBNZXNzYWdpbmcgUmVx dWlyZW1lbnRzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMiANCiAgIDYuIFNlY3VyaXR5 IENvbnNpZGVyYXRpb25zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTMg DQogICA3LiBSZWZlcmVuY2VzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLjEzIA0KICAgOC4gQWNrbm93bGVkZ21lbnRzLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xNSANCiAgIDkuIEF1dGhvcidzIEFkZHJlc3Nl cy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTUgDQogICAgDQoN Cg0KMS4gSW50cm9kdWN0aW9uIA0KDQogICBNZXNzYWdpbmcgaGFzIHByb3ZlbiB0byBiZSBhbiBp bXBvcnRhbnQgYXBwbGljYXRpb24sIGRldmVsb3BlZCBhbmQgDQogICBleHRlbnNpdmVseSB1c2Vk IGZvciBtb3JlIHRoYW4gYSBkZWNhZGUgb3ZlciB3aXJlIGxpbmUgbmV0d29ya3MuICANCiAgIE92 ZXIgdGhlIGxhc3QgZmV3IHllYXJzLCBtZXNzYWdpbmcgYXBwbGljYXRpb25zIGhhdmUgYWxzbyBi ZWVuIA0KICAgZGVwbG95ZWQgYWNyb3NzIHdpcmVsZXNzIG5ldHdvcmtzIHdvcmxkd2lkZS4gIElu aXRpYWxseSwgdGhlIG1vYmlsZSANCiAgIG1lc3NhZ2luZyBmYWNpbGl0aWVzIHdlcmUgc2ltcGxl OiB0ZXh0LWJhc2VkIGFuZCBwZXJzb24tdG8tcGVyc29uIChvciANCiAgIGRldmljZS10by1kZXZp Y2UpLiAgQ29ycmVzcG9uZGluZ2x5LCB0aGUgbWVjaGFuaXNtcyB1c2VkIHRvIHRyYW5zcG9ydCAN CiAgIHRoZSBzaW1wbGUgdGV4dC1iYXNlZCBtZXNzYWdlcyB3ZXJlIGFsc28gc2ltcGxlLiAgIA0K ICAgIA0KICAgU3Vic2VxdWVudGx5LCBhZGRpdGlvbmFsIGZlYXR1cmVzIGhhdmUgYmVlbiBhZGRl ZCB0byB0aGUgbW9iaWxlIA0KICAgbWVzc2FnaW5nIHNlcnZpY2VzLCByZXN1bHRpbmcgaW4gcmlj aCBtdWx0aW1lZGlhIHNlcnZpY2VzIHdpdGggbWFueSANCiANCiANClN0ZWJiZW5zICYgUm9zZWxp bnNreSAgRXhwaXJlcyAtIFNlcHRlbWJlciAyMDAzICAgICAgICAgICAgICAgW1BhZ2UgMl0gDQoM ICAgICAgICAgICAgTW9iaWxlIE1lc3NhZ2luZyBBcmNoaXRlY3R1cmVzICYgUmVxdWlyZW1lbnRz ICBNYXJjaCAyMDAzIA0KIA0KIA0KICAgZmVhdHVyZXMuICBQaG90byBtZXNzYWdpbmcgc2Vydmlj ZXMsIGZvciBleGFtcGxlLCBmaXJzdCBhcHBlYXJlZCBpbiANCiAgIEphcGFuIGluIDIwMDAgKGJh c2VkIG9uIElNQVA0IFszXSksIHRoZW4sIGluIDIwMDIsIGluIEV1cm9wZSBhbmQgaW4gDQogICB0 aGUgQW1lcmljYXMgKGJhc2VkIG9uIE9NQSBNTVMgWzRdKS4gICANCiAgICANCiAgIFRoZXNlIHJp Y2ggbXVsdGltZWRpYSBtb2JpbGUgbWVzc2FnaW5nIHNlcnZpY2VzIGhhdmUgcmVxdWlyZWQgcmlj aGVyIA0KICAgbWVzc2FnaW5nIHRyYW5zcG9ydCBwcm90b2NvbHMgd2hpY2ggYXJlIGNhcGFibGUg b2YgdHJhbnNwb3J0aW5nIGFuZCANCiAgIG1hbmFnaW5nIHRoZSB2YXJpZWQgbXVsdGltZWRpYSBv YmplY3RzLCBhcyB3ZWxsIGFzIHByb3ZpZGluZyB0aGUgDQogICBhcHByb3ByaWF0ZSBtZXNzYWdp bmcgc2VtYW50aWNzLiAgSU1BUDQsIHdpdGggaXRzIHJpY2ggbWVzc2FnaW5nIA0KICAgZmVhdHVy ZSBzZXQsIGhhcyBiZWVuIHVzZWQgYXMgdGhlIG1lc3NhZ2UgdHJhbnNwb3J0IHByb3RvY29sIGlu IA0KICAgc2V2ZXJhbCBtb2JpbGUgbWVzc2FnaW5nIGFyY2hpdGVjdHVyZXMuICBPTUEgTU1TIGhh cyBiZWVuIGRldmVsb3BlZCANCiAgIGJ5IDNHUFAoWzVdLFs2XSkgYW5kIE9NQSB0byBwcm92aWRl IGZvciBzb21lIG9mIHRoZSBtb2JpbGUgbWVzc2FnaW5nIA0KICAgc2VydmljZSBmdW5jdGlvbnMs IGFuZCBpcyB3aWRlbHkgc3VwcG9ydGVkIGJ5IG1vYmlsZSB2ZW5kb3JzIGFuZCANCiAgIHRoZWly IG9wZXJhdG9yLWN1c3RvbWVycy4gDQoNCg0KMi4gQ29tcG9uZW50cyBhbmQgTW9kZWxzIG9mIE1v YmlsZSBNZXNzYWdpbmcgDQoNCiAgIEZyb20gYSBzdXJ2ZXkgb2YgZXhpc3RpbmcgbWVzc2FnaW5n IGFyY2hpdGVjdHVyZXMsIHRoZXJlIGFyZSBpcyBhIA0KICAgY29tbW9uIGNsaWVudCBzZXJ2ZXIg YXJjaGl0ZWN0dXJlIHdpdGggbW9iaWxlIGNsaWVudHMgYW5kIG9wZXJhdG9yIA0KICAgc2VydmVy cy4gIFRoaXMgYXJjaGl0ZWN0dXJlIGlzIGRpZmZlcmVudGlhdGVkIGJ5IHdoZXRoZXIgdGhlIGNs aWVudHMgDQogICBoYXZlIHB1c2ggbW9kZWwgb3IgcHVsbCBtb2RlbCB0cmFuc2FjdGlvbnMgYmV0 d2VlbiB0aGVtLiAgDQoNCjIuMSBNb2JpbGUgTWVzc2FnaW5nIENvbXBvbmVudHMgDQoNCiAgIFRo ZSBjbGllbnQsIGFsc28ga25vd24gYXMgYSAidXNlciBhZ2VudCIsIHByZXNlbnRzIG1lc3NhZ2Vz IHRvIGFuZCANCiAgIGFjY2VwdHMgbWVzc2FnZXMgZnJvbSB0aGUgdXNlciwgYW5kIHBlcmZvcm1z IG1lc3NhZ2luZyBmdW5jdGlvbnMgb24gDQogICBiZWhhbGYgb2YgdGhlIHVzZXIsIHNvbWV0aW1l cyBhdXRvbWF0aWNhbGx5LCBzb21ldGltZXMgd2l0aCANCiAgIGludGVycm9nYXRpb24gb2YgdGhl IHVzZXIuIA0KICAgIA0KICAgVGhlIHNlcnZlciwgYWxzbyBrbm93biBhcyBhICJyZWxheS9zZXJ2 ZXIiIG9yIGEgInByb3h5LXJlbGF5IiwgDQogICBnZW5lcmFsbHkgcmVzaWRlcyBpbiB0aGUgb3Bl cmF0b3IncyBuZXR3b3JrIGFuZCBtYW5hZ2VzIG1lc3NhZ2VzIG9uIA0KICAgYmVoYWxmIG9mIHNv bWUgb3IgYWxsIG9mIHRoZSBvcGVyYXRvcidzIHN1YnNjcmliZXJzLiAgSXQgYWNjZXB0cyANCiAg IGNvbm5lY3Rpb25zIGZyb20gY2xpZW50cywgdHlwaWNhbGx5IGF1dGhlbnRpY2F0ZWQsIHBlcmZv cm1zIHJlcXVlc3RlZCANCiAgIGZ1bmN0aW9ucywgYW5kLCBpbXBvcnRhbnRseSwgZ2VuZXJhdGVz IGJpbGxpbmcgcmVjb3JkcyBhcHByb3ByaWF0ZSB0byANCiAgIHRoZSByZXF1ZXN0ZWQgZnVuY3Rp b24uICBUaGUgc2VydmVyIGFsc28gcHJvdmlkZXMgc3RvcmFnZSBvZiB0aGUgDQogICBtZXNzYWdl IGZvciBzb21lIGxlbmd0aCBvZiB0aW1lIChkZXBlbmRpbmcgb24gc2VydmljZSBkZWZpbml0aW9u KS4gDQoNCjIuMiBNb2JpbGUgTWVzc2FnaW5nIFRyYW5zYWN0aW9uIE1vZGVscyAgDQoNCiAgIEFz IHN0YXRlZCBhYm92ZSwgdGhlcmUgYXJlIHR3byBiYXNpYyB0cmFuc2FjdGlvbmFsIG1vZGVscy4g IFRoZSANCiAgICJwdWxsIiBtb2RlbCBpcyB3aGVyZSB0aGUgY29tcG9uZW50IHdpdGggdGhlIG1l c3NhZ2UgZGF0YSBpbml0aWF0ZXMgDQogICB0aGUgdHJhbnNhY3Rpb24uICBGb3IgZXhhbXBsZSBh IGNsaWVudCBtYXkgaW5pdGlhdGUgYSBjb25uZWN0aW9uIHRvIGEgDQogICBzZXJ2ZXIgYW5kIGlz c3VlIHJlcXVlc3RzIHRvIHRoZSBzZXJ2ZXIgdG8gZGlzY292ZXIgYW5kIHJldHJpZXZlIA0KICAg bWVzc2FnZXMgYXMgYXBwcm9wcmlhdGUuICBDb252ZW50aW9uYWwgZS1tYWlsIGNsaWVudHMsIHdl Yi1tYWlsIA0KICAgY2xpZW50cywgYW5kIFdBUC1iYXNlZCBtb2JpbGUgY2xpZW50cyB1c2UgdGhl ICJwdWxsIiBtb2RlbC4gICANCiANCiAgIFRoZSAicHVzaCIgbW9kZWwgaXMgd2hlcmUgdGhlIGNv bXBvbmVudCB0aGF0IHdpc2hlcyB0byBvcGVyYXRlIG9uIHRoZSANCiAgIGRhdGEgaW5pdGlhdGVz IHRoZSB0cmFuc2FjdGlvbi4gIEZvciBleGFtcGxlLCBpdCBpcyBjb21tb24gdGhhdCB0aGUgDQoN CiANCiANClN0ZWJiZW5zICYgUm9zZWxpbnNreSAgRXhwaXJlcyAtIFNlcHRlbWJlciAyMDAzICAg ICAgICAgICAgICAgW1BhZ2UgM10gDQoMICAgICAgICAgICAgTW9iaWxlIE1lc3NhZ2luZyBBcmNo aXRlY3R1cmVzICYgUmVxdWlyZW1lbnRzICBNYXJjaCAyMDAzIA0KIA0KIA0KICAgYXJyaXZhbCBv ZiBhIG5ldyBtZXNzYWdlIGF0IHRoZSB0ZXJtaW5hdGluZyBzZXJ2ZXIgY2F1c2VzIGEgDQogICBu b3RpZmljYXRpb24gdG8gYmUgc2VudCAoInB1c2hlZCIpIHRvIGEgbWVzc2FnaW5nIGNsaWVudC4g IA0KICAgIA0KICAgVGhlIHB1c2ggbW9kZWwgaGFzIHRoZSBhZHZhbnRhZ2Ugb2YgYmVpbmcgZXZl bnQgb3IgbWVzc2FnZSBkcml2ZW4uICANCiAgIFVzZXIgaW50ZXJhY3Rpb24gb25seSBvY2N1cnMg d2hlbiBtZXNzYWdlIGRhdGEgaXMgYXZhaWxhYmxlLiAgVW5saWtlIA0KICAgdGhlIHB1bGwgbW9k ZWwgd2hlcmUgdGhlIHVzZXIgbXVzdCBwb2xsIGZvciBuZXcgbWVzc2FnZSBkYXRhIChvciANCiAg IGNvbmZpZ3VyZSB0aGVpciBjbGllbnQgdG8gcG9sbCBmb3IgdGhlbSkuIA0KDQoyLjMgTW9iaWxl IE1lc3NhZ2luZyBUcmFuc2FjdGlvbnMgDQoNCiAgIFRoZSBtb3N0IGNvbW1vbiBmdW5jdGlvbnMg YXJlOiAic3VibWlzc2lvbiIsICJub3RpZmljYXRpb24iLCBhbmQgDQogICAicmV0cmlldmFsIi4g IFRoZXJlIG1heSBiZSBvdGhlciBmdW5jdGlvbnMsIHN1Y2ggYXMgImRlbGl2ZXJ5IA0KICAgcmVw b3J0cyIsICJyZWFkLXJlcGx5IHJlcG9ydHMiLCAiZm9yd2FyZGluZyIsICJ2aWV3IG1haWxib3gi LCAic3RvcmUgDQogICBtZXNzYWdlIiwgZXRjLiAgRWFjaCBvZiB0aGVzZSB0cmFuc2FjdGlvbnMg Y2FuIGJlIGltcGxlbWVudGVkIGluIA0KICAgZWl0aGVyIGEgcHVsbCBvciBwdXNoIG1vZGVsLiAg SG93ZXZlciwgc29tZSB0cmFuc2FjdGlvbnMgYXJlIG1vcmUgDQogICBuYXR1cmFsbHkgc3VpdGVk IHRvIG9uZSBtb2RlbCBvciBhbm90aGVyLiANCiAgICANCiAgIFRoZSBmb2xsb3dpbmcgRmlndXJl IDEgaXMgYSBzaW1wbGUgZGVwaWN0aW9uIG9mIHRoZSBiYXNpYyBtZXNzYWdpbmcgDQogICBtb2Rl bDogDQogICAgDQogICAoMSkgTWVzc2FnZSBzdWJtaXNzaW9uIA0KICAgKDIpIE1lc3NhZ2Ugbm90 aWZpY2F0aW9uIA0KICAgKDMpIE1lc3NhZ2UgcmV0cmlldmFsICANCiAgICANCiAgICANCiAgICAg Ky0tLS0tLS0rICAgICAgICAgICAgICAgICArLS0tLS0tKyAgICAgICAgICAgICAgICAgICAgICAg Ky0tLS0tLS0rIA0KICAgICB8TW9iaWxlIHwtLS0tLS0tKDEpLS0tLS0tPnwgICAgICB8LS0tLS0t LS0tLS0oMiktLS0tLS0tLT58TW9iaWxlIHwgDQogICAgIHxDbGllbnQgfCAgIFN1Ym1pdCBtc2cg ICAgfCAgICAgIHwgICAgIE5vdGlmaWNhdGlvbiAgICAgL3xDbGllbnQgfCANCiAgICAgKy0tLS0t LS0rICAgICAgICAgICAgICAgICB8ICAgICAgfCAgICAgICAgICAgICAgICAgICAgIC8gKy0tKy0t LS0rIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICB8ICAgICAgICAgICAg ICAgICAgICAvICAgICBeIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICB8 PC0tLS0tLS0tLS0oMyktLS0tLSsgICAgIC8gDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfFNlcnZlcnwgICBSZXRyaWV2YWwgcmVxdWVzdCAgICAvIA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAvIA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICB8ICAgICAgICAgICAgICAgICAgICAgIC8gDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgIHwtLS0tLS0tLS0tLSg0KS0tLS0t LS0rIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICB8ICAgUmV0cmlldmFs IHJlc3BvbnNlIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICB8ICANCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tKyANCiAgICAgICAgICAgICAgICAg ICAgRmlndXJlIDEgLSBCYXNpYyBNZXNzYWdpbmcgTW9kZWwgDQoNCjIuNCBTdWJtaXNzaW9uIA0K DQogICBUaGUgInN1Ym1pc3Npb24iIHRyYW5zYWN0aW9uIGlzIHRoZSB0cmFuc2FjdGlvbiBiZXR3 ZWVuIGEgY2xpZW50IGFuZCANCiAgIGEgc2VydmVyIGJ5IHdoaWNoIHRoZSB1c2VyIG9mIHRoZSBm b3JtZXIgY2FuIHNlbmRzIGEgbmV3IG1lc3NhZ2UgdG8gDQogICBhbm90aGVyIHVzZXIuIA0KICAg IA0KDQoNCiANCiANClN0ZWJiZW5zICYgUm9zZWxpbnNreSAgRXhwaXJlcyAtIFNlcHRlbWJlciAy MDAzICAgICAgICAgICAgICAgW1BhZ2UgNF0gDQoMICAgICAgICAgICAgTW9iaWxlIE1lc3NhZ2lu ZyBBcmNoaXRlY3R1cmVzICYgUmVxdWlyZW1lbnRzICBNYXJjaCAyMDAzIA0KIA0KIA0KICAgVGhp cyB0cmFuc2FjdGlvbiBpcyBtb3N0IGNvbW1vbmx5IGltcGxlbWVudGVkIGluIHRoZSBwdXNoIG1v ZGVsLiAgVGhlIA0KICAgd2hlbiB0aGUgdXNlciBoYXMgY29tcG9zZWQgYSBtZXNzYWdlLCB0aGUg dXNlciBkaXJlY3RzIHRoZSBjbGllbnQgdG8gDQogICBpbml0aWF0ZSBhIGNvbm5lY3Rpb24gdG8g dGhlIHNlcnZlciBhbmQgcHVzaCB0aGUgbWVzc2FnZSB1cCB0byB0aGUgDQogICBzZXJ2ZXIuIA0K ICAgIA0KICAgSW4gYSBwdWxsIG1vZGVsIGltcGxlbWVudGF0aW9uLCB0aGUgc2VydmVyIHdvdWxk IGNvbm5lY3QgdG8gdGhlIA0KICAgY2xpZW50IGZyb20gdGltZSB0byB0aW1lIGFuZCBxdWVyeSBm b3IgdGhlIHByZXNlbmNlIG9mIG5ldyBtZXNzYWdlcyANCiAgIHRvIHNlbmQuICBJbiBwcmFjdGlj ZSwgdGhpcyBpcyBuZXZlciBkb25lLiANCg0KMi41IE5vdGlmaWNhdGlvbiANCg0KICAgVGhlICJu b3RpZmljYXRpb24iIHRyYW5zYWN0aW9uIGlzIHRoZSB0cmFuc2FjdGlvbiBieSB3aXRoIHRoZSBz ZXJ2ZXIgDQogICBub3RpZmllcyB0aGUgY2xpZW50IHRoYXQgaXQgaGFzIHJlY2VpdmVkIG1lc3Nh Z2VzIGludGVuZGVkIGZvciB0aGF0IA0KICAgY2xpZW50LiANCiAgICANCiAgIFRoaXMgdHJhbnNh Y3Rpb24gaXMgYWxzbyBtb3N0IGNvbW1vbmx5IGltcGxlbWVudGVkIGFzIGEgcHVzaCANCiAgIHRy YW5zYWN0aW9uLiAgSW4gdGhpcyBtb2RlbCwgdGhlIHNlcnZlciB3aWxsIGluaXRpYXRlIGEgY29u bmVjdGlvbiB0byANCiAgIHRoZSBjbGllbnQgYW5kIHNlbmQgZGF0YSB0byB0aGUgY2xpZW50IGlu ZGljYXRpbmcgdGhhdCBuZXcgbWVzc2FnZSANCiAgIGRhdGEgaXMgYXZhaWxhYmxlIGZvciB0aGUg Y2xpZW50LiAgU01TIFs3XSwgYnkgdmlydHVlIG9mIGFscmVhZHkgDQogICBiZWluZyB3aWRlbHkg YXZhaWxhYmxlLCBoYXMgYmVjb21lIHRoZSB1YmlxdWl0b3VzIHByb3RvY29sIHRoYXQgDQogICBw cm92aWRlcyBmb3IgYSBiYXNpYyBub3RpZmljYXRpb24gc2VydmljZS4gIEdpdmVuIHRoYXQgU01T IHBhY2tldHMgDQogICBhcmUgbGltaXRlZCBpbiBzaXplLCB0aGUgcHJldmFsZW50IHVzZSBvZiBT TVMgaXMgdG8gc2VuZCBhIHN1bW1hcnkgb2YgDQogICBtdWx0aW1lZGlhIG1lc3NhZ2VzLCBpbmNs dWRpbmcgYSByZWZlcmVuY2UsIGluIHRoZSBub3RpZmljYXRpb24gDQogICBtZXNzYWdlLiAgIA0K ICAgIA0KICAgVGhlIFdBUCBGb3J1bSwgbm93IHBhcnQgb2YgdGhlIE9wZW4gTW9iaWxlIEFsbGlh bmNlIChPTUEpLCBwdWJsaXNoZWQgDQogICBhIGZsZXhpYmxlICJQdXNoIEFyY2hpdGVjdHVyZSIg KFdBUCBQdXNoIFs4XSwgUEFQIFs5XSksIHdpdGggd2hpY2ggDQogICBzZXJ2aWNlcyBjYW4gaGF2 ZSBtZXNzYWdlcyBwdXNoZWQgdG8gbW9iaWxlIGRldmljZXMsIGVpdGhlciBvdmVyIEhUVFAgDQog ICBbMTBdIG9yIFNNUy4gIFRoZXJlIGlzIHNvbWUgdGFsayBvZiBhZGFwdGluZyB0aGUgUHVzaCBQ cm94eS1HYXRld2F5IA0KICAgWzExXSB0byB1c2UgU0lQIE5PVElGWSBmb3Igbm90aWZpY2F0aW9u IHRyYW5zcG9ydCwgYnV0IHRoaXMsIHRvbywgaXMgDQogICBzdGlsbCB3b3JrLWluLXByb2dyZXNz LiANCiAgICANCiAgIFJlZ2FyZGxlc3Mgb2YgdGhlIGFjdHVhbCB0cmFuc3BvcnQgbWV0aG9kLCB0 aGUgZXNzZW50aWFsIGluZ3JlZGllbnQgDQogICB0byBhbGwgb2YgdGhlbSBpcyB0aGF0IGVpdGhl ciB0aGUgbWVzc2FnZSBpdHNlbGYgKGlmIGl0IGEgc2hvcnQgb25lKSANCiAgIG9yIGEgc3VtbWFy eSBvZiBhbmQgcmVmZXJlbmNlIHRvIHRoZSBtZXNzYWdlIG11c3QgYmUgc2VudCB0byB0aGUgDQog ICBjbGllbnQuICBJbiB0aGUgY2FzZSBvZiBhIHNob3J0IG1lc3NhZ2UgYmVpbmcgc2VudCB2aWEg YSANCiAgIG5vdGlmaWNhdGlvbiwgdGhlIGNsaWVudCBjYW4gdGhlbiBwcmVzZW50IGl0IHRvIHRo ZSB1c2VyLiAgSW4gdGhlIA0KICAgY2FzZSBvZiBhIGxvbmcgbWVzc2FnZSwgdGhlIGNsaWVudCBj YW4gZWl0aGVyIHRoZW4gcHJlc2VudCBhIHN1bW1hcnkgDQogICBvZiB0aGUgbWVzc2FnZSwgb3Is IGJ5IHVzaW5nIHRoZSBtZXNzYWdlIHJlZmVyZW5jZSwgcmV0cmlldmUgDQogICBhZGRpdGlvbmFs IGluZm9ybWF0aW9uIGFib3V0IHRoZSBtZXNzYWdlLCBvciBldmVuIHRoZSBjb21wbGV0ZSANCiAg IG1lc3NhZ2UsIGFuZCBwcmVzZW50IGl0IGFwcHJvcHJpYXRlbHkgdG8gdGhlIHVzZXIuIA0KICAg IA0KICAgVGhlIHNpZ25pZmljYW50IGFkdmFudGFnZSBvZiB0aGUgcHVzaCBtb2RlbCBub3RpZmlj YXRpb25zIGlzIHRoYXQgDQogICBkYXRhIGlzIHByZXNlbnRlZCB0byB0aGUgdXNlciB3aXRob3V0 IHRoZSB1c2VyIG5lZWRpbmcgdG8gYmUgYXdhcmUgb2YgDQogICBuZXR3b3JrL3RyYW5zcG9ydCBs YXRlbmNpZXMsIGFuZCB3aXRob3V0IHR5aW5nIHVwIG5ldHdvcmsgcmVzb3VyY2VzIA0KICAgZm9y IHBvbGxpbmcgd2hlbiB0aGVyZSBpcyBubyBuZXcgZGF0YS4gIEFsbCBvZiB0aGUgbGFyZ2VyIG1v YmlsZSANCiAgIG1lc3NhZ2luZyBzeXN0ZW1zIGltcGxlbWVudCBhIHB1c2ggbW9kZWwgZm9yIHRo ZSBub3RpZmljYXRpb24gDQogICB0cmFuc2FjdGlvbi4gDQogICAgDQogDQogDQpTdGViYmVucyAm IFJvc2VsaW5za3kgIEV4cGlyZXMgLSBTZXB0ZW1iZXIgMjAwMyAgICAgICAgICAgICAgIFtQYWdl IDVdIA0KDCAgICAgICAgICAgIE1vYmlsZSBNZXNzYWdpbmcgQXJjaGl0ZWN0dXJlcyAmIFJlcXVp cmVtZW50cyAgTWFyY2ggMjAwMyANCiANCiANCiAgIFRoZSAicHVsbCIgbW9kZWwgb2YgUEMtYmFz ZWQgb3IgV0FQLWJhc2VkIG1vYmlsZSBlLW1haWwgY2xpZW50cyBoYXMgDQogICBub3QgcmVxdWly ZWQgYSBub3RpZmljYXRpb24gbWV0aG9kIHBlci1zZS4gIFdoZW4gYSBuZXcgbWVzc2FnZSANCiAg IGFycml2ZXMgYXQgdGhlIHNlcnZlciwgdGhlIGNsaWVudCBsZWFybnMgb2YgaXQgb25seSB3aGVu IGl0IG5leHQgDQogICBpbml0aWF0ZXMgYSBjb25uZWN0aW9uIHRvIHRoZSBzZXJ2ZXIgYW5kIHJl cXVlc3RzIGEgbGlzdCBvZiBtZXNzYWdlcyANCiAgIChvciwgbW9yZSBvcHRpbWFsbHksIGEgbGlz dCBvZiBuZXcgbWVzc2FnZSkuICBDbGllbnRzIGNhbiBiZSANCiAgIGNvbmZpZ3VyZWQgdG8gYXV0 b21hdGljYWxseSBjb25uZWN0IHRvIHRoZSBzZXJ2ZXIgYW5kIGRldGVybWluZSANCiAgIHdoZXRo ZXIgb3Igbm90IG5ldyBtZXNzYWdlcyBhcmUgYXZhaWxhYmxlLCBhbmQgbm90aWZ5IHRoZSB1c2Vy IGFzIA0KICAgZGVzaXJlZC4gIFRoaXMgaGFzIGJlZW4gY29tcGxldGVseSBhY2NlcHRhYmxlIHRv IHRoZSBjbGllbnQgY29tbXVuaXR5IA0KICAgYW5kIHNvLCB0aGVyZSBoYXMgYmVlbiBubyBwcm90 b2NvbCBkZXZlbG9wbWVudCBpbiB0aGlzIGFyZWEuIA0KIA0KICAgVGhlcmUgaGFzIGJlZW4gcmVj ZW50IHdvcmsgdG8gZGVmaW5lICJlLW1haWwgbm90aWZpY2F0aW9uIiBtZXRob2RzIA0KICAgU0lQ LU1XSSBbMTJdLCBFTU4gWzEzXSwgU05BUCBbMTRdLCBidXQgdGhlc2UgYXJlIHN0aWxsIHdvcmtz LWluLQ0KICAgcHJvZ3Jlc3MuIA0KDQoyLjYgUmV0cmlldmFsIA0KDQogICBUaGUgInJldHJpZXZh bCIgdHJhbnNhY3Rpb24gaXMgdGhlIHRyYW5zYWN0aW9uIGJldHdlZW4gYSBjbGllbnQgYW5kIGEg DQogICBzZXJ2ZXIgYnkgd2hpY2ggdGhlIGNsaWVudCBjYW4gb2J0YWluIG9uZSBvciBtb3JlIG1l c3NhZ2VzIGZyb20gdGhlIA0KICAgc2VydmVyLiANCiANCiAgIEluIGEgcHVzaCBtb2RlbCBpbXBs ZW1lbnRhdGlvbiwgdGhlIHNlcnZlciB3aWxsIGluaXRpYXRlIGEgY29ubmVjdGlvbiANCiAgIHRv IHRoZSBjbGllbnQgYW5kIHB1c2ggdGhlIG1lc3NhZ2UgZGF0YSB0byB0aGUgY2xpZW50LiAgVGhp cyBpcyBkb25lIA0KICAgaW4gT01BIFs0XSBpbiAiSW1tZWRpYXRlIE1vZGUuIiAgVGhlIGFkdmFu dGFnZSBvZiB0aGlzIGlzIHRoYXQgdGhlIA0KICAgdXNlciBpcyBub3QgbmVjZXNzYXJpbHkgYXdh cmUgb2YgdHJhbnNwb3J0IG9yIG5ldHdvcmsgbGF0ZW5jaWVzLiAgVGhlIA0KICAgZGlzYWR2YW50 YWdlIGlzIHRoYXQgdGhlIGNsaWVudCBtYXkgbm90IGJlIGFibGUgdG8gc3RvcmUgdGhlIG1lc3Nh Z2UgDQogICBkdWUgdG8gc2l6ZSBjb25zdHJhaW50cy4gDQogICAgDQogICBJbiBhIHB1bGwgbW9k ZWwgaW1wbGVtZW50YXRpb24sIHRoZSBjbGllbnQgd2lsbCBpbml0aWF0ZSBhIGNvbm5lY3Rpb24g DQogICB0byB0aGUgc2VydmVyIGFuZCByZXRyaWV2ZSB0aGUgbWVzc2FnZSBmcm9tIHRoZSBzZXJ2 ZXIuICBPZnRlbiB0aGUgDQogICBjbGllbnQgd2lsbCBmaXJzdCByZXRyaWV2ZSBpbmZvcm1hdGlv biBhYm91dCB0aGUgbWVzc2FnZSAoZS5nLiBJTUFQNCANCiAgIEJPRFlTVFJVQ1RVUkUgWzNdKSwg YW5kIGFsbG93IHRoZSB1c2VyIHRvIHNlbGVjdGl2ZWx5IGRvd25sb2FkIHRoZSANCiAgIG1lc3Nh Z2UgZnJvbSB0aGUgc2VydmVyIHRvIHRoZSBjbGllbnQuICBUaGUgYWR2YW50YWdlIG9mIHRoaXMg bWV0aG9kIA0KICAgaXMgdGhhdCB0aGUgdXNlciBjYW4gY29udHJvbCB3aGF0IGRhdGEgaXMgYWN0 dWFsbHkgc2VudCB0byBhbmQgc3RvcmVkIA0KICAgYnkgdGhlIGNsaWVudC4gDQogICAgDQogICBJ biBib3RoIGltcGxlbWVudGF0aW9ucyAocHVzaCBvciBwdWxsKSB0aGUgc2VydmVyIGNhbiBiZSBj b25maWd1cmVkIA0KICAgdG8ga2VlcCBhIGNvcHkgb2YgdGhlIG1lc3NhZ2UgZGF0YSBpbiBzZXJ2 ZXItbWFuYWdlZCBzdG9yYWdlLiAgVGhpcyANCiAgIGlzIGNvbnNpZGVyZWQgdmVyeSB2YWx1YWJs ZSBieSBtYW55IHVzZXJzLiAgVGhlIHNlcnZlci1tYW5hZ2VkIA0KICAgbWVzc2FnZSBkYXRhIGlz IGF2YWlsYWJsZSBmb3Igb3RoZXIgb3BlcmF0aW9ucyB3aXRob3V0IHJlcXVpcmluZyANCiAgIHVw bG9hZCBmcm9tIHRoZSBjbGllbnQuICBGb3IgZXhhbXBsZSwgaXQgY2FuIGJlIHJlZmVyZW5jZWQg YW5kIA0KICAgZm9yd2FyZGVkIGFzIHBhcnQgb2YgYW5vdGhlciBtZXNzYWdlLCBvciBpdCBtYXkg YmUgdmlld2VkIGZyb20gDQogICBhbm90aGVyIGNsaWVudCwgd2hldGhlciBtb2JpbGUgb3IgZml4 ZWQuIA0KDQoNCjMuIE1vYmlsZSBNZXNzYWdpbmcgQXJjaGl0ZWN0dXJlcyANCg0KICAgQWx0aG91 Z2ggbWFueSBvZiB0aGUgdHJhbnNwb3J0IHByb3RvY29scyBhbmQgaW50ZXJmYWNlcyBoYXZlIGJl ZW4gDQogICBzdGFuZGFyZGl6ZWQsIG1vYmlsZSBvcGVyYXRvcnMgY29tcGV0ZSB3aXRoIGhvdyB0 aGV5IGNvbWJpbmUgdGhlIA0KICAgc3RhbmRhcmQgcHJvdG9jb2xzIGFuZCBpbnRlcmZhY2VzIGlu dG8gYW4gaW5ub3ZhdGl2ZSwgY29tcHJlaGVuc2l2ZSANCiANCiANClN0ZWJiZW5zICYgUm9zZWxp bnNreSAgRXhwaXJlcyAtIFNlcHRlbWJlciAyMDAzICAgICAgICAgICAgICAgW1BhZ2UgNl0gDQoM ICAgICAgICAgICAgTW9iaWxlIE1lc3NhZ2luZyBBcmNoaXRlY3R1cmVzICYgUmVxdWlyZW1lbnRz ICBNYXJjaCAyMDAzIA0KIA0KIA0KICAgbWVzc2FnaW5nIGFyY2hpdGVjdHVyZSB0aGF0IGZ1bGZp bGxzIHRoZWlyIHNlcnZpY2UgcmVxdWlyZW1lbnRzLiAgVGhlIA0KICAgZm9sbG93aW5nIHNlY3Rp b25zIGFyZSBhIGJyaWVmIHN1cnZleSBvZiBzZXZlcmFsIG1vYmlsZSBtZXNzYWdpbmcgDQogICBh cmNoaXRlY3R1cmVzLCB0aGVpciBmZWF0dXJlcywgYW5kIHRoZWlyIHByb2JsZW1zLiANCg0KMy4x IFNob3J0IE1lc3NhZ2UgU2VydmljZSAoU01TKSANCg0KICAgVGhlIFNob3J0IE1lc3NhZ2UgU2Vy dmljZSAoU01TKSBhbGxvd3MgdGhlIGV4Y2hhbmdlIG9mIHNob3J0IHRleHQtDQogICBvbmx5IG1l c3NhZ2VzIG9uIG1vYmlsZSB0ZWxlcGhvbmUgbmV0d29ya3MuICBTTVMgZW1lcmdlZCBpbiB0aGUg ZWFybHkgDQogICAxOTkwcyBhbmQgYnkgMjAwMSBoYWQgYmVjb21lIGEgdmVyeSBwb3B1bGFyIGNv bnN1bWVyLW9yaWVudGVkIA0KICAgbWVzc2FnaW5nIHNlcnZpY2UsIHdoZW4gdXNlcnMgZXhjaGFu Z2VkIG1vcmUgdGhhbiAxMDAgYmlsbGlvbiANCiAgIG1lc3NhZ2VzLiANCiAgICANCiAgIFNNUyB3 YXMgb3JpZ2luYWxseSBzdGFuZGFyZGl6ZWQgYXMgcGFydCBvZiB0aGUgR1NNIHBoYXNlIDEgRVRT SSANCiAgIHRlY2huaWNhbCBzcGVjaWZpY2F0aW9ucy4gIA0KIA0KICAgRmVhdHVyZXM6ICANCiAg ICAgLiBzaG9ydC1tZXNzYWdlcyBvZiBsZXNzIHRoYW4gMTQwIG9jdGV0cyANCiAgICAgLiBFLjE2 NC1iYXNlZFsxNV0gb3IgInNob3J0IGNvZGUiIGFkZHJlc3NpbmcgDQogICAgIC4gVGV4dCBvbmx5 IA0KICAgICAuIENsaWVudCBwcmVzZW50YXRpb24gaXMgZWFzeSAoYmVjYXVzZSB0ZXh0LW9ubHkp IA0KICAgICAuIEZpcnN0IG92ZXItdGhlLWFpciBpbW1lZGlhdGUgbWVzc2FnaW5nIHByb3RvY29s IA0KICAgICAuIEFkZGl0aW9uYWwgZnVuY3Rpb25zIChDQU5DRUwsIFJFUExBQ0UpIHRvIHN1cHBv cnQgY29udGVudC0NCiAgICAgICAgcHJvdmlkZXJzIChWQVNQcykgDQogICAgIC4gQXZhaWxhYmxl IG9uIGFsbW9zdCBldmVyeSBoYW5kc2V0OiBURE1BLCBDRE1BLCBHU00sIEdQUlMgDQogICAgDQog ICBQcm9ibGVtczogDQogICAgIC4gUmVxdWlyZXMgZXhwZW5zaXZlIFNTN1sxNl0gbmV0d29yayBp bnRlcmZhY2UgDQogICAgIC4gRWFjaCBTTVMgZGF0YSBwYWNrZXQgcmVxdWlyZXMgU1M3IHNpZ25h bGluZywgd2hpY2ggaXMgYWxzbyB1c2VkIA0KICAgICAgICBmb3Igdm9pY2Ugc2lnbmFsaW5nIA0K ICAgICAuIE5vIG5ldHdvcmsgbWFpbGJveCBzdXBwb3J0IA0KICAgICAuIE5vIHN0YW5kYXJkIElu dGVybmV0IGludGVyd29ya2luZyAoZS1tYWlsIGdhdGV3YXlzIGV4aXN0IGJ1dCBhcmUgDQogICAg ICAgIGFkLWhvYyBvciBjb21tZXJjaWFsIHByb2R1Y3RzKSANCiAgICAgLiBSZXF1aXJlcyBzcGVj aWFsaXplZCBoYXJkd2FyZSBzeXN0ZW1zIGNhbGxlZCBTTVNDcyANCiAgICAgLiBUaGVyZSBhcmUg c2V2ZXJhbCAic3RhbmRhcmQiIGludGVyZmFjZXMgZm9yIGludGVyLVNNU0NzLCANCiAgICAgICAg Y3JlYXRpbmcgdGhlIG5lZWQgZm9yIGludGVyLVNNU0Mgc3dpdGNoZXMgIA0KDQozLjIgTW9iaXRl eCANCg0KICAgTW9iaXRleCBpcyBhIHByb3ByaWV0YXJ5IHNlcnZpY2UsIGNyZWF0ZWQgYnkgRXJp Y3Nzb24sIHRoYXQgaXMgYSANCiAgIHBhY2tldC1zd2l0Y2hlZCwgbmFycm93YmFuZCBQQ1MgbmV0 d29yaywgZGVzaWduZWQgZm9yIHdpZGUtYXJlYSANCiAgIHdpcmVsZXNzIGRhdGEgY29tbXVuaWNh dGlvbnMuIE1vYml0ZXggbmV0d29ya3Mgb2ZmZXIgYSB2YXJpZXR5IG9mIA0KICAgcGFnaW5nIHNv bHV0aW9ucywgdGhlIG1vc3QgYWR2YW5jZWQgb2Ygd2hpY2ggaXMgY2FsbGVkICJpbnRlcmFjdGl2 ZSANCiAgIHBhZ2luZyIsIGEgMiB3YXkgdGV4dCBtZXNzYWdpbmcgc29sdXRpb24uIA0KICAgIA0K ICAgRmVhdHVyZXM6IA0KICAgICAuIFNob3J0LW1lc3NhZ2VzIG9mIGxlc3MgdGhhbiA1MDAgb2N0 ZXRzIA0KICAgICAuIERldmljZSBhZGRyZXNzaW5nIG9ubHkgDQogICAgIC4gVGV4dC1vbmx5IA0K ICAgICAuIFRyYW5zcG9ydCBzdXBwb3J0cyBzdWJtaXQsIGRlbGl2ZXJ5LCAmIHJlYWQgcmVwb3J0 cyANCiANCiANClN0ZWJiZW5zICYgUm9zZWxpbnNreSAgRXhwaXJlcyAtIFNlcHRlbWJlciAyMDAz ICAgICAgICAgICAgICAgW1BhZ2UgN10gDQoMICAgICAgICAgICAgTW9iaWxlIE1lc3NhZ2luZyBB cmNoaXRlY3R1cmVzICYgUmVxdWlyZW1lbnRzICBNYXJjaCAyMDAzIA0KIA0KIA0KICAgIA0KICAg UHJvYmxlbXM6IA0KICAgICAuIFByb3ByaWV0YXJ5IEVyaWNzc29uIG5ldHdvcmsgKGJhc2VkIG9u IFguMjUgWzE3XSkgDQogICAgIC4gRGV2aWNlIGFkZHJlc3Npbmcgb25seSANCiAgICAgLiBObyBu ZXR3b3JrIG1haWxib3ggc3VwcG9ydCANCiAgICAgLiBMaW1pdGVkIGNsaWVudCBhdmFpbGFiaWxp dHkgDQogICAgIC4gTm8gc3RhbmRhcmQgSW50ZXJuZXQgaW50ZXJ3b3JraW5nIGludGVyZmFjZSAN Cg0KMy4zIEV4dGVuZGVkIE1lc3NhZ2luZyBTZXJ2aWNlIChFTVMpIA0KDQogICBUaGUgRXh0ZW5k ZWQgTWVzc2FnaW5nIFNlcnZpY2UgKEVNUyBbMThdKSBpcyBhbiBlbmhhbmNlbWVudCB0byB0aGUg DQogICBTTVMgc2VydmljZSB0aGF0IGVuYWJsZXMgdGhlIGV4Y2hhbmdlIG9mIG11bHRpbWVkaWEg bWVzc2FnZXMuICBFTVMgDQogICB1dGlsaXplcyB0aGUgc2FtZSBuZXR3b3JrIGluZnJhc3RydWN0 dXJlIGFzIFNNUyBbN10uIA0KICAgIA0KICAgRmVhdHVyZXM6ICANCiAgICAgLiBMb25nIG1lc3Nh Z2VzIHNlbnQgdmlhIGNvbmNhdGVuYXRlZCBTTVMgcGFja2V0cyANCiAgICAgLiBFLjE2NC1iYXNl ZCBbMTVdIG9yICJzaG9ydCBjb2RlIiBhZGRyZXNzaW5nIA0KICAgICAuIFRleHQsIGJpdC1tYXAg aW1hZ2VzLCBhbmQgdmVjdG9yIGdyYXBoaWNzIA0KICAgIA0KICAgUHJvYmxlbXM6IA0KICAgICAu IFJlcXVpcmVzIGV4cGVuc2l2ZSBTUzcgWzE2XSBuZXR3b3JrIGludGVyZmFjZSANCiAgICAgLiBF YWNoIEVNUyAicGFja2V0IiBpcyBvbmUgb3IgbW9yZSBTTVMgZGF0YSBwYWNrZXRzLCBlYWNoIG9m IHdoaWNoIA0KICAgICAgICByZXF1aXJlcyBTUzcgc2lnbmFsaW5nIHRoYXQgaXMgYWxzbyB1c2Vk IGZvciB2b2ljZSBzaWduYWxpbmcgDQogICAgIC4gTm8gbmV0d29yayBtYWlsYm94IHN0b3JhZ2Ug DQogICAgIC4gTm8gc3RhbmRhcmQgaW50ZXJ3b3JraW5nIHdpdGggSW50ZXJuZXQgZS1tYWlsIHN5 c3RlbXMgDQogICAgIC4gQ2xpZW50IHByZXNlbnRhdGlvbiBvZiBtZWRpYSBsZXNzIHNpbXBsZSAN CiAgICAgLiBObyBjYXBhYmlsaXR5IGRpc2NvdmVyeSBvciBjb250ZW50IG5lZ290aWF0aW9uIGJl dHdlZW4gRU1TIA0KICAgICAgICBkZXZpY2VzICh3aGF0IGhhcHBlbnMgaWYgYSBiaXRtYXAgaW1h Z2UgaXMgc2VudCB0byBhbm90aGVyIA0KICAgICAgICBhZGRyZXNzIHRoYXQgZG9lcyBub3Qgc3Vw cG9ydCB0aGF0IGltYWdlIHR5cGU/KSANCiAgICAgLiBSZXF1aXJlcyBzcGVjaWFsaXplZCBoYXJk d2FyZSBzeXN0ZW1zIGNhbGxlZCBFTVNDcyAodXBncmFkZWQgDQogICAgICAgIFNNU0NzKSANCiAg ICAgLiBFTVNDcyBjb250aW51ZSB0aGUgbmVlZCBmb3IgU01TQy9FTVNDIHN3aXRjaGVzIA0KDQoz LjQgV2ViL1dBUC1iYXNlZCBNZXNzYWdpbmcgDQoNCiAgIFBlcmhhcHMgdGhlIGZpcnN0IGFyY2hp dGVjdHVyZSByZWFsaXplZCBmb3IgbW9iaWxlIG1lc3NhZ2luZyB0aGF0IA0KICAgYWxsb3dlZCBm b3IgdGhlIHBvc3NpYmlsaXR5IG9mIHByZXNlbnRpbmcgYSB1bmlmaWVkIGludGVyZmFjZSBmb3Ig DQogICBtdWx0aW1lZGlhIG1lc3NhZ2VzIHdhcyB0aGUgV0FQLWJhc2VkIG1vYmlsZSBlLW1haWwg c2VydmljZS4gDQogICAgDQogICBGZWF0dXJlczogDQogICAgIC4gTGV2ZXJhZ2VzIHViaXF1aXRv dXMgSFRUUCBbMTBdIGFzIHRyYW5zcG9ydCANCiAgICAgLiBSRkMyODIyIGFkZHJlc3NpbmcgWzIw XSANCiAgICAgLiBMYXJnZSBhbmQgbXVsdGltZWRpYSBtZXNzYWdlIHN1cHBvcnQgDQogICAgIC4g Q2xpZW50IGNhcGFiaWxpdHkgZGlzY292ZXJ5IGFuZCBjb250ZW50IGFkYXB0YXRpb24gYmFzZWQg b24gDQogICAgICAgIFVTRVJBR0VOVCBzdHJpbmcgWzEwXSANCiAgICAgLiBDYW4gc3VwcG9ydCBk ZWxpdmVyeSBhbmQgcmVhZCByZXBvcnRzIChzZXJ2ZXItYmFzZWQpIA0KICAgICAuIE1haWxib3gg ZnVuY3Rpb25zIGZ1bGx5IHN1cHBvcnRlZCANCiAgICAgLiBDbGllbnQgcmVxdWlyZXMgb25seSBh IFdBUCBicm93c2VyIA0KICAgICAuIE1lc3NhZ2UgdHJhbnNwb3J0ZWQgdmlhIElQIG5ldHdvcmss IHVzaW5nIEludGVybmV0IHByb3RvY29scyANCiANCiANClN0ZWJiZW5zICYgUm9zZWxpbnNreSAg RXhwaXJlcyAtIFNlcHRlbWJlciAyMDAzICAgICAgICAgICAgICAgW1BhZ2UgOF0gDQoMICAgICAg ICAgICAgTW9iaWxlIE1lc3NhZ2luZyBBcmNoaXRlY3R1cmVzICYgUmVxdWlyZW1lbnRzICBNYXJj aCAyMDAzIA0KIA0KIA0KICAgICAuIEludGVyb3BlcmF0ZXMgd2l0aCBJbnRlcm5ldCBlLW1haWwg c3lzdGVtcyANCiAgICANCiAgIFByb2JsZW1zOiANCiAgICAgLiBObyBFLjE2NCBbN10gb3IgInNo b3J0IGNvZGUiIGFkZHJlc3NpbmcsIGV4Y2VwdCBwb3NzaWJseSBmb3IgDQogICAgICAgIG9ubHkg dGhlIG1vYmlsZSBvcGVyYXRvcidzIG5ldHdvcmsgDQogICAgIC4gUmVxdWlyZXMgbmV0d29yayBj b25uZWN0aXZpdHkgZm9yIGFsbCBvcGVyYXRpb25zLCBldmVuIG1lc3NhZ2UgDQogICAgICAgIGNv bXBvc2l0aW9uIA0KICAgICAuIFVzZXIgdHlwaWNhbGx5IGV4cG9zZWQgdG8gdGhlIG5ldHdvcmsg bGF0ZW5jaWVzIChlLmcuLCBubyANCiAgICAgICAgImJhY2tncm91bmQiIHN1Ym1pc3Npb24gb3Ig cmV0cmlldmFsKSANCiAgICAgLiBTZXJ2ZXItYmFzZWQgbWVzc2FnZSBjb21wb3NpdGlvbiBub3Qg aW50ZWdyYXRlZCB3aXRoIGNsaWVudCANCiAgICAgICAgYWRkcmVzcyBib29rIA0KICAgICAuIE5v IG5vdGlmaWNhdGlvbnMgb2YgbmV3bHkgYXJyaXZlZCBtZXNzYWdlcyAtIHVzZXIgb3IgY2xpZW50 IG11c3QgDQogICAgICAgIHJlcXVlc3QgbmV3IG1lc3NhZ2VzIA0KICAgICAuIE1vYmlsZSByYWRp byBhY2Nlc3MgYmlsbGluZyBub3QgbmVjZXNzYXJpbHkgaW50ZWdyYXRlZCB3aXRoIA0KICAgICAg ICBtZXNzYWdlIHNlcnZpY2UgYmlsbGluZyANCiAgICANCiAgIEl0IGlzIGludGVyZXN0aW5nIHRv IG5vdGUgdGhhdCBvbmUgb2YgdGhlIG1ham9yIGNvbXBsYWludHMgd2l0aCANCiAgIG1vYmlsZSB3 ZWIgbWFpbCBzZXJ2aWNlcyB3YXMgbmV0d29yayBsYXRlbmNpZXMsIHdoaWNoIGlzIGEgDQogICBj b25zZXF1ZW5jZSBvZiB0aGUgZGVzaWduIG9mIHRoZSByZWxhdGl2ZWx5IHN0YXRlbGVzcywgYnJv d3Nlci1iYXNlZCANCiAgIGNsaWVudCwgYW5kIG5vdCBuZWNlc3NhcmlseSBhIGNvbnNlcXVlbmNl IG9mIHVzaW5nIFdTUCBhbmQvb3IgSFRUUC4gDQoNCjMuNSBNb2JpbGUgTWVzc2FnaW5nIEJhc2Vk IG9uIElNQVA0IGFuZCBTTVRQIA0KDQogICBTZXZlcmFsIG1vYmlsZSBvcGVyYXRvcnMgaGF2ZSBi dWlsdCBhIG1vYmlsZSBtZXNzYWdpbmcgYXJjaGl0ZWN0dXJlIA0KICAgYmFzZWQgb24gSUVURiBt ZXNzYWdpbmcgcHJvdG9jb2xzOiBTTVRQIFsxOV0sIElNQVA0IFszXSwgYW5kIHVzZWQgDQogICBT TVNbN10gZm9yIHRoZWlyIG5vdGlmaWNhdGlvbiBwcm90b2NvbC4gIFRvZGF5LCB0aGVzZSBvcGVy YXRvcnMgaGF2ZSANCiAgIHByb3Zlbiwgc3VjY2Vzc2Z1bCwgcmV2ZW51ZS1nZW5lcmF0aW5nIG11 bHRpbWVkaWEgbWVzc2FnaW5nIHNlcnZpY2VzLiANCiAgICANCiAgIEZlYXR1cmVzOiANCiAgICAg LiBSRkMyODIyIFsyMF0gYW5kIEUuMTY0IFsxNV0gYWRkcmVzc2luZywgaW5jbHVkaW5nICJzaG9y dCBjb2RlcyIgDQogICAgIC4gTGFyZ2UgYW5kIG11bHRpbWVkaWEgbWVzc2FnZSBzdXBwb3J0LCBN SU1FIFsyMV0gZW5jYXBzdWxhdGlvbiANCiAgICAgLiBDYW4gc3VwcG9ydCBkZWxpdmVyeSByZXBv cnRzIChEU05zIFsyMl0pIGFuZCByZWFkIHJlcG9ydHMgKE1ETnMgDQogICAgICAgIFsyM10pIA0K ICAgICAuIE1lc3NhZ2VzIHN1Ym1pdHRlZCwgcmV0cmlldmVkLCBhbmQgZm9yd2FyZGVkIHZpYSBJ UCBuZXR3b3JrLCANCiAgICAgICAgdXNpbmcgSW50ZXJuZXQgcHJvdG9jb2xzIA0KICAgICAuIFdp ZGUgaW50ZXJvcGVyYWJpbGl0eSB3aXRoIEludGVybmV0IGUtbWFpbCBzeXN0ZW1zLiANCiAgICAg LiBOb3RpZmljYXRpb25zIHZpYSBXQVAgUHVzaCBvciBTTVMgDQogICAgIC4gQ29tcGxldGUgbWFp bGJveCBzdXBwb3J0IGF2YWlsYWJsZSBub3cgDQogICAgIC4gQ2xpZW50IGFuZCBzZXJ2ZXIgZGV2 ZWxvcGVycyBoYXZlIHJlYWR5IGFjY2VzcyB0byB3aWRlbHkgDQogICAgICAgIGRlcGxveWVkIHBy b3RvY29sIGRldmVsb3BtZW50IGtpdHMsIHRlc3QgdG9vbHMsIGV0Yy4gDQogICAgIC4gQmlsbGlu ZyBjYW4gYmUgYmFzZWQgb24gZWl0aGVyIHBlci1tZXNzYWdlIG9yIHBlci1ieXRlIA0KICAgICAu IFBlcnNpc3RlbnQgc3RvcmFnZSBtb2RlbCBzdXBwb3J0ZWQgDQogICAgIC4gQXV0aGVudGljYXRp b24gY2FuIGJlIG5ldHdvcmstYmFzZWQgb3IgYXBwbGljYXRpb24tYmFzZWQgDQogICAgDQogICBQ cm9ibGVtczogDQogICAgIC4gSU1BUDQgdG9vICJjaGF0dHkiOyBvcGVyYXRvcnMgaGF2ZSBtYWRl IHByb3ByaWV0YXJ5IGFkYXB0YXRpb25zIA0KICAgICAgICB0byBhdm9pZCB0aGlzLiANCiAgICAg LiBNZXNzYWdlcyBhcmUgYmFzZTY0IGVuY29kZWQsIGV4cGFuZGluZyB0aGUgcGF5bG9hZC4gDQog ICAgIC4gTm90aWZpY2F0aW9uIG1ldGhvZHMgbm90IHN0YW5kYXJkaXplZC4gDQogDQogDQpTdGVi YmVucyAmIFJvc2VsaW5za3kgIEV4cGlyZXMgLSBTZXB0ZW1iZXIgMjAwMyAgICAgICAgICAgICAg IFtQYWdlIDldIA0KDCAgICAgICAgICAgIE1vYmlsZSBNZXNzYWdpbmcgQXJjaGl0ZWN0dXJlcyAm IFJlcXVpcmVtZW50cyAgTWFyY2ggMjAwMyANCiANCiANCiAgICAgLiBObyBjbGllbnQgY2FwYWJp bGl0eSBkaXNjb3Zlcnkgb3IgZXhjaGFuZ2UgDQogICAgIC4gTm8gY29udGVudCBhZGFwdGF0aW9u IA0KICAgICAuIE5vIGNvbnRlbnQgcHJvdGVjdGlvbiBtZWNoYW5pc21zIGN1cnJlbnRseSANCg0K My42IE1NUyBNZXNzYWdpbmcgDQoNCiAgIFRoZSAzR1BQIFQyIGFuZCBPTUEgTUFHIE1NUyBncm91 cHMgZGV2ZWxvcGVkIHRoZSBNdWx0aW1lZGlhIE1lc3NhZ2luZyANCiAgIFNlcnZpY2UgKE1NUykg c3BlY2lmaWNhdGlvbnMgaW5kZXBlbmRlbnRseSAoWzVdLCBbNl0pLCBiYXNlZCBvbiBuZXcgDQog ICBIVFRQIFsxMF0gbWV0aG9kcyBhbmQgV0FQIFB1c2ggKFsyNF0sIFsyNV0pLiANCiAgICANCiAg IFRoZSBNTVMgU3VibWlzc2lvbiBhbmQgUmV0cmlldmFsIG1ldGhvZHMgYXJlIGZ1bGZpbGxlZCB3 aXRoIEhUVFAgDQogICBtZXRob2RzLiAgVGhlIE1NUyBOb3RpZmljYXRpb24gaXMgYmFzZWQgb24g dGhlIFdBUCBQdXNoIGFyY2hpdGVjdHVyZSwgDQogICB3aGljaCBjYW4gZGVsaXZlcnkgcHVzaCBt ZXNzYWdlcyBvdmVyIEhUVFAgb3Igb3ZlciBTTVMgWzddLiANCiAgICANCiAgIEZlYXR1cmVzOiAN CiAgICAgLiBSRkMyODIyIGFuZCBFLjE2NCBhZGRyZXNzaW5nLCBpbmNsdWRpbmcgInNob3J0IGNv ZGVzIiANCiAgICAgLiBMYXJnZSBhbmQgbXVsdGltZWRpYSBtZXNzYWdlIHN1cHBvcnQsIE1JTUUg ZW5jYXBzdWxhdGlvbiANCiAgICAgLiBEZWxpdmVyeSByZXBvcnRzIGFuZCByZWFkIHJlcG9ydHMg c3VwcG9ydGVkIA0KICAgICAuIENsaWVudCBjYXBhYmlsaXR5IGRpc2NvdmVyeSAodmlhIFVBUFJP RiBbMjZdIG9yIEhUVFAgVVNFUkFHRU5UIA0KICAgICAgICBbMTBdIHN0cmluZ3MpIA0KICAgICAu IENvbnRlbnQgYWRhcHRhdGlvbiBzdXBwb3J0ZWQgDQogICAgIC4gRGVsYXllZCBkZWxpdmVyeSBm ZWF0dXJlIHN1cHBvcnRlZCANCiAgICAgLiBGb3J3YXJkIHdpdGhvdXQgZG93bmxvYWQgDQogICAg IC4gVGlnaHRseSBpbnRlZ3JhdGVkIGJpbGxpbmcsIHN1cHBvcnRpbmcgYm90aCBwcmUtIGFuZCBw b3N0LXBheSANCiAgICAgICAgb3BlcmF0aW9ucyANCiAgICAgLiBTb21lIG1haWxib3ggZnVuY3Rp b25zIHN1cHBvcnRlZCBub3cgDQogICAgIC4gTWVzc2FnZXMgc3VibWl0dGVkLCByZXRyaWV2ZWQs IGFuZCBmb3J3YXJkZWQgdmlhIElQIG5ldHdvcmssIA0KICAgICAgICB1c2luZyBTTVRQIHdpdGgg TU1TIGhlYWRlcnMgDQogICAgIC4gSW50ZXJuZXQgZS1tYWlsIGludGVyd29ya2luZyANCiAgICAg LiBXZWxsLXNwZWNpZmllZCBjb250ZW50IHByb3ZpZGVyIEFQSSB0aGF0IGFsbG93cyBwYXJ0bmVy aW5nIA0KICAgICAgICByZWxhdGlvbnNoaXBzIGJldHdlZW4gY29udGVudCBvd25lcnMgYW5kIG1l c3NhZ2luZyBzZXJ2aWNlIA0KICAgICAgICBwcm92aWRlcnMuIA0KICAgICAuIE5vdGlmaWNhdGlv bnMgdmlhIFdBUCBQdXNoIG9yIFNNUyANCiAgICAgLiBNZXNzYWdlIGlzIGNvbXByZXNzZWQgdG8g c2F2ZSBiYW5kd2lkdGggDQogICAgIC4gV2VsbC1zcGVjaWZpZWQgSU9UIHByb2dyYW0gd2l0aGlu IE9NQSBJT1AgDQogICAgIC4gQXV0aGVudGljYXRpb24gaXMgbmV0d29yay1iYXNlZCANCiAgICAN CiAgIFByb2JsZW1zOiANCiAgICAgLiBEZWxpdmVyeSByZXBvcnRzIGFyZSBub3QgRFNOcyBhbmQg ZG8gbm90IGludGVyb3BlcmF0ZSB3aXRoIFNNVFAgDQogICAgICAgIGUtbWFpbCBzeXN0ZW1zIGlu IGEgc3RhbmRhcmQgZmFzaGlvbiANCiAgICAgLiBSZWFkLXJlcGx5IHJlcG9ydHMgYXJlIG5vdCBN RE5zIGFuZCBkbyBub3QgaW50ZXJvcGVyYXRlIHdpdGggDQogICAgICAgIFNNVFAgZS1tYWlsIHN5 c3RlbXMgaW4gYSBzdGFuZGFyZCBmYXNoaW9uIA0KICAgICAuIFNvbWUgbWFpbGJveCBmdW5jdGlv bnMgbm90IHN1cHBvcnRlZCAoc2VydmVyLWJhc2VkIHNvcnRpbmcsIA0KICAgICAgICBtZXNzYWdl IGZvbGRlcnMpIA0KICAgICAuIE92ZXItdGhlLWFpciB0cmFuc3BvcnQgcHJvdG9jb2xzIG5vdCB3 aWRlbHkgZGVwbG95ZWQ7IGxhY2sgb2YgDQogICAgICAgIGRldmVsb3BtZW50IGtpdHMgYW5kIHRl c3QgdG9vbHMgDQogICAgIC4gQ29udGVudCBwcm90ZWN0aW9uIG1lY2hhbmlzbXMgYXJlIGxpbWl0 ZWQgdG8gYSAiZm9yd2FyZCBsb2NrIiANCiAgICAgICAgKE9NQSBEUk0gaXMgc3RpbGwgYSB3b3Jr LWluLXByb2dyZXNzKSANCg0KIA0KIA0KU3RlYmJlbnMgJiBSb3NlbGluc2t5ICBFeHBpcmVzIC0g U2VwdGVtYmVyIDIwMDMgICAgICAgICAgICAgIFtQYWdlIDEwXSANCgwgICAgICAgICAgICBNb2Jp bGUgTWVzc2FnaW5nIEFyY2hpdGVjdHVyZXMgJiBSZXF1aXJlbWVudHMgIE1hcmNoIDIwMDMgDQog DQogDQo0LiBNZXNzYWdpbmcgQ2FsbCBGbG93cyANCg0KICAgSW4gRmlndXJlIDIgKGJlbG93KSwg dGhlIGJhc2ljIGNhbGwgZmxvd3MgZm9yIHRoZSBJRVRGIG1lc3NhZ2luZyBhbmQgDQogICBNTVMg dGVjaG5vbG9naWVzIGFyZSBkZXBpY3RlZCwgc2ltaWxhciB0byB0aGUgYmFzaWMgbWVzc2FnaW5n IG1vZGVsIA0KICAgZnJvbSBGaWd1cmUgMTogDQogICAgDQogICAoMSkgTWVzc2FnZSBzdWJtaXNz aW9uIChmcm9tIHRoZSBjbGllbnQpIA0KICAgKDIpIE1lc3NhZ2Ugbm90aWZpY2F0aW9uICh0byB0 aGUgY2xpZW50KSANCiAgICgzKSBNZXNzYWdlIHJldHJpZXZhbCByZXF1ZXN0IChmcm9tIHRoZSBj bGllbnQpIA0KICAgKDQpIE1lc3NhZ2UgcmV0cmlldmFsIHJlc3BvbnNlIChkZWxpdmVyIG1zZyB0 byB0aGUgY2xpZW50KSANCiAgICANCiAgICANCiAgICAgKy0tLS0tLS0rICAgICAgICAgICAgICAg ICArLS0tLS0tKyAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0rIA0KICAgICB8TW9iaWxl IHwtLS0tLS0tKDEpLS0tLS0tPnwgICAgICB8LS0tLS0tLS0tLS0oMiktLS0tLS0tLT58TW9iaWxl IHwgDQogICAgIHxDbGllbnQgfCAgIFN1Ym1pdCBtc2cgICAgfCAgICAgIHwgICAgIE5vdGlmaWNh dGlvbiAgICAgL3xDbGllbnQgfCANCiAgICAgKy0tLS0tLS0rICAgICAoU01UUCBvcikgICB8ICAg ICAgfCAgICAgICAgIChTTVMpICAgICAgIC8gKy0tKy0tLS0rIA0KICAgICAgICAgICAgICAgICAo SU1BUCBBUFBFTkQpIHxTTVRQLyB8ICAgICAgICAgICAgICAgICAgICAvICAgICBeIA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHxJTUFQNCB8PC0tLS0tLS0tLS0oMyktLS0tLSsgICAg IC8gDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfFNlcnZlcnwgICBSZXRyaWV2YWwg cmVxdWVzdCAgICAvIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICB8ICAg ICAgICAgKElNQVApICAgICAgICAvIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgIC8gDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCAgICAgIHwtLS0tLS0tLS0tLSg0KS0tLS0tLS0rIA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgICAgICB8ICAgUmV0cmlldmFsIHJlc3BvbnNlIA0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwgICAgICB8ICAgICAgICAgKElNQVApIA0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICstLS0tLS0rIA0KICAgICAgICAgRmlndXJlIDIgLSBNZXNzYWdp bmcgQ2FsbCBGbG93IHdpdGggU01UUCwgU01TLCAmIElNQVAgDQogICAgDQogICAgDQogICAgICst LS0tLS0tKyAgICAgICAgICAgICAgICAgKy0tLS0tLSsgICAgICAgICAgICAgICAgICAgICAgICst LS0tLS0tKyANCiAgICAgfE1vYmlsZSB8LS0tLS0tLSgxKS0tLS0tLT58ICAgICAgfC0tLS0tLS0t LS0tKDIpLS0tLS0tLS0+fE1vYmlsZSB8IA0KICAgICB8Q2xpZW50IHwgICBTdWJtaXQgbXNnICAg IHwgICAgICB8ICAgICBOb3RpZmljYXRpb24gICAgIC98Q2xpZW50IHwgDQogICAgICstLS0tLS0t KyAgICAgKEhUVFApICAgICAgfCAgICAgIHwgICAgICAgICAoU01TKSAgICAgICAvICstLSstLS0t KyANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgfCAgICAgICAgICAgICAg ICAgICAgLyAgICAgXiANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IE1NUyAgfDwt LS0tLS0tLS0tKDMpLS0tLS0rICAgICAvIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHxTZXJ2ZXJ8ICAgUmV0cmlldmFsIHJlcXVlc3QgICAgLyANCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8ICAgICAgfCAgICAgICAgIChIVFRQKSAgICAgICAgLyANCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAvIA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICB8LS0tLS0tLS0tLS0oNCktLS0tLS0t KyANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgfCAgIFJldHJpZXZhbCBy ZXNwb25zZSANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgfCAgICAgICAg IChIVFRQKSANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tKyANCiAgICAg ICAgICBGaWd1cmUgMyAtIE1NUyB3aXRoIHNwZWNpYWxpemVkIEhUVFAgbWV0aG9kcyAmIFNNUy4g DQogICBQbGVhc2Ugbm90ZSB0aGF0IHRoZSBjYWxsIGZsb3dzIGZvciBib3RoIGFyZSBpZGVudGlj YWwgZXhjZXB0IGZvciB0aGUgDQogICBhY3R1YWwgdHJhbnNwb3J0IHByb3RvY29scy4gDQoNCg0K IA0KIA0KU3RlYmJlbnMgJiBSb3NlbGluc2t5ICBFeHBpcmVzIC0gU2VwdGVtYmVyIDIwMDMgICAg ICAgICAgICAgIFtQYWdlIDExXSANCgwgICAgICAgICAgICBNb2JpbGUgTWVzc2FnaW5nIEFyY2hp dGVjdHVyZXMgJiBSZXF1aXJlbWVudHMgIE1hcmNoIDIwMDMgDQogDQogDQo1LiBBbmFseXNpcyBv ZiBNb2JpbGUgTWVzc2FnaW5nIFJlcXVpcmVtZW50cyANCg0KICAgQXMgaWRlbnRpZmllZCBpbiB0 aGUgcHJlY2VkaW5nIGRlc2NyaXB0aW9ucywgbW9kZXJuIG1vYmlsZSBtZXNzYWdpbmcgDQogICBz eXN0ZW1zIGhhdmUgYSBudW1iZXIgb2YgcmVxdWlyZW1lbnRzLiAgU29tZSBvZiB0aGVzZSBkaWZm ZXIgDQogICBzaWduaWZpY2FudGx5IGZyb20gdGhvc2Ugc2VlbiBpbiB0aGUgZGVza3RvcCBvcmll bnRlZCBlbWFpbCBzeXN0ZW1zIA0KICAgZGVwbG95ZWQgaW4gdG9kYXkncyBJbnRlcm5ldC4gICAN CiAgICANCiAgIFRoZSBtb2JpbGUgdXNlciBtYXJrZXRwbGFjZSBpcyB0YXJnZXRlZCBhdCBhIGxh cmdlIGNvbnN1bWVyIGF1ZGllbmNlIA0KICAgYW5kIHJlcXVpcmVzIGEgc2ltcGxlLCBpbW1lZGlh dGUgYW5kIGNvbXBlbGxpbmcgbWVzc2FnaW5nIGV4cGVyaWVuY2UuIA0KICAgIA0KICAgVXNlcnMg b2YgdG9kYXkncyBtb2JpbGUgbWVzc2FnaW5nIHVzZXIgYWdlbnRzIGRlc2lyZSBhIHJpY2ggZW5k IHVzZXIgDQogICBleHBlcmllbmNlIHRoYXQgZmVhdHVyZXMgbXVsdGltZWRpYSBjb250ZW50IHB1 c2hlZCB0byB0aGUgZW5kIHVzZXIgDQogICBkZXZpY2UuICBUaGUgZGV2aWNlcyBhdmFpbGFibGUg dG9kYXkgYXJlIGNvbnN0cmFpbmVkIGFzIHRvIHdoaWNoIA0KICAgbWVkaWEgY29kZWNzIGFyZSBz dXBwb3J0ZWQsIGxpbWl0ZWQgc2NyZWVuIHNpemUsIGxpbWl0ZWQgb3IgZXhwZW5zaXZlIA0KICAg bmV0d29yayBiYW5kd2lkdGguICBUaGUgbW9iaWxlIGRldmljZXMgYXJlIG9mdGVuIHJvYW1pbmcg aW4gYW5kIG91dCANCiAgIG9mIG5ldHdvcmsgY292ZXJhZ2UgYW5kIHRoZSBtZXNzYWdpbmcgc3lz dGVtIG11c3QgdGFrZSB0aGlzIGludG8gDQogICBjb25zaWRlcmF0aW9uLiANCiAgICANCiAgIE1v YmlsZSBuZXR3b3JrIHByb3ZpZGVycyBvZnRlbiBvcGVyYXRlIG9uIGEgInBheSBmb3IgdXNlIiBz ZXJ2aWNlIA0KICAgbW9kZWwuICBUaGlzIGJyaW5ncyBpbiByZXF1aXJlbWVudHMgZm9yIGNsZWFy bHkgZGVsaW5lYXRlZCBzZXJ2aWNlIA0KICAgdHJhbnNhY3Rpb25zIHRoYXQgY2FuIGJlIHJlcG9y dGVkIHRvIGJpbGxpbmcgc3lzdGVtcywgYW5kIGZvciANCiAgIHBvc2l0aXZlIGVuZC10by1lbmQg YWNrbm93bGVkZ2VtZW50IG9mIGRlbGl2ZXJ5IG9yIG5vbi1kZWxpdmVyeSBvZiANCiAgIG1lc3Nh Z2VzLiANCg0KNS4xIE1vYmlsZSBNZXNzYWdpbmcgUmVxdWlyZW1lbnRzIA0KDQogICBUaGUgZm9s bG93aW5nIGFyZSByZXF1aXJlbWVudHMgb2YgYSBzdWNjZXNzZnVsIG1vYmlsZSBtZXNzYWdpbmcg DQogICBvZmZlcmluZzogDQogICAgIC4gUHVzaCBiYXNlZCBub3RpZmljYXRpb25zLiANCiAgICAg LiBEZWxpdmVyeSBtb2RlbCB3aGVyZSBtZXNzYWdlcyAianVzdCBzaG93IHVwIiBvbiB0aGUgZGV2 aWNlICh3aGVuIA0KICAgICAgICBhcHByb3ByaWF0ZSksIGJhc2VkIG9uIHB1c2ggYmFzZWQgbm90 aWZpY2F0aW9uIGFuZCBlbmQtdXNlciANCiAgICAgICAgcHJlZmVyZW5jZSBzZXR0aW5ncy4gIElu IG90aGVyIHdvcmRzLCBoaWRlIG5ldHdvcmsgbGF0ZW5jaWVzIA0KICAgICAgICBmcm9tIHRoZSB1 c2VyLCBhbmQgcmVkdWNlIHVzZXIgaW50ZXJhY3Rpb24gd2l0aCBwcm9maWxlLWJhc2VkIA0KICAg ICAgICBhdXRvbWF0aW9ucy4gDQogICAgIC4gUkZDMjgyMiBhbmQgRS4xNjQgYWRkcmVzc2luZywg aW5jbHVkaW5nICJzaG9ydCBjb2RlcyIgDQogICAgIC4gTGFyZ2UgbWVzc2FnZSBhbmQgbXVsdGlt ZWRpYSBtZXNzYWdlIHN1cHBvcnQsIE1JTUUgZW5jYXBzdWxhdGlvbiANCiAgICAgLiBTdXBwb3J0 IGZvciBlbmQtdG8tZW5kIGRlbGl2ZXJ5IHJlcG9ydHMgYW5kIHJlYWQgcmVwb3J0cyANCiAgICAg LiBDbGllbnQgY2FwYWJpbGl0eSBkaXNjb3ZlcnkvZXhjaGFuZ2UgYW5kIGNvbnRlbnQgYWRhcHRh dGlvbiANCiAgICAgLiBVc2VyIGNvbmZpZ3VyYWJsZSBmaWx0ZXJzIGZvciBzZWxlY3RpdmUgZG93 bmxvYWRpbmcgYW5kIFNQQU0gDQogICAgICAgIGNvbnRyb2wgDQogICAgIC4gTWVzc2FnZSBleGNo YW5nZSB3aXRoIGV4aXN0aW5nIEludGVybmV0IGVtYWlsIHN5c3RlbXMgDQogICAgIC4gTWFpbGJv eCAocGVyc2lzdGVudCBzdG9yYWdlIG1vZGVsKSBzdXBwb3J0IA0KICAgICAuIE5ldHdvcmstYmFz ZWQgYW5kL29yIGFwcGxpY2F0aW9uLWJhc2VkIGF1dGhlbnRpY2F0aW9uIA0KICAgICAuIEJhbmR3 aWR0aCBzYXZpbmcgZmVhdHVyZXMgc3VjaCBhcyBiaW5hcnkgdHJhbnNmZXJzLCBkYXRhIA0KICAg ICAgICBjb21wcmVzc2lvbiwgZm9yd2FyZCB3aXRob3V0IGRvd25sb2FkIGFuZCBzdHJlYW1saW5l ZCBjbGllbnQtDQogICAgICAgIHNlcnZlciBtZXNzYWdlIHN1Ym1pc3Npb24gYW5kIHJldHJpZXZh bCANCg0KDQoNCiANCiANClN0ZWJiZW5zICYgUm9zZWxpbnNreSAgRXhwaXJlcyAtIFNlcHRlbWJl ciAyMDAzICAgICAgICAgICAgICBbUGFnZSAxMl0gDQoMICAgICAgICAgICAgTW9iaWxlIE1lc3Nh Z2luZyBBcmNoaXRlY3R1cmVzICYgUmVxdWlyZW1lbnRzICBNYXJjaCAyMDAzIA0KIA0KIA0KNi4g U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgDQoNCiAgIFRoaXMgZHJhZnQgZGVzY3JpYmVzIG1vYmls ZSBtZXNzYWdpbmcgbmV0d29ya3MgYmFzZWQgb24gSU1BUDQsIFNNVFAgDQogICBhbmQgSFRUUC4g IEFsdGhvdWdoIGFsbCBvZmZlciBhcHBsaWNhdGlvbi1sZXZlbCBhdXRoZW50aWNhdGlvbiwgbWFu eSANCiAgIG1vYmlsZSBvcGVyYXRvcnMgaGF2ZSBkZXBsb3llZCBtb2JpbGUgbWVzc2FnaW5nIHNl cnZpY2VzIG5ldHdvcmstDQogICBiYXNlZCBhdXRoZW50aWNhdGlvbi4gIEluIG90aGVyIHdvcmRz LCB0aGUgc2Vzc2lvbnMgYXJlIGltcGxpY2l0bHkgDQogICBhdXRoZW50aWNhdGVkIGJ5IHRoZSBt b2JpbGUgZGV2aWNlIG5ldHdvcmsgYWNjZXNzIHBhcmFtZXRlcnMuIA0KDQoNCjcuIFJlZmVyZW5j ZXMNCg0KIA0KICAgMSAgQnJhZG5lciwgUy4sICJUaGUgSW50ZXJuZXQgU3RhbmRhcmRzIFByb2Nl c3MgLS0gUmV2aXNpb24gMyIsIEJDUCANCiAgICAgIDksIFJGQyAyMDI2LCBPY3RvYmVyIDE5OTYu IA0KDQogICAyICBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5k aWNhdGUgUmVxdWlyZW1lbnQgDQogICAgICBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJj aCAxOTk3IA0KDQogICAzICBDcmlzcGluLCBNLiwgIkludGVybmV0IE1lc3NhZ2UgQWNjZXNzIFBy b3RvY29sIC0gVmVyc2lvbiA0cmV2MSIsIA0KICAgICAgUkZDIDIwNjAsIFVuaXZlcnNpdHkgb2Yg V2FzaGluZ3RvbiwgRGVjZW1iZXIgMTk5Ni4gDQoNCiAgIDQgIE9wZW4gTW9iaWxlIEFsbGlhbmNl IChPTUEpICJNdWx0aW1lZGlhIE1lc3NhZ2luZyBTZXJ2aWNlOyANCiAgICAgIEFyY2hpdGVjdHVy YWwgT3ZlcnZpZXcgVmVyc2lvbiAxLjEiLCBPTUEsIDIwMDIgDQoNCiAgIDUgIDNHUFAgVFMgMjIu MTQwICJUaGlyZCBHZW5lcmF0aW9uIFBhcnRuZXJzaGlwIFByb2plY3Q7IFRlY2huaWNhbCANCiAg ICAgIFNwZWNpZmljYXRpb24gR3JvdXAgU2VydmljZXMgYW5kIFN5c3RlbSBBc3BlY3RzOyBTZXJ2 aWNlIGFzcGVjdHM7IA0KICAgICAgRnVuY3Rpb25hbCBkZXNjcmlwdGlvbjsgU3RhZ2UgMSBNdWx0 aW1lZGlhIE1lc3NhZ2luZyBTZXJ2aWNlIiwgDQogICAgICAzR1BQLCAyMDAxIA0KDQogICA2ICAz R1BQIFRTIDIzLjE0MCAiVGhpcmQgR2VuZXJhdGlvbiBQYXJ0bmVyc2hpcCBQcm9qZWN0OyBUZWNo bmljYWwgDQogICAgICBTcGVjaWZpY2F0aW9uIEdyb3VwIFRlcm1pbmFsczsgTXVsdGltZWRpYSBN ZXNzYWdpbmcgU2VydmljZSAoTU1TKTsgDQogICAgICBGdW5jdGlvbmFsIGRlc2NyaXB0aW9uOyBT dGFnZSAyIiwgM0dQUCwgMjAwMSANCg0KICAgNyAgQy5TMDAxNS1BOiBTaG9ydCBNZXNzYWdlIFNl cnZpY2UgKFNNUyksIERlY2VtYmVyIDE5OTksIDNHUFAyLiANCg0KICAgOCAgT3BlbiBNb2JpbGUg QWxsaWFuY2UgKE9NQSkgIlB1c2ggQXJjaGl0ZWN0dXJhbCBPdmVydmlldywgIA0KICAgICAgV0FQ LTI1MC1QdXNoQXJjaE92ZXJ2aWV3LTIwMDEwNzAzLWEiLCBPTUEsIDIwMDEgDQoNCiAgIDkgIE9w ZW4gTW9iaWxlIEFsbGlhbmNlIChPTUEpICJQdXNoIEFyY2hpdGVjdHVyYWwgT3ZlcnZpZXcgDQog ICAgICBQdXNoIEFjY2VzcyBQcm90b2NvbCBTcGVjaWZpY2F0aW9uLCBXQVAtMjQ3LVBBUC0yMDAx MDQyOS1hIiwgT01BLCANCiAgICAgIDIwMDEgDQoNCiAgIDEwIEZpZWxkaW5nLCBHZXR0eXMsIEJl cm5lcnMtTGVlLCBldC4gYWwuLCAiSHlwZXJ0ZXh0IFRyYW5zZmVyIA0KICAgICAgUHJvdG9jb2wg LSBIVFRQIDEuMSIsIFJGQyAyNjE2LCBKdW5lIDE5OTkuIA0KDQogICAxMSBPcGVuIE1vYmlsZSBB bGxpYW5jZSAoT01BKSAiUHVzaCBQcm94eSBHYXRld2F5IFNlcnZpY2UgDQogICAgICBTcGVjaWZp Y2F0aW9uIiwgV0FQLTI0OS1QUEdTZXJ2aWNlLTIwMDEwNDI1LnBkZiwgT01BLCAyMDAxICAgDQog DQogDQogDQpTdGViYmVucyAmIFJvc2VsaW5za3kgIEV4cGlyZXMgLSBTZXB0ZW1iZXIgMjAwMyAg ICAgICAgICAgICAgW1BhZ2UgMTNdIA0KDCAgICAgICAgICAgIE1vYmlsZSBNZXNzYWdpbmcgQXJj aGl0ZWN0dXJlcyAmIFJlcXVpcmVtZW50cyAgTWFyY2ggMjAwMyANCiANCiANCiANCiAgIDEyIE1h aHksIFIuICJBIE1lc3NhZ2UgU3VtbWFyeSBhbmQgTWVzc2FnZSBXYWl0aW5nIEluZGljYXRpb24g RXZlbnQgDQogICAgICBQYWNrYWdlIGZvciB0aGUgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29s IChTSVApIiwgZHJhZnQtaWV0Zi0NCiAgICAgIHNpcHBpbmctbXdpLTAxLnR4dCANCg0KICAgMTMg T3BlbiBNb2JpbGUgQWxsaWFuY2UgKE9NQSkgIkUtbWFpbCBOb3RpZmljYXRpb24gVmVyc2lvbiAx LjAiLCBPTUEsIA0KICAgICAgMjAwMiANCg0KICAgMTQgU2hhcGlyYSwgTi4gYW5kIEFsb25pLCBF LiAiU2ltcGxlIE5vdGlmaWNhdGlvbiBhbmQgQWxhcm0gUHJvdG9jb2wgDQogICAgICAoU05BUCki LCBDb212ZXJzZSBUZWNobm9sb2d5LCAyMDAyLiANCg0KICAgMTUgSVRVLVQgUmVjb21tZW5kYXRp b25zIFNlcmllcyBFOiAiRS4xNjQ6IFRoZSBpbnRlcm5hdGlvbmFsIHB1YmxpYyANCiAgICAgIHRl bGVjb21tdW5pY2F0aW9uIG51bWJlcmluZyBwbGFuIjsgSVRVLCBNYXkgMTk5Ny4gIA0KDQogICAx NiBDQ0lUVCBXaGl0ZSBCb29rLCBWb2x1bWUgVkksIEZhc2NpY2xlIFZJLjcsIFJlY29tbWVuZGF0 aW9ucyBRLjcwMC0NCiAgICAgIFEuNzE2OiBTcGVjaWZpY2F0aW9ucyBvZiBTaWduYWxsaW5nIFN5 c3RlbSBOby4gNy4gDQogICAgICAgDQogICAgICBDQ0lUVCBXaGl0ZSBCb29rIFZvbHVtZSBWSSwg RmFzY2ljbGUgVkkuOCwgUmVjb21tZW5kYXRpb25zIFEuNzIxLQ0KICAgICAgUS43NjY6IFNwZWNp ZmljYXRpb25zIG9mIFNpZ25hbGxpbmcgU3lzdGVtIE5vLjcuIA0KICAgICAgIA0KICAgICAgSVRV IFdoaXRlIEJvb2ssIElUVS1UIFJlY29tbWVuZGF0aW9uIFEuNzYzOiBTcGVjaWZpY2F0aW9ucyBv ZiANCiAgICAgIFNpZ25hbGxpbmcgU3lzdGVtIE51bWJlciA3LiAgDQogICAgICAgDQogICAgICBH Ui0yNDYtQ09SRSwgSXNzdWUgMSwgRGVjZW1iZXIgMTk5NDogU3BlY2lmaWNhdGlvbnMgb2YgU2ln bmFsbGluZyANCiAgICAgIFN5c3RlbSBOdW1iZXIgNy4gDQoNCiAgIDE3IElUVS1UIFJlY29tbWVu ZGF0aW9uIFNlcmllcyBYOiBYLjI1OiAiSW50ZXJmYWNlIGJldHdlZW4gRGF0YSANCiAgICAgIFRl cm1pbmFsIEVxdWlwbWVudCAoRFRFKSBhbmQgRGF0YSBDaXJjdWl0LXRlcm1pbmF0aW5nIEVxdWlw bWVudCANCiAgICAgIChEQ0UpIGZvciB0ZXJtaW5hbHMgb3BlcmF0aW5nIGluIHRoZSBwYWNrZXQg bW9kZSBhbmQgY29ubmVjdGVkIHRvIA0KICAgICAgcHVibGljIGRhdGEgbmV0d29ya3MgYnkgZGVk aWNhdGVkIGNpcmN1aXQiLCBJVFUsIE9jdCAxOTk2LiANCg0KICAgMTggUy5SMDA1MS0wIHYxLjAs ICJFbmhhbmNlZCBNZXNzYWdlIFNlcnZpY2UgKEVNUykgU3RhZ2UgMSANCiAgICAgIERlc2NyaXB0 aW9uIiwgM0dQUDIsIEp1bHkgMjAwMS4gDQoNCiAgIDE5IEtsZW5zaW4sIEouICJTaW1wbGUgTWFp bCBUcmFuc2ZlciBQcm90b2NvbCIsIFJGQyAyODIxLCBBcHJpbCAyMDAxLiANCg0KICAgMjAgUmVz bmljaywgUC4gIkludGVybmV0IE1lc3NhZ2UgRm9ybWF0IiwgUkZDIDI4MjIsIEFwcmlsIDIwMDEu ICANCg0KICAgMjEgRnJlZWQsIE4uIGFuZCBCb3JlbnN0ZWluLCBOLiAiTXVsdGlwdXJwb3NlIElu dGVybmV0IE1haWwgDQogICAgICBFeHRlbnNpb25zIChNSU1FKSBQYXJ0IFR3bzogTWVkaWEgVHlw ZXMiLCBSRkMgMjA0NiwgTm92ZW1iZXIgMTk5Ni4gDQoNCiAgIDIyIE1vb3JlLCBLLiAiU01UUCBT ZXJ2aWNlIEV4dGVuc2lvbiBmb3IgRGVsaXZlcnkgU3RhdHVzIA0KICAgICAgTm90aWZpY2F0aW9u cyIsIFJGQyAxODkxLCBKYW51YXJ5IDE5OTYuIA0KDQogICAyMyBSLiBGYWptYW4sICJBbiBFeHRl bnNpYmxlIE1lc3NhZ2UgRm9ybWF0IGZvciBNZXNzYWdlIERpc3Bvc2l0aW9uIA0KICAgICAgTm90 aWZpY2F0aW9ucyIsIFJGQyAyMjk4LCBNYXJjaCAxOTk4LiANCg0KIA0KIA0KIA0KU3RlYmJlbnMg JiBSb3NlbGluc2t5ICBFeHBpcmVzIC0gU2VwdGVtYmVyIDIwMDMgICAgICAgICAgICAgIFtQYWdl IDE0XSANCgwgICAgICAgICAgICBNb2JpbGUgTWVzc2FnaW5nIEFyY2hpdGVjdHVyZXMgJiBSZXF1 aXJlbWVudHMgIE1hcmNoIDIwMDMgDQogDQogDQogDQogICAyNCBPcGVuIE1vYmlsZSBBbGxpYW5j ZSAoT01BKSAiTXVsdGltZWRpYSBNZXNzYWdpbmcgU2VydmljZTsgQ2xpZW50IA0KICAgICAgVHJh bnNhY3Rpb25zIFZlcnNpb24gMS4xIiwgT01BLU1NUy12MV8xLCBPTUEsIDIwMDIgDQoNCiAgIDI1 IE9wZW4gTW9iaWxlIEFsbGlhbmNlIChPTUEpICJNdWx0aW1lZGlhIE1lc3NhZ2luZyBTZXJ2aWNl OyANCiAgICAgIEVuY2Fwc3VsYXRpb24gUHJvdG9jb2wgVmVyc2lvbiAxLjEiLCBPTUEtTU1TLXYx XzEsIE9NQSwgMjAwMiANCg0KICAgMjYgT3BlbiBNb2JpbGUgQWxsaWFuY2UgKE9NQSkgIlVzZXIg QWdlbnQgUHJvZmlsZSwgVmVyc2lvbiAxLjEiLCBPTUEtDQogICAgICBVQVBST0YtdjFfMSwgT01B LCBEZWNlbWJlciAyMDAyLiANCg0KDQoNCjguIEFja25vd2xlZGdtZW50cyANCg0KICAgQmVuamFt aW4gRWxsc3dvcnRoLCANCiAgIE9wZW53YXZlIFN5c3RlbXMsIEluYy4gDQogICA1MzAgRS4gTW9u dGVjaXRvIFN0LiwgU2FudGEgQmFyYmFyYSwgQ0EgOTMxMDMgDQogICBQaG9uZTogODA1LTg4NC0z MTUzIA0KICAgRW1haWw6IGJlbmphbWluLmVsbHN3b3J0aEBvcGVud2F2ZS5jb20gDQoNCg0KOS4g QXV0aG9yJ3MgQWRkcmVzc2VzIA0KDQogICAgDQogICBBbGFuIEsuIFN0ZWJiZW5zIA0KICAgT3Bl bndhdmUgU3lzdGVtcywgSW5jLiANCiAgIDUzMCBFLiBNb250ZWNpdG8gU3QuLCBTYW50YSBCYXJi YXJhLCBDQSA5MzEwMyANCiAgIFBob25lOiA4MDUtODg0LTMxNjIgDQogICBFbWFpbDogYWxhbi5z dGViYmVuc0BvcGVud2F2ZS5jb20gDQogDQogICBNaWx0IFJvc2VsaW5za3kgDQogICBPcGVud2F2 ZSBTeXN0ZW1zLCBJbmMuIA0KICAgNTMwIEUuIE1vbnRlY2l0byBTdC4sIFNhbnRhIEJhcmJhcmEs IENBIDkzMTAzIA0KICAgUGhvbmU6IDgwNS04ODQtNjIwNyANCiAgIEVtYWlsOiBtaWx0LnJvc2Vs aW5za3lAb3BlbndhdmUuY29tIA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCiANCiANClN0 ZWJiZW5zICYgUm9zZWxpbnNreSAgRXhwaXJlcyAtIFNlcHRlbWJlciAyMDAzICAgICAgICAgICAg ICBbUGFnZSAxNV0gDQoM ------------85AC17761C613B-- - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Tue Mar 4 12:37:13 2003 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id h24Hb6428719 for um-outgoing; Tue, 4 Mar 2003 12:37:06 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from zoe.office.snowshore.com (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id h24Hb3x28710 for ; Tue, 4 Mar 2003 12:37:05 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [UM] FW: IETF 56 Presentation Submissions Date: Tue, 4 Mar 2003 12:39:09 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D24885C@zoe.office.snowshore.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF 56 Presentation Submissions Thread-Index: AcLhvsCJf/zzvciTRUudIRTUcFW2IAAry9NQ From: "Eric Burger" To: "IETF LEMONADE (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by flyingfox.snowshore.com id h24Hb5x28711 Sender: owner-um@snowshore.com Precedence: bulk I can get your presentations posted prior to our meeting in San Francisco. As a reminder, we are meeting from 3:30pm - 5:30pm on Thursday, March 20. Cons: You have to get your presentation written before you present it :-) Pros: If (when) the projector dies, everyone has access to your presentation without lots of "I'll post it here" time wasted. Also, people following on Jabber can follow along with the presentation without clogging up the mail list. N.B.: No tutorials; only problem resolution and discussion. Remember, we have only 2 hours! -----Original Message----- From: IETF Proceedings Administrator [mailto:minutes@ietf.org] Sent: Monday, March 03, 2003 2:53 PM To: wgchairs@ietf.org; bofchairs@ietf.org; Steve Coya Subject: IETF 56 Presentation Submissions This message is for all group chairs who will be meeting in San Francisco. Presentations may be submitted for online viewing at IETF 56 along with any interim sessions since Atlanta (55). These materials may be sent in until Thursday, March 14th @ 5:00pm. After this cutoff date materials may be submitted onsite at the Registration Desk, however please allow at least 1 day for new posts to be listed online. Please see www.ietf.org/proceedings/03mar/ for guidelines and the group submission form. Thank you, IETF Secretariat - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Thu Mar 6 12:25:08 2003 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id h26HOrQ17202 for um-outgoing; Thu, 6 Mar 2003 12:24:53 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from il-tlv-smtpout1.icomverse.com (comversegw.icomverse.com [192.118.48.248]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id h26HOox17197 for ; Thu, 6 Mar 2003 12:24:50 -0500 (EST) Received: from il-tlv-mbdg1.comverse.com (localhost.localdomain [127.0.0.1]) by il-tlv-smtpout1.icomverse.com (8.11.6/8.11.6) with ESMTP id h26HOaR23629 for ; Thu, 6 Mar 2003 19:24:36 +0200 Received: by il-tlv-mbdg1.comverse.com with Internet Mail Service (5.5.2655.55) id <1W08P614>; Thu, 6 Mar 2003 19:24:48 +0200 Message-ID: <32B823C1CD4FD5119C0D0002A560F78E09B47BB5@ismail3.comverse.com> From: Decktor Gev To: "'um@snowshore.com'" Cc: Erev Ari , Shapira Noam Subject: [UM] RE: Comments about draft-shapira-snap-04.txt Date: Thu, 6 Mar 2003 19:24:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E405.46728578" Sender: owner-um@snowshore.com Precedence: bulk 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_01C2E405.46728578 Content-Type: text/plain; charset="koi8-r" > -----Original Message----- > From: Alexey Melnikov [mailto:mel@messagingdirect.com] > Sent: Sunday, February 23, 2003 3:08 PM > To: Shapira Noam > Cc: Erev Ari > Subject: Comments about draft-shapira-snap-04.txt > > > Hi, > I have some comments about draft-shapira-snap-04.txt. If you've > already fixed them in a new revision, just disregard them. > > Feel free to forward my comments to appropriate mailing lists. > > >2. Basic Operation > ... > > > > Message Deposit process- a message is deposited in a user's > > In email world there is common term MDA (Mail Delivery Agent), so you > should probably use this term instead of inventing a new one. > We would use this term in the next drafts > > mailbox. In this case, if the deposit is successful, the Messaging > > System will send a "new message" request to the Notification > > Service. The request will include partial MIME headers of the > > incoming message. If the new message was rejected, the Messaging > > System will send a "message reject" request. An example > of a process > > > like this is the SMTP process in email servers. > > >2.1 The Transport Layer > > > > The suggested protocol uses HTTP as an underlying transport layer. > > The messaging system sends a HTTP request with the POST > method. The > > notification service replies with a HTTP response. A great deal of > > thought has been spent on choosing the correct underlying > transport > > protocol. HTTP has been chosen as it is widely deployed > over the net > > This is a dangerous comment as there is a lot of discussion at IETF > about "deployed and broken protocol" versa "non deployed and working > properly". But more to the point: HTTP uses request/response model, > but for SNAP it seems more appropriate to use "Fire-and-forget" model, > i.e. a Messaging System should just send the information to > Notification Service in the same way "syslog" works. Really, Messaging > System doesn't care whether the Notification Service received > the information and was able to process it. > One of the main reasons the request-response model has been used, was to increase reliability by allowing a "Store and foreward" like mechanizm. HTTP seems to be classic for such solution. > > and provides the needs of the notification protocol - as described > > in section 1.3 in this document. > > ... > >2.2.4 Retries > > > > Upon receiving a response from the service indicating a > failure, the > > > source SHOULD retry the request in case the service failure is > > recoverable (i.e. temporary). If the source does not receive a > response > > from the service, it SHOULD retry as well. > > I am not sure how you can deal reasonably with the latter case, thus I > am not sure why SHOULD is used here. This wold be changed to "RECOMMENDED" > > >2.2.5 Pipelining > > > > The source SHOULD pipeline requests according to [RFC-HTTP] part > > 8.1.2. > > Actually, exact section is 8.1.2.2 This would be corrected > > > If the source pipelines requests, the service SHOULD send > > its responses in the same order in which they where received. > > According to HTTP you MUST send responses in the same order. If the > server would reorder responses, the client will be unable to relate > responses to requests, because HTTP doesn't use tags for identifying > requests/responses. In section 3.1.7 you propose Request-Id that is > used for this purpose, but you still can't change order of responses > if you comply with HTTP. So, you either use HTTP (in which case this > sentence MUST be dropped), or you clearly say that you are using HTTP > syntax, but not HTTP semantics. > > Once again, maybe you are using wrong transport protocol and it might > be better to reuse something existing (e.g. BEEP, which has all you > want) or write a simpler protocol specifically designed for your task. > This would be changed to "MUST". Again for reliability reasons I think HTTP is the right choice. > >3.4.1 Email-Address (M) > > > > The fully qualified email address for the mailbox. > > There is terminology confusion here. So for my email address > "mel@messagingdirect.com" and two mailboxes "INBOX" and "Drafts", > Email-Address would be the same "mel@messagingdirect.com" and > Mailbox-Name would be "INBOX" or "Drafts" respectively? If the answer > is yes, I would suggest to use the term "user" instead of "mailbox" > above. A user has an email address and one or more [IMAP] mailboxes > associated with it. > If Mailbox-Name would have been a mandatory field this would have been reasonable. however this field may not be sent, causing the notification service being aware of the Subscriber's identity only by email-address. i think that for the sake of those cases, Email-Address is a better description for this field > >3.5.3 Message-Id > > > > Unique identifier that can be used by the Notification Service or > > any other user agent (UA) to retrieve the message. The message id > > should comply with [RFC-2822]. > > This is very confusing, considering what you write below. Is > it the value of Message-ID header or IMAP UID? > > Why do you have this as a requirement? The main purpose was to allow Notifcation end client to be able to retrieve the message. Obviously in the case of IMAP IMAP uid + UIDVALIDITY would allow this, however we cant assume the messaging server may not be IMAP4 server. Therefore I think it should be RFC822 message id. Since in the context of IMAP, IMAP uid + UIDVALIDITY provide a faster way of retrieving the message, I think a thought should be given to adding these fileds as additional fields in the next version(such as Imap-Uid, Imap-Uid-Validity). Another issue we were thinking about is using a URI field, supplied by the notification source to the service which would provide user an instant access to the message > > > The Message-Id MUST persist across > > sessions in the source, > > You can't require this, because this can't be guarantied for > IMAP, for example. In the context of IMAP that's right. However, as I've mentioned before I think Message-Id should reffer to RFC822 message-id header > > > in order to allow the UA to retrieve the > > message at any time. > > > > In case where the source is an Email Server, the source > SHOULD send > > the IMAP4 UID [RFC-IMAP4]. > > Why SHOULD here? Presumably Notification Service will pass > this information to some client that is going to use it, so > the client must know exactly what format is used. You should > add protocol tags here, e.g. > "Message-Id: IMAP;315@216", or even better, you can use URLs here. > > Regarding IMAP specifically: A message UID is only valid > while the corresponding mailbox UIDVALIDITY is the same. IMAP > server is allowed to change UIDVALIDITY at any time (although > this is not recommended). So, in order to uniquely identify a > message you MUST include the mailbox UIDVALIDITY value here as well. > I agree. therefore I think that in the case of IMAP email server the source should send IMAP UID and UIDVALIDITY over additional fields, as I proposed in my previous remarks > > >3.5.8 Message-Send-Time > > > > The time the message has been sent as described in the message. > > This MAY be the value of the Date header as defined in [RFC-2822]. > > Why MAY here? Can this value be anything other than the value > of Date header? If yes, you have to give more details what > can be used for this value. Yes, it can be something else. the messaging system may not be a rfc-2822 complient system (such as voice mail server) and therefore, the notification service doesn't require the source of this field to be associated with any header, but requires it to be this specific value(retrieved from headers, voice mail data, or any other form...) > > >3.5.9 Message-Receive-Time > > > > The time the message was received in the source expressed in GMT. > > This MAY be the value of the IMAP4 Internal Date Message Attribute > > as defined in [RFC-IMAP4] > > Same as above. Same as above > > >3.5.10 Message-Size > > > > A number that indicates the message size in bytes. If there are > > attachments to the message, the size SHOULD include the size of > > the attachments. > > For IMAP message size (i.e. RFC822.SIZE) always includes > attachments. Why SHOULD here? Since the notification client may be a messaging server which doesn't implememnt IMAP-4, this SNAP <--> IMAP-4 association can't be mandatory.(if its an IMAP server that's correct but than again, it may not be one) > > > >3.5.12 Body > > This should probably be moved after 3.5.13. > I will come back to this when I comment on ABNF. > > > The source SHOULD send the body of the MIME message in certain > > requests as described later. When doing so, the following apply: > > > > The source MUST copy the Content-Type header from the MIME message > > to the request header. > > > > The source MUST NOT send the body if the Content-Type is > not "text". > > > All text subtypes are allowed. > > > > The source MAY send only part of the body (for example > the first 100 > > > octets). > > > > The source MUST add a Content-Length header to the request > > specifying the size of the body. > > You can add here that Content-Length is required as per HTTP 1.1 spec. Correct, this would be fixed in the next draft > > >4.1.3 Redirection (3xx) Status Codes > > > >4.1.3.1 "301 Moved Permanently" > > > > Upon receiving this status code, the source MUST resend the > > notification request to the new URI specified in the location > > field of the response. > > > > When sending other requests after receiving this response, the > > source SHOULD use the new URL that is part of the URI returned in > > the "location" field. > > > >4.1.3.2 "307 Temporary Redirect" > > > > Upon receiving this status code, the source MUST resend > the request > > to the new URI specified in the location field of the > response. The > > source MUST NOT change its behavior when sending future requests. > > You have either define own version or URLs here (e.g. > snap://test.example.com/...) or make say that if > http URL is used, it MUST include port number, because SNAP > is not running on the same port as HTTP. > Correct. We certainly want to benefit from the usage of HTTP and therefore use HTTP URL's. this would be fixed and added in the next draft. > >5.2.1 General Attribute Syntax > > > ... > > MessageGroup = > > Message-Context > > [From] > > [To] > > [CC] > > [Subject] > > [Message-Send-Time] > > [Message-Receive-Time] > > [Message-Size] > > [Body] > > [Msg-Importance] > > [Msg-Sensitivity] > > [Message-Id] > > [Delivery-Report-Msg] > > ABNF mandate ordering of fields (unless you add a comment > saying otherwise). [Body] should be moved to the end, as a > server will be unable to parse any attribute specified after > [Body]. Also, for the same reason there should be an empty > line to delimit Body from the rest. The proposed syntax would > be extensible as well. > Correct, this would be fixed in the next draft > >5.2.3 Attributes > ... > > Message-Size = *DIGITS > > This is wrong as allows for empty string and sequences like > 0...0. The correct syntax would be something like: > > NZDIGITS = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" > DIGITS = "0" / NZDIGITS > NZINTEGER = NZDIGITS *DIGITS > INTEGER = "0" / NZINTEGER > > The same comment applies to all *DIGIST values ("counter" and > maybe others). > > the syntax for "percentage" is wrong, but I think most people > understand what are you talking about. The correct syntax > would be (and you should leave "0".."100" as a > comment): > > percent = "0" / (NZDIGITS DIGITS) / ("1" 2*DIGITS) > Correct, this would be fixed in the next draft > >5.3 Response Syntax > > > > Response = 1Status-Line *1Request-Id-Line *1Description-Line > > This doesn't seem right, what exactly you are trying to say? This is a private case of the general response definition in HTTP protocol (section 6), when request-id line and description line would be considered as Entity-Header fields. > > >5.4 Examples: > > > > Request example: > > > > POST /Notification-Service/notif.cgi HTTP/1.1 ;The URI > > How does the client knows what URL to specify in the request? > This is not described anywhere in the document. If the > request URL is irrelevant, please say so. > The request URL in this example is arbitrary. This is only an example. We would add a remark in the next draft which would state that this URL isn't obligatory. > > Content-Type: text/SNAP; ;From HTTP > > charset="utf-8" ;From HTTP > > Content-Length: nnnn ;From HTTP > > > > Notification-Protocol-Version:1.1 > > Application-Name:Applic > > Application-Version:1.0 > > Server-Type:Email > > Request-Type:New-Msg > > Request-Time:15Feb2000%2012:02:00%20+0000 > > Why are you encoding spaces? I don't think this is described in ABNF. Your are right. This would be removed in the next version of the draft > > > Request-Id:9941401AA > > Message-Context:text-message > ;Indicate email > > Message-Id:9999 > > Email-Address:joe@email.com > > Server-Name:ES1 > > Total-Email-Message:20 > > Total-New-Email-Message:20 > > Message-Send-Time:15Feb2000%2012:02:00%20+0000 > > Message-Receive-Time:15Feb2000%2012:02:00%20+0000 > > Message-Size:20000 > > Msg-Importance:high > > From:Budd@email.com > > To:joe@email.com > > Subject:Hello%20Joe > > Response example (1): > > HTTP/1.1 200 OK CRLF > > Some mandatory HTTP headers are missing. I'm not sure I know to which Headers u refer to. If your are refering to Content-Type and/Or Content-Length, they would be added in the next draft's example. > > > Request Id: 9941401AA CRLF > > Typo: Should be Request-Id This has already been fixed in Draft 5. > > > Request processed successfully CRLF > > Here you use CRLF convention. I suggest you just add empty lines as > appropriate: You are right. We will use a consistent notations in the next draft's examples. (either CRLF or emty lines, but in a consistent way throughout the entire draft) > > Response example (1): > HTTP/1.1 200 OK > Content-Type: text/SNAP; ;From HTTP > charset="utf-8" ;From HTTP > Content-Length: mmm ;From HTTP > > Request-Id: 9941401AA > Request processed successfully > > >6.3 Impersonation > > > > A Messaging System impersonation might cause the Notification > > Service to send notification messages on events that did > not occur. > > This is why you need authentication. This is not going to be > good enough for IESG. > This is one of the main issues raised towards the mailing list. we do intend of dealing more seriously with the security aspect. > >6.4 Network Snooping > > > > Packet sniffing on the SNAP payload may impose a threat on the > > user's privacy. The SNAP's payload SHOULD be secured in order to > > prevent network snooping. > > You have to give some indication how the payload can be > secured, otherwise your SHOULD is meaningless. Once again, currently SNAP doesn't deal intesively with security issues. We hope to add this aspects > > > 7. IANA Considerations > ... > > Author/Change controller: > > > > noam.shapira@comverse.com > > Usually author is you, and Change controller is IESG. This is > for a case when you can't be contacted. This would be fixed in the next draft > > >8. References > > As per new IESG requirements this has to be split into to > parts: normative references (i.e. "required to implement") > and informative references. > > P.S. I hope that my comments don't discourage you, as I think > it is a good start. > > Best Regards, > Alexey Melnikov > __________________________________________ > R & D, ACI Worldwide/MessagingDirect > Watford, UK > > Work Phone: +44 1923 81 2877 > Home Page: http://orthanc.ab.ca/mel > > I speak for myself only, not for my employer. > __________________________________________ > > > > ------_=_NextPart_001_01C2E405.46728578 Content-Type: text/html; charset="koi8-r" RE: Comments about draft-shapira-snap-04.txt

> -----Original Message-----
> From: Alexey Melnikov [mailto:mel@messagingdirect.com]
> Sent: Sunday, February 23, 2003 3:08 PM
> To: Shapira Noam
> Cc: Erev Ari
> Subject: Comments about draft-shapira-snap-04.txt
>
>
> Hi,
> I have some comments about draft-shapira-snap-04.txt. If you've
> already fixed them in a new revision, just disregard them.
>
> Feel free to forward my comments to appropriate mailing lists.
>
> >2. Basic Operation
> ...
> >
> >   Message Deposit process-  a message is deposited in a user's
>
> In email world there is common term MDA (Mail Delivery Agent), so you
> should probably use this term instead of inventing a new one.
>
We would use this term in the next drafts

> >   mailbox. In this case, if the deposit is successful, the Messaging
> >   System will send a "new message" request to the Notification
> >   Service. The request will include partial MIME headers of the
> >   incoming message. If the new message was rejected, the Messaging
> >   System will send a "message reject" request. An example
> of a process
>
> >   like this is the SMTP process in email servers.
>
> >2.1 The Transport Layer
> >
> >   The suggested protocol uses HTTP as an underlying transport layer.
> >   The messaging system sends a HTTP request with the POST
> method. The
> >   notification service replies with a HTTP response. A great deal of
> >   thought has been spent on choosing the correct underlying
> transport
> >   protocol. HTTP has been chosen as it is widely deployed
> over the net
>
> This is a dangerous comment as there is a lot of discussion at IETF
> about "deployed and broken protocol" versa "non deployed and working
> properly". But more to the point: HTTP uses request/response model,
> but for SNAP it seems more appropriate to use "Fire-and-forget" model,
> i.e. a Messaging System should just send the information to
> Notification Service in the same way "syslog" works. Really, Messaging
> System doesn't care whether the Notification Service received
> the information and was able to process it.
>
One of the main reasons the request-response model has been used, was to increase reliability by allowing a "Store and foreward" like mechanizm. HTTP seems to be classic for such solution.

> >   and provides the needs of the notification protocol - as described
> >   in section 1.3 in this document.
>
> ...
> >2.2.4 Retries
> >
> >   Upon receiving a response from the service indicating a
> failure, the
>
> >   source SHOULD retry the request in case the service failure is
> >   recoverable (i.e. temporary). If the source does not receive a
> response
> >   from the service, it SHOULD retry as well.
>
> I am not sure how you can deal reasonably with the latter case, thus I
> am not sure why SHOULD is used here.

This wold be changed to "RECOMMENDED"

>
> >2.2.5 Pipelining
> >
> >   The source SHOULD pipeline requests according to [RFC-HTTP] part
> >   8.1.2.
>
> Actually, exact section is 8.1.2.2

This would be corrected

>
> >   If the source pipelines requests, the service SHOULD send
> >   its responses in the same order in which they where received.
>
> According to HTTP you MUST send responses in the same order. If the
> server would reorder responses, the client will be unable to relate
> responses to requests, because HTTP doesn't use tags for identifying
> requests/responses. In section 3.1.7 you propose Request-Id that is
> used for this purpose, but you still can't change order of responses
> if you comply with HTTP. So, you either use HTTP (in which case this
> sentence MUST be dropped), or you clearly say that you are using HTTP
> syntax, but not HTTP semantics.
>
> Once again, maybe you are using wrong transport protocol and it might
> be better to reuse something existing (e.g. BEEP, which has all you
> want) or write a simpler protocol specifically designed for your task.
>

This would be changed to "MUST". Again for reliability reasons I think HTTP is the right choice.

> >3.4.1 Email-Address (M)
> >
> >   The fully qualified email address for the mailbox.
>
> There is terminology confusion here.  So for my email address
> "mel@messagingdirect.com" and two mailboxes "INBOX" and "Drafts",
> Email-Address would be the same "mel@messagingdirect.com" and
> Mailbox-Name would be "INBOX" or "Drafts" respectively? If the answer
> is yes, I would suggest to use the term "user" instead of "mailbox"
> above. A user has an email address and one or more [IMAP] mailboxes
> associated with it.
>

If Mailbox-Name would have been a mandatory field this would have been reasonable. however this field may not be sent, causing the notification service being aware of the Subscriber's identity only by email-address. i think that for the sake of those cases, Email-Address is a better description for this field

> >3.5.3 Message-Id
> >
> >   Unique identifier that can be used by the Notification Service or
> >   any other user agent (UA) to retrieve the message. The message id
> >   should comply with [RFC-2822].
>
> This is very confusing, considering what you write below. Is
> it the value of Message-ID header or IMAP UID?
>
> Why do you have this as a requirement?

The main purpose was to allow Notifcation end client to be able to retrieve the message. Obviously in the case of IMAP IMAP uid + UIDVALIDITY would allow this, however we cant assume the messaging server may not be IMAP4 server. Therefore I think it should be RFC822 message id. Since in the context of IMAP, IMAP uid + UIDVALIDITY provide a faster way of retrieving the message, I think a thought should be given to adding these fileds as additional fields in the next version(such as Imap-Uid, Imap-Uid-Validity).

Another issue we were thinking about is using a URI field, supplied by the notification source to the service which would provide user an instant access to the message

>
> >   The Message-Id MUST persist across
> >   sessions in the source,
>
> You can't require this, because this can't be guarantied for
> IMAP, for example.

In the context of IMAP that's right. However, as I've mentioned before I think Message-Id should reffer to RFC822 message-id header

>
> >   in order to allow the UA to retrieve the
> >   message at any time.
> >
> >   In case where the source is an Email Server, the source
> SHOULD send
> >   the IMAP4 UID [RFC-IMAP4].
>
> Why SHOULD here? Presumably Notification Service will pass
> this information to some client that is going to use it, so
> the client must know exactly what format is used. You should
> add protocol tags here, e.g.
> "Message-Id: IMAP;315@216", or even better, you can use URLs here.
>
> Regarding IMAP specifically: A message UID is only valid
> while the corresponding mailbox UIDVALIDITY is the same. IMAP
> server is allowed to change UIDVALIDITY at any time (although
> this is not recommended). So, in order to uniquely identify a
> message you MUST include the mailbox UIDVALIDITY value here as well.
>
I agree. therefore I think that in the case of IMAP email server the source should send IMAP UID and UIDVALIDITY over additional fields, as I proposed in my previous remarks

>
> >3.5.8 Message-Send-Time
> >
> >   The time the message has been sent as described in the message.
> >   This MAY be the value of the Date header as defined in [RFC-2822].
>
> Why MAY here? Can this value be anything other than the value
> of Date header? If yes, you have to give more details what
> can be used for this value.

Yes, it can be something else. the messaging system may not be a rfc-2822 complient system (such as voice mail server) and therefore, the notification service doesn't require the source of this field to be associated with any header, but requires it to be this specific value(retrieved from headers, voice mail data, or any other form...)

>
> >3.5.9 Message-Receive-Time
> >
> >   The time the message was received in the source expressed in GMT.
> >   This MAY be the value of the IMAP4 Internal Date Message Attribute
> >   as defined in [RFC-IMAP4]
>
> Same as above.

Same as above

>
> >3.5.10 Message-Size
> >
> >   A number that indicates the message size in bytes. If there are
> >   attachments to the message, the size SHOULD include the size of
> >   the attachments.
>
> For IMAP message size (i.e. RFC822.SIZE) always includes
> attachments. Why SHOULD here?

Since the notification client may be a messaging server which doesn't implememnt IMAP-4, this SNAP <--> IMAP-4 association can't be mandatory.(if its an IMAP server that's correct but than again, it may not be one)

>
>
> >3.5.12 Body
>
> This should probably be moved after 3.5.13.
> I will come back to this when I comment on ABNF.
>
> >   The source SHOULD send the body of the MIME message in certain
> >   requests as described later. When doing so, the following apply:
> >
> >   The source MUST copy the Content-Type header from the MIME message
> >   to the request header.
> >
> >   The source MUST NOT send the body if the Content-Type is
> not "text".
>
> >   All text subtypes are allowed.
> >
> >   The source MAY send only part of the body (for example
> the first 100
>
> >   octets).
> >
> >   The source MUST add a Content-Length header to the request
> >   specifying the size of the body.
>
> You can add here that Content-Length is required as per HTTP 1.1 spec.

Correct, this would be fixed in the next draft

>
> >4.1.3 Redirection (3xx) Status Codes
> >
> >4.1.3.1 "301 Moved Permanently"
> >
> >   Upon receiving this status code, the source MUST resend the
> >   notification request to the new URI specified in the location
> >   field of the response.
> >
> >   When sending other requests after receiving this response, the
> >   source SHOULD use the new URL that is part of the URI returned in
> >   the "location" field.
> >
> >4.1.3.2 "307 Temporary Redirect"
> >
> >   Upon receiving this status code, the source MUST resend
> the request
> >   to the new URI specified in the location field of the
> response. The
> >   source MUST NOT change its behavior when sending future requests.
>
> You have either define own version or URLs here (e.g.
> snap://test.example.com/...) or make say that if
> http URL is used, it MUST include port number, because SNAP
> is not running on the same port as HTTP.
>

Correct. We certainly want to benefit from the usage of HTTP and therefore use HTTP URL's. this would be fixed and added in the next draft.

> >5.2.1 General Attribute Syntax
> >
> ...
> >   MessageGroup =
> >     Message-Context
> >     [From]
> >     [To]
> >     [CC]
> >     [Subject]
> >     [Message-Send-Time]
> >     [Message-Receive-Time]
> >     [Message-Size]
> >     [Body]
> >     [Msg-Importance]
> >     [Msg-Sensitivity]
> >     [Message-Id]
> >     [Delivery-Report-Msg]
>
> ABNF mandate ordering of fields (unless you add a comment
> saying otherwise). [Body] should be moved to the end, as a
> server will be unable to parse any attribute specified after
> [Body]. Also, for the same reason there should be an empty
> line to delimit Body from the rest. The proposed syntax would
> be extensible as well.
>

Correct, this would be fixed in the next draft

> >5.2.3 Attributes
> ...
> >   Message-Size = *DIGITS
>
> This is wrong as allows for empty string and sequences like
> 0...0. The correct syntax would be something like:
>
> NZDIGITS = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
> DIGITS     = "0" / NZDIGITS
> NZINTEGER = NZDIGITS *DIGITS
> INTEGER = "0" / NZINTEGER
>
> The same comment applies to all *DIGIST values ("counter" and
> maybe others).
>
> the syntax for "percentage" is wrong, but I think most people
> understand what are you talking about. The correct syntax
> would be (and you should leave "0".."100" as a
> comment):
>
> percent = "0" / (NZDIGITS DIGITS) / ("1" 2*DIGITS)
>

Correct, this would be fixed in the next draft

> >5.3 Response Syntax
> >
> >   Response = 1Status-Line *1Request-Id-Line *1Description-Line
>
> This doesn't seem right, what exactly you are trying to say?

This is a private case of the general response definition in HTTP protocol (section 6), when request-id line and description line would be considered as Entity-Header fields.

>
> >5.4 Examples:
> >
> >   Request example:
> >
> > POST /Notification-Service/notif.cgi HTTP/1.1    ;The URI
>
> How does the client knows what URL to specify in the request?
> This is not described anywhere in the document. If the
> request URL is irrelevant, please say so.
>

The request URL in this example is arbitrary. This is only an example. We would add a remark in the next draft which would state that this URL isn't obligatory.

> >        Content-Type: text/SNAP;                         ;From HTTP
> >        charset="utf-8"                                  ;From HTTP
> >        Content-Length: nnnn                             ;From HTTP
> >
> >        Notification-Protocol-Version:1.1
> >        Application-Name:Applic
> >        Application-Version:1.0
> >        Server-Type:Email
> >        Request-Type:New-Msg
> >        Request-Time:15Feb2000%2012:02:00%20+0000
>
> Why are you encoding spaces? I don't think this is described in ABNF.

Your are right. This would be removed in the next version of the draft

>
> >        Request-Id:9941401AA
> >        Message-Context:text-message                  
> ;Indicate email
> >        Message-Id:9999
> >        Email-Address:joe@email.com
> >        Server-Name:ES1
> >        Total-Email-Message:20
> >        Total-New-Email-Message:20
> >        Message-Send-Time:15Feb2000%2012:02:00%20+0000
> >        Message-Receive-Time:15Feb2000%2012:02:00%20+0000
> >        Message-Size:20000
> >        Msg-Importance:high
> >        From:Budd@email.com
> >        To:joe@email.com
> >        Subject:Hello%20Joe
>
>     Response example (1):
> >      HTTP/1.1 200 OK CRLF
>
> Some mandatory HTTP headers are missing.

I'm not sure I know to which Headers u refer to. If your are refering to Content-Type and/Or Content-Length, they would be added in the next draft's example.

>
> >      Request Id: 9941401AA CRLF
>
> Typo: Should be Request-Id

This has already been fixed in Draft 5.

>
> >      Request processed successfully CRLF
>
> Here you use CRLF convention. I suggest you just add empty lines as
> appropriate:

You are right. We will use a consistent notations in the next draft's examples. (either CRLF or emty lines, but in a consistent way throughout the entire draft)

>
>     Response example (1):
>       HTTP/1.1 200 OK
>       Content-Type: text/SNAP;                         ;From HTTP
>       charset="utf-8"                                  ;From HTTP
>       Content-Length: mmm                             ;From HTTP
>
>       Request-Id: 9941401AA
>       Request processed successfully
>
> >6.3 Impersonation
> >
> >   A Messaging System impersonation might cause the Notification
> >   Service to send notification messages on events that did
> not occur.
>
> This is why you need authentication. This is not going to be
> good enough for IESG.
>
This is one of the main issues raised towards the mailing list. we do intend of dealing more seriously with the security aspect.

> >6.4 Network Snooping
> >
> >   Packet sniffing on the SNAP payload may impose a threat on the
> >   user's privacy. The SNAP's payload SHOULD be secured in order to
> >   prevent network snooping.
>
> You have to give some indication how the payload can be
> secured, otherwise your SHOULD is meaningless.

Once again, currently SNAP doesn't deal intesively with security issues. We hope to add this aspects

>
> > 7. IANA Considerations
> ...
> >     Author/Change controller:
> >
> >       noam.shapira@comverse.com
>
> Usually author is you, and Change controller is IESG. This is
> for a case when you can't be contacted.

This would be fixed in the next draft
>
> >8. References
>
> As per new IESG requirements this has to be split into to
> parts: normative references (i.e. "required to implement")
> and informative references.
>
> P.S. I hope that my comments don't discourage you, as I think
> it is a good start.
>
> Best Regards,
> Alexey Melnikov
> __________________________________________
> R & D, ACI Worldwide/MessagingDirect
> Watford, UK
>
> Work Phone: +44 1923 81 2877
> Home Page: http://orthanc.ab.ca/mel
>
> I speak for myself only, not for my employer.
> __________________________________________
>
>
>
>

------_=_NextPart_001_01C2E405.46728578-- - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Thu Mar 6 12:31:55 2003 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id h26HVsN17358 for um-outgoing; Thu, 6 Mar 2003 12:31:54 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from il-tlv-smtpout1.icomverse.com (comversegw.icomverse.com [192.118.48.248]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id h26HVqx17353 for ; Thu, 6 Mar 2003 12:31:52 -0500 (EST) Received: from il-tlv-mbdg2.comverse.com (localhost.localdomain [127.0.0.1]) by il-tlv-smtpout1.icomverse.com (8.11.6/8.11.6) with ESMTP id h26HVct23940 for ; Thu, 6 Mar 2003 19:31:38 +0200 Received: by il-tlv-mbdg2.comverse.com with Internet Mail Service (5.5.2655.55) id <1XAC460Q>; Thu, 6 Mar 2003 19:31:50 +0200 Message-ID: <767720C6032ED511AE8C00508BE3518E0756FCCC@ISMAILWEB> From: Shapira Noam To: "'um@snowshore.com'" Subject: [UM] FW: Comments about draft-shapira-snap-04.txt Date: Thu, 6 Mar 2003 19:31:46 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E406.397AE60C" Sender: owner-um@snowshore.com Precedence: bulk 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_01C2E406.397AE60C Content-Type: text/plain; charset="koi8-r" -----Original Message----- From: Decktor Gev Sent: Thursday, March 06, 2003 7:25 PM To: 'um@snowshore.com' Cc: Erev Ari; Shapira Noam Subject: RE: Comments about draft-shapira-snap-04.txt > -----Original Message----- > From: Alexey Melnikov [mailto:mel@messagingdirect.com] > Sent: Sunday, February 23, 2003 3:08 PM > To: Shapira Noam > Cc: Erev Ari > Subject: Comments about draft-shapira-snap-04.txt > > > Hi, > I have some comments about draft-shapira-snap-04.txt. If you've > already fixed them in a new revision, just disregard them. > > Feel free to forward my comments to appropriate mailing lists. > > >2. Basic Operation > ... > > > > Message Deposit process- a message is deposited in a user's > > In email world there is common term MDA (Mail Delivery Agent), so you > should probably use this term instead of inventing a new one. > We would use this term in the next drafts > > mailbox. In this case, if the deposit is successful, the Messaging > > System will send a "new message" request to the Notification > > Service. The request will include partial MIME headers of the > > incoming message. If the new message was rejected, the Messaging > > System will send a "message reject" request. An example > of a process > > > like this is the SMTP process in email servers. > > >2.1 The Transport Layer > > > > The suggested protocol uses HTTP as an underlying transport layer. > > The messaging system sends a HTTP request with the POST > method. The > > notification service replies with a HTTP response. A great deal of > > thought has been spent on choosing the correct underlying > transport > > protocol. HTTP has been chosen as it is widely deployed > over the net > > This is a dangerous comment as there is a lot of discussion at IETF > about "deployed and broken protocol" versa "non deployed and working > properly". But more to the point: HTTP uses request/response model, > but for SNAP it seems more appropriate to use "Fire-and-forget" model, > i.e. a Messaging System should just send the information to > Notification Service in the same way "syslog" works. Really, Messaging > System doesn't care whether the Notification Service received the > information and was able to process it. > One of the main reasons the request-response model has been used, was to increase reliability by allowing a "Store and foreward" like mechanizm. HTTP seems to be classic for such solution. > > and provides the needs of the notification protocol - as described > > in section 1.3 in this document. > > ... > >2.2.4 Retries > > > > Upon receiving a response from the service indicating a > failure, the > > > source SHOULD retry the request in case the service failure is > > recoverable (i.e. temporary). If the source does not receive a > response > > from the service, it SHOULD retry as well. > > I am not sure how you can deal reasonably with the latter case, thus I > am not sure why SHOULD is used here. This wold be changed to "RECOMMENDED" > > >2.2.5 Pipelining > > > > The source SHOULD pipeline requests according to [RFC-HTTP] part > > 8.1.2. > > Actually, exact section is 8.1.2.2 This would be corrected > > > If the source pipelines requests, the service SHOULD send > > its responses in the same order in which they where received. > > According to HTTP you MUST send responses in the same order. If the > server would reorder responses, the client will be unable to relate > responses to requests, because HTTP doesn't use tags for identifying > requests/responses. In section 3.1.7 you propose Request-Id that is > used for this purpose, but you still can't change order of responses > if you comply with HTTP. So, you either use HTTP (in which case this > sentence MUST be dropped), or you clearly say that you are using HTTP > syntax, but not HTTP semantics. > > Once again, maybe you are using wrong transport protocol and it might > be better to reuse something existing (e.g. BEEP, which has all you > want) or write a simpler protocol specifically designed for your task. > This would be changed to "MUST". Again for reliability reasons I think HTTP is the right choice. > >3.4.1 Email-Address (M) > > > > The fully qualified email address for the mailbox. > > There is terminology confusion here. So for my email address > "mel@messagingdirect.com" and two mailboxes "INBOX" and "Drafts", > Email-Address would be the same "mel@messagingdirect.com" and > Mailbox-Name would be "INBOX" or "Drafts" respectively? If the answer > is yes, I would suggest to use the term "user" instead of "mailbox" > above. A user has an email address and one or more [IMAP] mailboxes > associated with it. > If Mailbox-Name would have been a mandatory field this would have been reasonable. however this field may not be sent, causing the notification service being aware of the Subscriber's identity only by email-address. i think that for the sake of those cases, Email-Address is a better description for this field > >3.5.3 Message-Id > > > > Unique identifier that can be used by the Notification Service or > > any other user agent (UA) to retrieve the message. The message id > > should comply with [RFC-2822]. > > This is very confusing, considering what you write below. Is > it the value of Message-ID header or IMAP UID? > > Why do you have this as a requirement? The main purpose was to allow Notifcation end client to be able to retrieve the message. Obviously in the case of IMAP IMAP uid + UIDVALIDITY would allow this, however we cant assume the messaging server may not be IMAP4 server. Therefore I think it should be RFC822 message id. Since in the context of IMAP, IMAP uid + UIDVALIDITY provide a faster way of retrieving the message, I think a thought should be given to adding these fileds as additional fields in the next version(such as Imap-Uid, Imap-Uid-Validity). Another issue we were thinking about is using a URI field, supplied by the notification source to the service which would provide user an instant access to the message > > > The Message-Id MUST persist across > > sessions in the source, > > You can't require this, because this can't be guarantied for > IMAP, for example. In the context of IMAP that's right. However, as I've mentioned before I think Message-Id should reffer to RFC822 message-id header > > > in order to allow the UA to retrieve the > > message at any time. > > > > In case where the source is an Email Server, the source > SHOULD send > > the IMAP4 UID [RFC-IMAP4]. > > Why SHOULD here? Presumably Notification Service will pass > this information to some client that is going to use it, so > the client must know exactly what format is used. You should > add protocol tags here, e.g. > "Message-Id: IMAP;315@216", or even better, you can use URLs here. > > Regarding IMAP specifically: A message UID is only valid > while the corresponding mailbox UIDVALIDITY is the same. IMAP > server is allowed to change UIDVALIDITY at any time (although > this is not recommended). So, in order to uniquely identify a > message you MUST include the mailbox UIDVALIDITY value here as well. > I agree. therefore I think that in the case of IMAP email server the source should send IMAP UID and UIDVALIDITY over additional fields, as I proposed in my previous remarks > > >3.5.8 Message-Send-Time > > > > The time the message has been sent as described in the message. > > This MAY be the value of the Date header as defined in [RFC-2822]. > > Why MAY here? Can this value be anything other than the value > of Date header? If yes, you have to give more details what > can be used for this value. Yes, it can be something else. the messaging system may not be a rfc-2822 complient system (such as voice mail server) and therefore, the notification service doesn't require the source of this field to be associated with any header, but requires it to be this specific value(retrieved from headers, voice mail data, or any other form...) > > >3.5.9 Message-Receive-Time > > > > The time the message was received in the source expressed in GMT. > > This MAY be the value of the IMAP4 Internal Date Message Attribute > > as defined in [RFC-IMAP4] > > Same as above. Same as above > > >3.5.10 Message-Size > > > > A number that indicates the message size in bytes. If there are > > attachments to the message, the size SHOULD include the size of > > the attachments. > > For IMAP message size (i.e. RFC822.SIZE) always includes > attachments. Why SHOULD here? Since the notification client may be a messaging server which doesn't implememnt IMAP-4, this SNAP <--> IMAP-4 association can't be mandatory.(if its an IMAP server that's correct but than again, it may not be one) > > > >3.5.12 Body > > This should probably be moved after 3.5.13. > I will come back to this when I comment on ABNF. > > > The source SHOULD send the body of the MIME message in certain > > requests as described later. When doing so, the following apply: > > > > The source MUST copy the Content-Type header from the MIME message > > to the request header. > > > > The source MUST NOT send the body if the Content-Type is > not "text". > > > All text subtypes are allowed. > > > > The source MAY send only part of the body (for example > the first 100 > > > octets). > > > > The source MUST add a Content-Length header to the request > > specifying the size of the body. > > You can add here that Content-Length is required as per HTTP 1.1 spec. Correct, this would be fixed in the next draft > > >4.1.3 Redirection (3xx) Status Codes > > > >4.1.3.1 "301 Moved Permanently" > > > > Upon receiving this status code, the source MUST resend the > > notification request to the new URI specified in the location > > field of the response. > > > > When sending other requests after receiving this response, the > > source SHOULD use the new URL that is part of the URI returned in > > the "location" field. > > > >4.1.3.2 "307 Temporary Redirect" > > > > Upon receiving this status code, the source MUST resend > the request > > to the new URI specified in the location field of the > response. The > > source MUST NOT change its behavior when sending future requests. > > You have either define own version or URLs here (e.g. > snap://test.example.com/...) or make say that if > http URL is used, it MUST include port number, because SNAP > is not running on the same port as HTTP. > Correct. We certainly want to benefit from the usage of HTTP and therefore use HTTP URL's. this would be fixed and added in the next draft. > >5.2.1 General Attribute Syntax > > > ... > > MessageGroup = > > Message-Context > > [From] > > [To] > > [CC] > > [Subject] > > [Message-Send-Time] > > [Message-Receive-Time] > > [Message-Size] > > [Body] > > [Msg-Importance] > > [Msg-Sensitivity] > > [Message-Id] > > [Delivery-Report-Msg] > > ABNF mandate ordering of fields (unless you add a comment > saying otherwise). [Body] should be moved to the end, as a > server will be unable to parse any attribute specified after > [Body]. Also, for the same reason there should be an empty > line to delimit Body from the rest. The proposed syntax would > be extensible as well. > Correct, this would be fixed in the next draft > >5.2.3 Attributes > ... > > Message-Size = *DIGITS > > This is wrong as allows for empty string and sequences like > 0...0. The correct syntax would be something like: > > NZDIGITS = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" > DIGITS = "0" / NZDIGITS > NZINTEGER = NZDIGITS *DIGITS > INTEGER = "0" / NZINTEGER > > The same comment applies to all *DIGIST values ("counter" and > maybe others). > > the syntax for "percentage" is wrong, but I think most people > understand what are you talking about. The correct syntax > would be (and you should leave "0".."100" as a > comment): > > percent = "0" / (NZDIGITS DIGITS) / ("1" 2*DIGITS) > Correct, this would be fixed in the next draft > >5.3 Response Syntax > > > > Response = 1Status-Line *1Request-Id-Line *1Description-Line > > This doesn't seem right, what exactly you are trying to say? This is a private case of the general response definition in HTTP protocol (section 6), when request-id line and description line would be considered as Entity-Header fields. > > >5.4 Examples: > > > > Request example: > > > > POST /Notification-Service/notif.cgi HTTP/1.1 ;The URI > > How does the client knows what URL to specify in the request? > This is not described anywhere in the document. If the > request URL is irrelevant, please say so. > The request URL in this example is arbitrary. This is only an example. We would add a remark in the next draft which would state that this URL isn't obligatory. > > Content-Type: text/SNAP; ;From HTTP > > charset="utf-8" ;From HTTP > > Content-Length: nnnn ;From HTTP > > > > Notification-Protocol-Version:1.1 > > Application-Name:Applic > > Application-Version:1.0 > > Server-Type:Email > > Request-Type:New-Msg > > Request-Time:15Feb2000%2012:02:00%20+0000 > > Why are you encoding spaces? I don't think this is described in ABNF. Your are right. This would be removed in the next version of the draft > > > Request-Id:9941401AA > > Message-Context:text-message > ;Indicate email > > Message-Id:9999 > > Email-Address:joe@email.com > > Server-Name:ES1 > > Total-Email-Message:20 > > Total-New-Email-Message:20 > > Message-Send-Time:15Feb2000%2012:02:00%20+0000 > > Message-Receive-Time:15Feb2000%2012:02:00%20+0000 > > Message-Size:20000 > > Msg-Importance:high > > From:Budd@email.com > > To:joe@email.com > > Subject:Hello%20Joe > > Response example (1): > > HTTP/1.1 200 OK CRLF > > Some mandatory HTTP headers are missing. I'm not sure I know to which Headers u refer to. If your are refering to Content-Type and/Or Content-Length, they would be added in the next draft's example. > > > Request Id: 9941401AA CRLF > > Typo: Should be Request-Id This has already been fixed in Draft 5. > > > Request processed successfully CRLF > > Here you use CRLF convention. I suggest you just add empty lines as > appropriate: You are right. We will use a consistent notations in the next draft's examples. (either CRLF or emty lines, but in a consistent way throughout the entire draft) > > Response example (1): > HTTP/1.1 200 OK > Content-Type: text/SNAP; ;From HTTP > charset="utf-8" ;From HTTP > Content-Length: mmm ;From HTTP > > Request-Id: 9941401AA > Request processed successfully > > >6.3 Impersonation > > > > A Messaging System impersonation might cause the Notification > > Service to send notification messages on events that did > not occur. > > This is why you need authentication. This is not going to be > good enough for IESG. > This is one of the main issues raised towards the mailing list. we do intend of dealing more seriously with the security aspect. > >6.4 Network Snooping > > > > Packet sniffing on the SNAP payload may impose a threat on the > > user's privacy. The SNAP's payload SHOULD be secured in order to > > prevent network snooping. > > You have to give some indication how the payload can be > secured, otherwise your SHOULD is meaningless. Once again, currently SNAP doesn't deal intesively with security issues. We hope to add this aspects > > > 7. IANA Considerations > ... > > Author/Change controller: > > > > noam.shapira@comverse.com > > Usually author is you, and Change controller is IESG. This is > for a case when you can't be contacted. This would be fixed in the next draft > > >8. References > > As per new IESG requirements this has to be split into to > parts: normative references (i.e. "required to implement") > and informative references. > > P.S. I hope that my comments don't discourage you, as I think > it is a good start. > > Best Regards, > Alexey Melnikov > __________________________________________ > R & D, ACI Worldwide/MessagingDirect > Watford, UK > > Work Phone: +44 1923 81 2877 > Home Page: http://orthanc.ab.ca/mel > > I speak for myself only, not for my employer. > __________________________________________ > > > > ------_=_NextPart_001_01C2E406.397AE60C Content-Type: text/html; charset="koi8-r" FW: Comments about draft-shapira-snap-04.txt

-----Original Message-----
From: Decktor Gev
Sent: Thursday, March 06, 2003 7:25 PM
To: 'um@snowshore.com'
Cc: Erev Ari; Shapira Noam
Subject: RE: Comments about draft-shapira-snap-04.txt


> -----Original Message-----
> From: Alexey Melnikov [mailto:mel@messagingdirect.com]
> Sent: Sunday, February 23, 2003 3:08 PM
> To: Shapira Noam
> Cc: Erev Ari
> Subject: Comments about draft-shapira-snap-04.txt
>
>
> Hi,
> I have some comments about draft-shapira-snap-04.txt. If you've
> already fixed them in a new revision, just disregard them.
>
> Feel free to forward my comments to appropriate mailing lists.
>
> >2. Basic Operation
> ...
> >
> >   Message Deposit process-  a message is deposited in a user's
>
> In email world there is common term MDA (Mail Delivery Agent), so you
> should probably use this term instead of inventing a new one.
>
We would use this term in the next drafts

> >   mailbox. In this case, if the deposit is successful, the Messaging
> >   System will send a "new message" request to the Notification
> >   Service. The request will include partial MIME headers of the
> >   incoming message. If the new message was rejected, the Messaging
> >   System will send a "message reject" request. An example
> of a process
>
> >   like this is the SMTP process in email servers.
>
> >2.1 The Transport Layer
> >
> >   The suggested protocol uses HTTP as an underlying transport layer.
> >   The messaging system sends a HTTP request with the POST
> method. The
> >   notification service replies with a HTTP response. A great deal of
> >   thought has been spent on choosing the correct underlying
> transport
> >   protocol. HTTP has been chosen as it is widely deployed
> over the net
>
> This is a dangerous comment as there is a lot of discussion at IETF
> about "deployed and broken protocol" versa "non deployed and working
> properly". But more to the point: HTTP uses request/response model,
> but for SNAP it seems more appropriate to use "Fire-and-forget" model,
> i.e. a Messaging System should just send the information to
> Notification Service in the same way "syslog" works. Really, Messaging
> System doesn't care whether the Notification Service received the
> information and was able to process it.
>
One of the main reasons the request-response model has been used, was to increase reliability by allowing a "Store and foreward" like mechanizm. HTTP seems to be classic for such solution.

> >   and provides the needs of the notification protocol - as described
> >   in section 1.3 in this document.
>
> ...
> >2.2.4 Retries
> >
> >   Upon receiving a response from the service indicating a
> failure, the
>
> >   source SHOULD retry the request in case the service failure is
> >   recoverable (i.e. temporary). If the source does not receive a
> response
> >   from the service, it SHOULD retry as well.
>
> I am not sure how you can deal reasonably with the latter case, thus I
> am not sure why SHOULD is used here.

This wold be changed to "RECOMMENDED"

>
> >2.2.5 Pipelining
> >
> >   The source SHOULD pipeline requests according to [RFC-HTTP] part
> >   8.1.2.
>
> Actually, exact section is 8.1.2.2

This would be corrected

>
> >   If the source pipelines requests, the service SHOULD send
> >   its responses in the same order in which they where received.
>
> According to HTTP you MUST send responses in the same order. If the
> server would reorder responses, the client will be unable to relate
> responses to requests, because HTTP doesn't use tags for identifying
> requests/responses. In section 3.1.7 you propose Request-Id that is
> used for this purpose, but you still can't change order of responses
> if you comply with HTTP. So, you either use HTTP (in which case this
> sentence MUST be dropped), or you clearly say that you are using HTTP
> syntax, but not HTTP semantics.
>
> Once again, maybe you are using wrong transport protocol and it might
> be better to reuse something existing (e.g. BEEP, which has all you
> want) or write a simpler protocol specifically designed for your task.
>

This would be changed to "MUST". Again for reliability reasons I think HTTP is the right choice.

> >3.4.1 Email-Address (M)
> >
> >   The fully qualified email address for the mailbox.
>
> There is terminology confusion here.  So for my email address
> "mel@messagingdirect.com" and two mailboxes "INBOX" and "Drafts",
> Email-Address would be the same "mel@messagingdirect.com" and
> Mailbox-Name would be "INBOX" or "Drafts" respectively? If the answer
> is yes, I would suggest to use the term "user" instead of "mailbox"
> above. A user has an email address and one or more [IMAP] mailboxes
> associated with it.
>

If Mailbox-Name would have been a mandatory field this would have been reasonable. however this field may not be sent, causing the notification service being aware of the Subscriber's identity only by email-address. i think that for the sake of those cases, Email-Address is a better description for this field

> >3.5.3 Message-Id
> >
> >   Unique identifier that can be used by the Notification Service or
> >   any other user agent (UA) to retrieve the message. The message id
> >   should comply with [RFC-2822].
>
> This is very confusing, considering what you write below. Is
> it the value of Message-ID header or IMAP UID?
>
> Why do you have this as a requirement?

The main purpose was to allow Notifcation end client to be able to retrieve the message. Obviously in the case of IMAP IMAP uid + UIDVALIDITY would allow this, however we cant assume the messaging server may not be IMAP4 server. Therefore I think it should be RFC822 message id. Since in the context of IMAP, IMAP uid + UIDVALIDITY provide a faster way of retrieving the message, I think a thought should be given to adding these fileds as additional fields in the next version(such as Imap-Uid, Imap-Uid-Validity).

Another issue we were thinking about is using a URI field, supplied by the notification source to the service which would provide user an instant access to the message

>
> >   The Message-Id MUST persist across
> >   sessions in the source,
>
> You can't require this, because this can't be guarantied for
> IMAP, for example.

In the context of IMAP that's right. However, as I've mentioned before I think Message-Id should reffer to RFC822 message-id header

>
> >   in order to allow the UA to retrieve the
> >   message at any time.
> >
> >   In case where the source is an Email Server, the source
> SHOULD send
> >   the IMAP4 UID [RFC-IMAP4].
>
> Why SHOULD here? Presumably Notification Service will pass
> this information to some client that is going to use it, so
> the client must know exactly what format is used. You should
> add protocol tags here, e.g.
> "Message-Id: IMAP;315@216", or even better, you can use URLs here.
>
> Regarding IMAP specifically: A message UID is only valid
> while the corresponding mailbox UIDVALIDITY is the same. IMAP
> server is allowed to change UIDVALIDITY at any time (although
> this is not recommended). So, in order to uniquely identify a
> message you MUST include the mailbox UIDVALIDITY value here as well.
>
I agree. therefore I think that in the case of IMAP email server the source should send IMAP UID and UIDVALIDITY over additional fields, as I proposed in my previous remarks

>
> >3.5.8 Message-Send-Time
> >
> >   The time the message has been sent as described in the message.
> >   This MAY be the value of the Date header as defined in [RFC-2822].
>
> Why MAY here? Can this value be anything other than the value
> of Date header? If yes, you have to give more details what
> can be used for this value.

Yes, it can be something else. the messaging system may not be a rfc-2822 complient system (such as voice mail server) and therefore, the notification service doesn't require the source of this field to be associated with any header, but requires it to be this specific value(retrieved from headers, voice mail data, or any other form...)

>
> >3.5.9 Message-Receive-Time
> >
> >   The time the message was received in the source expressed in GMT.
> >   This MAY be the value of the IMAP4 Internal Date Message Attribute
> >   as defined in [RFC-IMAP4]
>
> Same as above.

Same as above

>
> >3.5.10 Message-Size
> >
> >   A number that indicates the message size in bytes. If there are
> >   attachments to the message, the size SHOULD include the size of
> >   the attachments.
>
> For IMAP message size (i.e. RFC822.SIZE) always includes
> attachments. Why SHOULD here?

Since the notification client may be a messaging server which doesn't implememnt IMAP-4, this SNAP <--> IMAP-4 association can't be mandatory.(if its an IMAP server that's correct but than again, it may not be one)

>
>
> >3.5.12 Body
>
> This should probably be moved after 3.5.13.
> I will come back to this when I comment on ABNF.
>
> >   The source SHOULD send the body of the MIME message in certain
> >   requests as described later. When doing so, the following apply:
> >
> >   The source MUST copy the Content-Type header from the MIME message
> >   to the request header.
> >
> >   The source MUST NOT send the body if the Content-Type is
> not "text".
>
> >   All text subtypes are allowed.
> >
> >   The source MAY send only part of the body (for example
> the first 100
>
> >   octets).
> >
> >   The source MUST add a Content-Length header to the request
> >   specifying the size of the body.
>
> You can add here that Content-Length is required as per HTTP 1.1 spec.

Correct, this would be fixed in the next draft

>
> >4.1.3 Redirection (3xx) Status Codes
> >
> >4.1.3.1 "301 Moved Permanently"
> >
> >   Upon receiving this status code, the source MUST resend the
> >   notification request to the new URI specified in the location
> >   field of the response.
> >
> >   When sending other requests after receiving this response, the
> >   source SHOULD use the new URL that is part of the URI returned in
> >   the "location" field.
> >
> >4.1.3.2 "307 Temporary Redirect"
> >
> >   Upon receiving this status code, the source MUST resend
> the request
> >   to the new URI specified in the location field of the
> response. The
> >   source MUST NOT change its behavior when sending future requests.
>
> You have either define own version or URLs here (e.g.
> snap://test.example.com/...) or make say that if
> http URL is used, it MUST include port number, because SNAP
> is not running on the same port as HTTP.
>

Correct. We certainly want to benefit from the usage of HTTP and therefore use HTTP URL's. this would be fixed and added in the next draft.

> >5.2.1 General Attribute Syntax
> >
> ...
> >   MessageGroup =
> >     Message-Context
> >     [From]
> >     [To]
> >     [CC]
> >     [Subject]
> >     [Message-Send-Time]
> >     [Message-Receive-Time]
> >     [Message-Size]
> >     [Body]
> >     [Msg-Importance]
> >     [Msg-Sensitivity]
> >     [Message-Id]
> >     [Delivery-Report-Msg]
>
> ABNF mandate ordering of fields (unless you add a comment
> saying otherwise). [Body] should be moved to the end, as a
> server will be unable to parse any attribute specified after
> [Body]. Also, for the same reason there should be an empty
> line to delimit Body from the rest. The proposed syntax would
> be extensible as well.
>

Correct, this would be fixed in the next draft

> >5.2.3 Attributes
> ...
> >   Message-Size = *DIGITS
>
> This is wrong as allows for empty string and sequences like
> 0...0. The correct syntax would be something like:
>
> NZDIGITS = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
> DIGITS     = "0" / NZDIGITS
> NZINTEGER = NZDIGITS *DIGITS
> INTEGER = "0" / NZINTEGER
>
> The same comment applies to all *DIGIST values ("counter" and
> maybe others).
>
> the syntax for "percentage" is wrong, but I think most people
> understand what are you talking about. The correct syntax
> would be (and you should leave "0".."100" as a
> comment):
>
> percent = "0" / (NZDIGITS DIGITS) / ("1" 2*DIGITS)
>

Correct, this would be fixed in the next draft

> >5.3 Response Syntax
> >
> >   Response = 1Status-Line *1Request-Id-Line *1Description-Line
>
> This doesn't seem right, what exactly you are trying to say?

This is a private case of the general response definition in HTTP protocol (section 6), when request-id line and description line would be considered as Entity-Header fields.

>
> >5.4 Examples:
> >
> >   Request example:
> >
> > POST /Notification-Service/notif.cgi HTTP/1.1    ;The URI
>
> How does the client knows what URL to specify in the request?
> This is not described anywhere in the document. If the
> request URL is irrelevant, please say so.
>

The request URL in this example is arbitrary. This is only an example. We would add a remark in the next draft which would state that this URL isn't obligatory.

> >        Content-Type: text/SNAP;                         ;From HTTP
> >        charset="utf-8"                                  ;From HTTP
> >        Content-Length: nnnn                             ;From HTTP
> >
> >        Notification-Protocol-Version:1.1
> >        Application-Name:Applic
> >        Application-Version:1.0
> >        Server-Type:Email
> >        Request-Type:New-Msg
> >        Request-Time:15Feb2000%2012:02:00%20+0000
>
> Why are you encoding spaces? I don't think this is described in ABNF.

Your are right. This would be removed in the next version of the draft

>
> >        Request-Id:9941401AA
> >        Message-Context:text-message                  
> ;Indicate email
> >        Message-Id:9999
> >        Email-Address:joe@email.com
> >        Server-Name:ES1
> >        Total-Email-Message:20
> >        Total-New-Email-Message:20
> >        Message-Send-Time:15Feb2000%2012:02:00%20+0000
> >        Message-Receive-Time:15Feb2000%2012:02:00%20+0000
> >        Message-Size:20000
> >        Msg-Importance:high
> >        From:Budd@email.com
> >        To:joe@email.com
> >        Subject:Hello%20Joe
>
>     Response example (1):
> >      HTTP/1.1 200 OK CRLF
>
> Some mandatory HTTP headers are missing.

I'm not sure I know to which Headers u refer to. If your are refering to Content-Type and/Or Content-Length, they would be added in the next draft's example.

>
> >      Request Id: 9941401AA CRLF
>
> Typo: Should be Request-Id

This has already been fixed in Draft 5.

>
> >      Request processed successfully CRLF
>
> Here you use CRLF convention. I suggest you just add empty lines as
> appropriate:

You are right. We will use a consistent notations in the next draft's examples. (either CRLF or emty lines, but in a consistent way throughout the entire draft)

>
>     Response example (1):
>       HTTP/1.1 200 OK
>       Content-Type: text/SNAP;                         ;From HTTP
>       charset="utf-8"                                  ;From HTTP
>       Content-Length: mmm                             ;From HTTP
>
>       Request-Id: 9941401AA
>       Request processed successfully
>
> >6.3 Impersonation
> >
> >   A Messaging System impersonation might cause the Notification
> >   Service to send notification messages on events that did
> not occur.
>
> This is why you need authentication. This is not going to be
> good enough for IESG.
>
This is one of the main issues raised towards the mailing list. we do intend of dealing more seriously with the security aspect.

> >6.4 Network Snooping
> >
> >   Packet sniffing on the SNAP payload may impose a threat on the
> >   user's privacy. The SNAP's payload SHOULD be secured in order to
> >   prevent network snooping.
>
> You have to give some indication how the payload can be
> secured, otherwise your SHOULD is meaningless.

Once again, currently SNAP doesn't deal intesively with security issues. We hope to add this aspects

>
> > 7. IANA Considerations
> ...
> >     Author/Change controller:
> >
> >       noam.shapira@comverse.com
>
> Usually author is you, and Change controller is IESG. This is
> for a case when you can't be contacted.

This would be fixed in the next draft
>
> >8. References
>
> As per new IESG requirements this has to be split into to
> parts: normative references (i.e. "required to implement")
> and informative references.
>
> P.S. I hope that my comments don't discourage you, as I think
> it is a good start.
>
> Best Regards,
> Alexey Melnikov
> __________________________________________
> R & D, ACI Worldwide/MessagingDirect
> Watford, UK
>
> Work Phone: +44 1923 81 2877
> Home Page: http://orthanc.ab.ca/mel
>
> I speak for myself only, not for my employer.
> __________________________________________
>
>
>
>

------_=_NextPart_001_01C2E406.397AE60C-- - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Thu Mar 6 12:37:20 2003 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id h26HbJQ17446 for um-outgoing; Thu, 6 Mar 2003 12:37:19 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from il-tlv-smtpout2.icomverse.com (comversegw.icomverse.com [192.118.48.248]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id h26HbCx17440; Thu, 6 Mar 2003 12:37:13 -0500 (EST) Received: from il-tlv-mbdg2.comverse.com (localhost.localdomain [127.0.0.1]) by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id h26Hb0c20967; Thu, 6 Mar 2003 19:37:00 +0200 Received: by il-tlv-mbdg2.comverse.com with Internet Mail Service (5.5.2655.55) id <1XAC47A0>; Thu, 6 Mar 2003 19:37:10 +0200 Message-ID: <767720C6032ED511AE8C00508BE3518E0756FCCF@ISMAILWEB> From: Shapira Noam To: "'Eric Burger'" Cc: um@snowshore.com Subject: RE: [UM] SNAP - next steps Date: Thu, 6 Mar 2003 19:37:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E407.0070427A" Sender: owner-um@snowshore.com Precedence: bulk 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_01C2E407.0070427A Content-Type: text/plain; charset="iso-8859-1" Eric, What you are basically saying is that if we do a complete security definition in the draft - it will be suitable as an internet protocol? NS > -----Original Message----- > From: Eric Burger [mailto:eburger@snowshore.com] > Sent: Friday, February 28, 2003 9:47 PM > To: Shapira Noam > Cc: um@snowshore.com > Subject: RE: [UM] SNAP - next steps > > > Here is the key issue that I am stuck on: > > Original Message From: Shapira Noam > [mailto:Shapira_Noam@icomverse.com] Sent: Tuesday, February > 25, 2003 9:22 AM [snip] > > 2. Where the Messaging server and the Notification server > are provided > > by the same service provider but not necessarily the same > manufacture > > (e.g. both servers are held by service-provider.com but the email > > server is from Email-SW-Vendor1 and the notification server is from > > Notification-SW-Vendor2 > > > > The difference is clear. The first option probably needs to handle > > more issues like: 1. Security / Privacy > > 2. Provisioning / Subscription > > 3. User Profile (user identification) > > Etc. > > I would offer that situation 2 is explicitly not the kind of > protocol the IETF publishes. The issues listed for situation > 1 ARE the issues listed that a real Internet solution needs > to address. I would liken this situation to the one raised > by the Security Considerations draft from the IAB > . From the draft: Internet protocol designers cannot safely assume that their protocols will be deployed in such an environment [a walled garden], for three reasons. First, protocols which were originally designed to be deployed in closed environments often are later deployed on the Internet, thus creating serious vulnerabilities. Second, networks which appear to be topologically disconnected may not be. One reason may be that the network has been reconfigured to allow access by the outside world. Moreover, firewalls are increasingly passing generic application layer protocols such as [SOAP] or [HTTP]. Network protocols which are based on these generic protocols cannot in general assume that a firewall will protect them. Although the second paragraph is speaking specifically about firewalls, I would offer the issues are identical for notification protocols. Protocol proposals, to be an IETF protocol, must address INTERNET requirements. ------_=_NextPart_001_01C2E407.0070427A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [UM] SNAP - next steps

Eric,

What you are basically saying is that if we do a = complete security definition in the draft - it will be suitable as an = internet protocol?

NS

> -----Original Message-----
> From: Eric Burger [mailto:eburger@snowshore.com] =
> Sent: Friday, February 28, 2003 9:47 PM
> To: Shapira Noam
> Cc: um@snowshore.com
> Subject: RE: [UM] SNAP - next steps
>
>
> Here is the key issue that I am stuck = on:
>
> Original Message From: Shapira Noam
> [mailto:Shapira_Noam@icomverse= .com] Sent: Tuesday, February
> 25, 2003 9:22 AM [snip]
> > 2. Where the Messaging server and the = Notification server
> are provided
> > by the same service provider but not = necessarily the same
> manufacture
> > (e.g. both servers are held by = service-provider.com  but the email
> > server is from Email-SW-Vendor1 and the = notification server is from
> > Notification-SW-Vendor2
> >
> > The difference is clear. The first option = probably needs to handle
> > more issues like: 1. Security / = Privacy
> > 2. Provisioning / Subscription
> > 3. User Profile (user identification) =
> > Etc.
>
> I would offer that situation 2 is explicitly = not the kind of
> protocol the IETF publishes.  The issues = listed for situation
> 1 ARE the issues listed that a real Internet = solution needs
> to address.  I would liken this situation = to the one raised
> by the Security Considerations draft from the = IAB
> <http://www.ietf.org/internet-drafts/draft-iab-sec-cons= -03.txt
>.  From the draft:

   Internet protocol designers cannot = safely assume
   that their protocols will be deployed = in such an
   environment [a walled garden], for = three reasons.
   First, protocols which were originally = designed
   to be deployed in closed environments = often are
   later deployed on the Internet, thus = creating
   serious vulnerabilities.

   Second, networks which appear to be = topologically
   disconnected may not be. One reason may = be that
   the network has been reconfigured to = allow access
   by the outside world. Moreover, = firewalls are
   increasingly passing generic = application layer
   protocols such as [SOAP] or = [HTTP].  Network
   protocols which are based on these = generic
   protocols cannot in general assume that = a firewall
   will protect them.

Although the second paragraph is speaking = specifically about firewalls, I would offer the issues are identical = for notification protocols.  Protocol proposals, to be an IETF = protocol, must address INTERNET requirements.

------_=_NextPart_001_01C2E407.0070427A-- - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Thu Mar 13 16:14:57 2003 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id h2DLESr22039 for um-outgoing; Thu, 13 Mar 2003 16:14:28 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from zoe.office.snowshore.com (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id h2DLERx22035 for ; Thu, 13 Mar 2003 16:14:27 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [UM] FW: Text Conferencing for the 56th IETF meeting in San Francisco Date: Thu, 13 Mar 2003 16:16:33 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D2488BE@zoe.office.snowshore.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Text Conferencing for the 56th IETF meeting in San Francisco Thread-Index: AcLoBVabSuzp8UnOQH2PWzjV/PwZAgBnhiXg From: "Eric Burger" To: "IETF SPEECHSC (E-mail)" , "IETF LEMONADE (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by flyingfox.snowshore.com id h2DLERx22036 Sender: owner-um@snowshore.com Precedence: bulk -----Original Message----- From: Marshall Rose [mailto:mrose+mtr.ietf@dbc.mtview.ca.us] Sent: Tuesday, March 11, 2003 1:59 PM Subject: Text Conferencing for the 56th IETF meeting in San Francisco Remote Access for the 56th IETF meeting in San Francisco: Text Conferencing At each IETF meeting, two of the working group meeting rooms are equipped for video multicast and remote participation. That is, for every IETF meeting slot, two of the working groups can see and hear the meeting. For the 56th IETF, in *addition* to the usual network A/V, text conferencing will be provided for every working group that meets. All of the conference rooms will be hosted on conference.ietf.jabber.com and each is named using the official IETF abbreviation found in the agenda (e.g., "apparea", "dhc", "forces", and so on -- for all the examples that follow, we'll use "foobar" as the abbreviation). Each conference room also has a 'bot which records everything that gets sent. So, the minute taker can review this information right after the meeting. 1. Before the meeting: 1.1. If you want to participate If you don't already have one, get yourself a Jabber client, here are some suggestions: platform suggestion -------- ---------- win32 http://exodus.jabberstudio.org 'nix http://gabber.sf.net macos http://jabberfox.sf.net When you start the client for the first time, it will eventually ask if you want to register on a public server. Go ahead and do that. If you want to find out more, instead of choosing these defaults, here are pointers to some additional information: list of clients: http://www.jabber.org/user/clientlist.php howto: http://www.jabber.org/user/userguide/ server list: http://www.jabber.org/user/publicservers.php To make sure everything is running ok, do a "Join Group Chat" with your Jabber client: Group/Room: plenary Server: conference.ietf.jabber.com This conference room is up and running right now (although probably no one will be in it when you connect). 1.2. What the Chair does If you want to make text conferencing available, you'll need to have a volunteer scribe in the meeting room. The scribe will be typing in a running commentary as to what's going on in the room (who's presenting, what question is being asked, etc.) So, why not send an email out on the mailing list now, before the meeting, to ask for volunteers? 2. At the meeting 2.1. What the Chair does When a session starts, the chair asks if someone in the room is willing to act as "scribe". If no one volunteers, read no further, we're done! Otherwise, the scribe should do a "Join Group Chat" with their Jabber client, e.g., Group/Room: foobar Server: conference.ietf.jabber.com 2.2. What the Scribe does The scribe types in a running commentary as to what's going on in the room. For example, if a speaker makes a presentation, the scribe types in the URL for the presentation (more on this in a bit). Simlarly, during question time, a remote participant can type a question into the room and the scribe can pass it on to the speaker. 2.3. What each Presenter does Each presenter should put a copy of their presentation on a web server somewhere, so remote participants can follow along. 2.4. Where to find the conference log http://www.jabber.com/chatbot/logs/conference.ietf.jabber.com/foobar/ NOTE: the logging facility will not be active until later this week... ####### - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Fri Mar 14 10:06:46 2003 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id h2EF6hk08661 for um-outgoing; Fri, 14 Mar 2003 10:06:43 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from zoe.office.snowshore.com (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id h2EF6gx08657 for ; Fri, 14 Mar 2003 10:06:42 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [UM] SNAP - next steps Date: Fri, 14 Mar 2003 10:08:48 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D2488DE@zoe.office.snowshore.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [UM] SNAP - next steps Thread-Index: AcLkB1dzbM2tWUsoRlSmQJRDhW1dhwFxcM0Q From: "Eric Burger" To: "Shapira Noam" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by flyingfox.snowshore.com id h2EF6gx08658 Sender: owner-um@snowshore.com Precedence: bulk In mathematical terms, that would be "necessary, but not sufficient." The protocol must fully address security. In addition, it needs to scale, work through firewalls and NATs, work over IPv6, and not choke on IDN (to name just a few). That said, you get almost all of that from using http. It is very important to NOT make simplifying assumptions about the connectivity between servers that will break the "works in all situations" nature of Internet protocols. -----Original Message----- From: Shapira Noam [mailto:Shapira_Noam@icomverse.com] Sent: Thursday, March 06, 2003 12:37 PM To: Eric Burger Cc: UM list Subject: RE: [UM] SNAP - next steps Eric, What you are basically saying is that if we do a complete security definition in the draft - it will be suitable as an internet protocol? NS > -----Original Message----- > From: Eric Burger [mailto:eburger@snowshore.com] > Sent: Friday, February 28, 2003 9:47 PM > To: Shapira Noam > Cc: um@snowshore.com > Subject: RE: [UM] SNAP - next steps > > > Here is the key issue that I am stuck on: > > Original Message From: Shapira Noam > [mailto:Shapira_Noam@icomverse.com] Sent: Tuesday, February > 25, 2003 9:22 AM [snip] > > 2. Where the Messaging server and the Notification server > are provided > > by the same service provider but not necessarily the same > manufacture > > (e.g. both servers are held by service-provider.com but the email > > server is from Email-SW-Vendor1 and the notification server is from > > Notification-SW-Vendor2 > > > > The difference is clear. The first option probably needs to handle > > more issues like: 1. Security / Privacy > > 2. Provisioning / Subscription > > 3. User Profile (user identification) > > Etc. > > I would offer that situation 2 is explicitly not the kind of > protocol the IETF publishes. The issues listed for situation > 1 ARE the issues listed that a real Internet solution needs > to address. I would liken this situation to the one raised > by the Security Considerations draft from the IAB > . From the draft: Internet protocol designers cannot safely assume that their protocols will be deployed in such an environment [a walled garden], for three reasons. First, protocols which were originally designed to be deployed in closed environments often are later deployed on the Internet, thus creating serious vulnerabilities. Second, networks which appear to be topologically disconnected may not be. One reason may be that the network has been reconfigured to allow access by the outside world. Moreover, firewalls are increasingly passing generic application layer protocols such as [SOAP] or [HTTP]. Network protocols which are based on these generic protocols cannot in general assume that a firewall will protect them. Although the second paragraph is speaking specifically about firewalls, I would offer the issues are identical for notification protocols. Protocol proposals, to be an IETF protocol, must address INTERNET requirements. - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Sun Mar 16 20:14:56 2003 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id h2H1El326634 for um-outgoing; Sun, 16 Mar 2003 20:14:47 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from zoe.office.snowshore.com (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id h2H1Ekx26630 for ; Sun, 16 Mar 2003 20:14:46 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [UM] Lemonade Agenda Date: Sun, 16 Mar 2003 20:16:52 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D2488F6@zoe.office.snowshore.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [UM] draft-stebrose-mmsarch-00.txt Thread-Index: AcLh6fE0EIm0kFW2SXm7j1HUwRFECgAsZi4QACHs5cIAEltpkAGV6GPwACxK5UEAZeA/EA== From: "Eric Burger" To: "IETF LEMONADE (E-mail)" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by flyingfox.snowshore.com id h2H1Ekx26631 Sender: owner-um@snowshore.com Precedence: bulk Date: THURSDAY, March 20, 2003 Time: 1530-1730 Afternoon Sessions II Location: Imperial A Directorate: APP Abbreviation: lemonade Title: License to Enhance Messaging Oriented Network Access for Diverse Endpoints PWG Note Wells & Agenda Bashing :05 Requirements (Kue Wong) :20 http://www.ietf.org/internet-drafts/draft-wong-umcli-02.txt Server-to-Server Requirements (Lisa Dusseault) :20 http://www.ietf.org/internet-drafts/draft-dusseault-s2s-event-reqs-00.txt SNAP (Ari Erev) :20 http://www.ietf.org/internet-drafts/draft-shapira-snap-05.txt Next Steps and Document Assignments (Chairs) :20 Mobile Messaging Invited Discussion (Alan Stebbens & Milt Roselinsky) :30 * There is a document for this presentation on the mail list. * The web interface is broken right now. I'll post the link by Monday evening. - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Mon Mar 17 09:10:42 2003 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id h2HEAcf08928 for um-outgoing; Mon, 17 Mar 2003 09:10:38 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from il-tlv-smtpout2.icomverse.com (il-tlv-firewall-main.icomverse.com [192.118.48.248]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id h2HEAax08924; Mon, 17 Mar 2003 09:10:36 -0500 (EST) Received: from il-tlv-mbdg1.comverse.com (localhost.localdomain [127.0.0.1]) by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id h2HEAJT20343; Mon, 17 Mar 2003 16:10:19 +0200 Received: by il-tlv-mbdg1.comverse.com with Internet Mail Service (5.5.2655.55) id ; Mon, 17 Mar 2003 16:10:27 +0200 Message-ID: <7D4344E32B34D511A6500002A560C60204D88FE5@il-tlv-mail4.comverse.com> From: Erev Ari To: "'um@snowshore.com'" Cc: "'eburger@snowshore.com'" , "'Glenn Parsons'" Subject: [UM] Media Size and SNAP Updates for Lemonade meeting (IETF 56) Date: Mon, 17 Mar 2003 16:10:22 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2EC8E.F2F8A3CC" Sender: owner-um@snowshore.com Precedence: bulk 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_01C2EC8E.F2F8A3CC Content-Type: text/plain; charset="windows-1255" Hello Eric, Glenn and all, I have changed my plans in the last minute, and as a result, I will not attend this IETF meeting in SF. :( I appologize for the late notice, but the decision was taken very late, and I could not let Eric know in time (before publishing the Lemonade Agenda). Here are some relevant updates for the lemonade meeting: 1. MediaSize (draft-shveidel-mediasize-02.txt) Draft updated on 02/03. The update reflects the feedback from last IETF, mainly that the "Media Size" is on a "Message-Context" level. If there is no new input, I think the document is ready. We did not receive any meaningful input in the last few months. 2. SNAP: Noam Shapira's and my original intention was to try and define the minimum requirements that SNAP needs to meet in order to be accepted as Lemonade's notification protocol. It seems that Lisa Dusseault's draft (server-to-server event pipeline protocols requirement) addresses this issue and defines such requirements. Unfortunately we missed this draft submission and only saw it today for the first time. We will make an effort to respond to the draft before the lemonade meeting on Thursday. >From a quick look at the draft it is quite evident that Lisa's requirements are much more general (and trying to address many application areas). This was not the original agenda of the SNAP work (actually, the option of having a "general notification" protocol was discussed and rejected in one of the IETF VPIM meetings). We will have to consider the SNAP work based on the acceptance and feedback of Lisa's draft requirements. Based on the above, there is nothing else to update about SNAP. Regards, Ari Erev ------_=_NextPart_001_01C2EC8E.F2F8A3CC Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Media Size and SNAP Updates for Lemonade meeting (IETF = 56)

Hello Eric, Glenn and all,

I have changed my plans in the last = minute, and as a result, I will not attend this IETF meeting in = SF.  :(
I appologize for the late notice, but = the decision was taken very late, and I could not let Eric know in time = (before publishing the Lemonade Agenda).

Here are some relevant updates for the = lemonade meeting:

1. MediaSize  = (draft-shveidel-mediasize-02.txt)

   Draft updated on = 02/03.
   The update reflects the = feedback from last IETF, mainly that the "Media Size" is on a = "Message-Context" level.
   If there is no new = input, I think the document is ready. We did not receive any meaningful = input in the last few months.

2. SNAP:

Noam Shapira's and my original = intention was to try and define the minimum requirements that SNAP = needs to meet in order

to be accepted as Lemonade's = notification protocol.

It seems that Lisa Dusseault's draft = (server-to-server event pipeline protocols requirement) addresses this = issue and defines such requirements.

Unfortunately we missed this draft = submission and only saw it today for the first time.
We will make an effort to respond to = the draft before the lemonade meeting on Thursday.

From a quick look at the draft it is = quite evident that Lisa's requirements are much more general (and = trying to address many application areas). This was not the original = agenda of the SNAP work (actually, the option of having a "general = notification" protocol was discussed and rejected in one of the = IETF VPIM meetings).

We will have to consider the SNAP work = based on the acceptance and feedback of Lisa's draft = requirements.

Based on the above, there is nothing = else to update about SNAP.

Regards,
Ari Erev


------_=_NextPart_001_01C2EC8E.F2F8A3CC-- - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Wed Mar 19 08:49:07 2003 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id h2JDlrV23160 for um-outgoing; Wed, 19 Mar 2003 08:47:53 -0500 (EST) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from il-tlv-smtpout2.icomverse.com (comversegw.icomverse.com [192.118.48.248]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id h2JDlpx23156 for ; Wed, 19 Mar 2003 08:47:51 -0500 (EST) Received: from il-tlv-mbdg1.comverse.com (localhost.localdomain [127.0.0.1]) by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id h2JDldk11200; Wed, 19 Mar 2003 15:47:39 +0200 Received: by il-tlv-mbdg1.comverse.com with Internet Mail Service (5.5.2655.55) id ; Wed, 19 Mar 2003 15:47:47 +0200 Message-ID: <767720C6032ED511AE8C00508BE3518E08CD33CD@ISMAILWEB> From: Shapira Noam To: um@snowshore.com, "'lisa@xythos.com'" Subject: [UM] Server-to-Server Requirements - a few comment Date: Wed, 19 Mar 2003 15:47:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2EE1E.1F1776FA" Sender: owner-um@snowshore.com Precedence: bulk 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_01C2EE1E.1F1776FA Content-Type: text/plain; charset="iso-8859-1" Hi Lisa, all, As Ari specified in the previous email I would like to give a few comments on the Server-to-Server Requirements (by Lisa Dusseault). Unfortunately - I will not be able to attend the meeting on Thursday - so here are my comments: There are 4 main issues I would like to relate to: 1. Connection Characteristics- is HTTP good enough? 2. Profile information / subscription issues 3. Security issues 4. Extensibility So, 1. Connection Characteristics - is HTTP good enough? Lisa's main requirement for the transport layer is that the protocol should be light weight as it is going to host very high traffic (as explained in the draft). Further, it should support the security requirements (mentioned later on) with minimum overhead. The argument suggested is that HTTP is too heavy for such a task (the overhead of HTTP information as a request/response protocol - is high and it's necessity is questionable). I would like to suggest a different approach - and give a few pointers in favor of HTTP - as I see it (my answer is mostly in the context of Messaging Notification - as defined in SNAP): A. HTTP is easy to deploy - we are using a well known protocol with easy development and implementation. We can't ignore this issue - building a protocol from nil - not using other legacy protocols - seems to me neglecting the fact that we want the protocol to catch and be implemented. B. As you know HTTP 1.1 support persistent connection - and therefore avoids the connection start ups (on heavily used connections). C. About the overhead. True, we could have done better in aspects of optimizing the amount of data passed back and forth using TCP packets. But, as I see it - another requirement is that the protocol should be informative. In messaging context (as defined in SNAP) - from our experience the overhead of HTTP is disputable. D. About the request/response model - I think Lisa has a good point in the extensibility of the protocol (mentioned later on) - where several sources of notification are assumed - therefore - a request/response model seems to me to be solving a set of problems - for example content-length - will probably be different for different notification source types. About ACKs. Are "ACKs" required? - I think they are required indeed. In some cases, the notification can be used as part of an application that is "mission critical" for the end user. Having ACKs helps the notification source take the appropriate action (for example retry) when the notification trigger is not processed. Removing the ACKs leaves the notification source in some doubt (especially in some end cases) which may cause losing (or duplicating) notifications. 2. Profile information / subscription issues In section 2.3 it says "..Email addresses can probably be used in some messaging scenarios, but what about other addresses? What if the server receiving the notifications is not an email server but another kind of notification aggregator?.." I think the basic assumption (at least what we assume in SNAP) should be that the notification server has the end user profile - in which - it has a mapping from one server identification to another. If the source is an email server - there is no better (unique) identifier than the email address. The notification server will need to know to map the address to some other address domain, such as an SMS number. About the subscription (section 2.4): ".. Is it a requirement that the recipient of notifications be able to choose which kinds are required? This would allow the server to filter out notifications for accounts that are inactive, and notifications of uninteresting types. It might greatly reduce the quantity of notifications used in the system. .. " As we see the notification server - it has two targets: event information aggregator and a logic server that generates (according to user preferences) notifications - e.g. send SMS on a new email. The notification server holds the user profile and decides if an event is interesting or not. I agree that we would like to reduce the amount of events in order to reduce the amount of traffic - but this should be on a server to server integration basis and not for each subscriber. There is no question that the user should be able to choose which kinds of notifications are required, and filter-out some notification types. But this is on the level between the end-user and the notification aggregator - not necessarily between the notification aggregator and the notification source. Sometimes, in order to implement a specific filtering scheme the notification aggregator MUST HAVE ALL the notifications sent to it from the notification source, in order to reliably implement a specific filtering requested by the end-user. I think in general that the issue of subscription should not be part of the notification protocol. It isn't part of SMTP, IMAP and other protocols. I think that we might need to consider (at least in the context of SNAP) a protocol that will accompany the notification protocol and will define the way provisioning should be done. Another issue about profile information, Section 4.1 talks about language negotiation. I think that the end user language should be part of the end user profile - on the notification server. The notification server will need to use different user agents in order to inform about the notification - each one might have a different char-set and maybe different language. 3. Security issues In section 3.3 it says: " ..It may be necessary for a notification aggregation server to provide authentication for the end user in order to prove that access to certain kinds of event information is allowed.." I think there is a basic problem with this. It means that the notification server will need to hold for each user on each notification source it's password that needs to be coordinated each time it is changed in one side. If the protocol will handle authorization and it will be encrypted (as the draft does suggest) it will provide a good enough solution. Note that assuming the notification server has the information on the subscriber (profile) - once the notification source is authenticated and authorized - for each user - the notification server can indicate if it is eligible for service or not. 4. Extensibility (section 5) This section comes back to the old dispute we had in the SNAP - do we want XML or 2822 like format. I think that XML is more commonly used and it's extensibility inherent. I would like to argue, though, that XML processing/parsing is "heavier" than the 2822-like format option. I think XML is an answer but not the only answer for extensibility and should not be taken for granted. Thanks, Noam ------_=_NextPart_001_01C2EE1E.1F1776FA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Server-to-Server Requirements - a few comment

Hi Lisa, all,

As Ari specified in the previous email = I would like to give a few comments on the Server-to-Server Requirements (by Lisa = Dusseault).

Unfortunately - I will not be able to = attend the meeting on Thursday - so here are my comments:

There are 4 main issues I would like = to relate to:
1. Connection Characteristics- is = HTTP good enough?
2. Profile information / subscription = issues
3. Security issues
4. Extensibility

So,

1. Connection Characteristics - is = HTTP good enough?

Lisa's main requirement for the = transport layer is that the protocol should be light weight as it is = going to host very high traffic (as explained in the draft).  = Further, it should support the security requirements (mentioned later = on) with minimum overhead.

The argument suggested is that HTTP is = too heavy for such a task (the overhead of HTTP information as a = request/response protocol - is high and it's necessity is = questionable). I would like to suggest a different approach - and give = a few pointers in favor of HTTP - as I see it (my answer is mostly in = the context of Messaging Notification - as defined in SNAP):

A. HTTP is easy to deploy - we are = using a well known protocol with easy development and implementation. = We can't ignore this issue - building a protocol from nil - not using = other legacy protocols - seems to me neglecting the fact that we want = the protocol to catch and be implemented.

B. As you know HTTP 1.1 support = persistent connection - and therefore avoids the connection start ups = (on heavily used connections).

C. About the overhead. True, we could = have done better in aspects of optimizing the amount of data passed = back and forth using TCP packets. But, as I see it - another = requirement is that the protocol should be informative. In messaging = context (as defined in SNAP) - from our experience the overhead of HTTP = is disputable.

D. About the request/response model - = I think Lisa has a good point in the extensibility of the protocol = (mentioned later on) - where several sources of notification are = assumed - therefore - a request/response model seems to me to be = solving a set of problems - for example content-length - will probably = be different for different notification source types.

About ACKs.
Are "ACKs" required? - I = think they are required indeed. In some cases, the notification can be = used as part of an application that is "mission critical" for = the end user. Having ACKs helps the notification source take the = appropriate action (for example retry) when the notification trigger is = not processed. Removing the ACKs leaves the notification source in some = doubt (especially in some end cases) which may cause losing (or = duplicating) notifications.


2. Profile information / subscription = issues

In section 2.3 it says
        "..Email addresses can probably be used in some = messaging scenarios,
        but what about other addresses? What if the server = receiving the
        notifications is not an email server but another kind of = notification
        aggregator?.."
I think the basic assumption (at = least what we assume in SNAP) should be that the notification server = has the end user profile - in which -  it has a mapping from one = server identification to another. If the source is an email server - = there is no better (unique) identifier than the email address. The = notification server will need to know to map the address to some other = address domain, such as an SMS number.

About the subscription (section = 2.4):
        ".. Is it a requirement that the recipient of = notifications be able to
        choose which kinds are required?  This would allow = the server to
        filter out notifications for accounts that are inactive, = and
        notifications of uninteresting types.  It might = greatly reduce the
        quantity of notifications used in the system. .. = "
As we see the notification = server  - it has two targets: event information aggregator and a = logic server that generates (according to user preferences) = notifications - e.g. send SMS on a new email. The notification server = holds the user profile and decides if an event is interesting or not. I = agree that we would like to reduce the amount of events in order to = reduce the amount of traffic - but this should be on a server to server = integration basis and not for each subscriber.

There is no question that the user = should be able to choose which kinds of notifications are required, and = filter-out some notification types. But this is on the level between = the end-user and the notification aggregator -  not necessarily = between the notification aggregator and the notification source. = Sometimes, in order to implement a specific filtering scheme the = notification aggregator MUST HAVE ALL the notifications sent to it from = the notification source, in order to reliably implement a specific = filtering requested by the end-user.

I think in general that the issue of = subscription should not be part of the notification protocol. It isn't = part of SMTP, IMAP and other protocols. I think that we might need to = consider (at least in the context of SNAP) a protocol that will = accompany the notification protocol and will define the way = provisioning should be done.

Another issue about profile = information, Section 4.1 talks about language negotiation. I think that = the end user language should be part of the end user profile - on the = notification server. The notification server will need to use different = user agents in order to inform about the notification - each one might = have a different char-set and maybe different language.

3. Security issues

In section 3.3 it says:
        " ..It may be necessary for a notification = aggregation server to provide
        authentication for the end  user in order to prove = that access to certain
        kinds of event information is allowed.."

I think there is a basic problem with = this. It means that the notification server will need to hold for each = user on each notification source it's password that needs to be = coordinated each time it is changed in one side. If the protocol will = handle authorization and it will be encrypted (as the draft does = suggest) it will provide a good enough solution. Note that assuming the = notification server has the information on the subscriber (profile) - = once the notification source is authenticated and authorized - for each = user - the notification server can indicate if it is eligible for = service or not.

4. Extensibility (section 5)
This section comes back to the old = dispute we had in the SNAP - do we want XML or 2822 like format. I = think that XML is more commonly used and it's extensibility inherent. I = would like to argue, though, that XML processing/parsing is = "heavier" than the 2822-like format option. I think XML is an = answer but not the only answer for extensibility and should not be = taken for granted.


Thanks,
Noam



------_=_NextPart_001_01C2EE1E.1F1776FA-- - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html