From owner-ietf-openproxy@mail.imc.org Tue Sep 2 01:53:19 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05699 for ; Tue, 2 Sep 2003 01:53:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u46S-0003OM-00 for opes-archive@ietf.org; Tue, 02 Sep 2003 01:53:20 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19u46R-0003Nw-00 for opes-archive@ietf.org; Tue, 02 Sep 2003 01:53:19 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h825ZNgc051349 for ; Mon, 1 Sep 2003 22:35:23 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h825ZNVL051348 for ietf-openproxy-bks; Mon, 1 Sep 2003 22:35:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h825ZLgc051343 for ; Mon, 1 Sep 2003 22:35:21 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h825ZOqF030304 for ; Mon, 1 Sep 2003 23:35:24 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h825ZE0N030303; Mon, 1 Sep 2003 23:35:14 -0600 (MDT) (envelope-from rousskov) Date: Mon, 1 Sep 2003 23:35:14 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: Re: moving along on rules language In-Reply-To: Message-ID: References: <20030822115516.4abe1229.mrose@dbc.mtview.ca.us> <20030822140828.168c71e3.mrose@dbc.mtview.ca.us> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-893559119-1062480914=:41427" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-893559119-1062480914=:41427 Content-Type: TEXT/PLAIN; charset=US-ASCII > On Fri, 22 Aug 2003, Marshall Rose wrote: > > great. if your confident with an alternative approach, put an > initial document together and submit it. i don't want to forestall > alternatives, but we need to be wrapping things up. An alternative draft is attached in plain text. HTML rendering is at http://www.measurement-factory.com/tmp/opes/snapshots/current/p.html As we discussed, this draft is not as detailed or as polished as the IRML draft. The draft purpose is to illustrate the "killer idea" behind the alternative approach: a minimalistic and efficient configuration language designed specifically for the problem domain, but with a room to grow. See draft introduction for more detailed treatment of design goals. I hope this draft is sufficient to pick one direction over the other, but I would be happy to clarify or add as needed, of course. I do realize that there has been a lot more work put into IRML already. I wish I knew about its existence earlier. If nothing else, this draft is probably the ultimate form of "constructive comments" IRML folks are asking for :-). On the positive side, many IRML ideas/developments can be easily reused if an alternative approach is chosen. The reverse is probably not as true because P capitalizes on being a language rather than a hierarchical collection of attributes (but it is all relative and equivalent from Turing point of view, of course). HTH, Alex. P.S. If "P" is already taken as a language name, please let me know. My quick search yielded no matches. "PL" does not count, IMHO. --0-893559119-1062480914=:41427 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="p.txt" Content-ID: Content-Description: draft-rousskov-opes-rules.txt Content-Disposition: attachment; filename="p.txt" Content-Transfer-Encoding: BASE64 DQoNCk9wZW4gUGx1Z2dhYmxlIEVkZ2UgU2VydmljZXMgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBBLiBSb3Vzc2tvdg0KSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRoZSBNZWFz dXJlbWVudCBGYWN0b3J5DQpFeHBpcmVzOiBGZWJydWFyeSAyOSwgMjAwNCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBdWd1c3QgMzEsIDIwMDMN Cg0KDQogICAgICAgICAgICAgICAgICAgICBQOiBNZXNzYWdlIFByb2Nlc3Np bmcgTGFuZ3VhZ2UNCiAgICAgICAgICAgICAgICAgICAgICAgZHJhZnQtcm91 c3Nrb3Ytb3Blcy1ydWxlcw0KDQpTdGF0dXMgb2YgdGhpcyBNZW1vDQoNCiAg IFRoaXMgZG9jdW1lbnQgaXMgYW4gSW50ZXJuZXQtRHJhZnQgYW5kIGlzIGlu IGZ1bGwgY29uZm9ybWFuY2Ugd2l0aA0KICAgYWxsIHByb3Zpc2lvbnMgb2Yg U2VjdGlvbiAxMCBvZiBSRkMyMDI2Lg0KDQogICBJbnRlcm5ldC1EcmFmdHMg YXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVl cmluZw0KICAgVGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0 cyB3b3JraW5nIGdyb3Vwcy4gTm90ZSB0aGF0IG90aGVyDQogICBncm91cHMg bWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRl cm5ldC1EcmFmdHMuDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQg ZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocw0K ICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVk IGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkNCiAgIHRpbWUuIEl0IGlzIGlu YXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVu Y2UNCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFz ICJ3b3JrIGluIHByb2dyZXNzLiINCg0KICAgVGhlIGxpc3Qgb2YgY3VycmVu dCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0IGh0dHA6Ly8N CiAgIHd3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0Lg0KDQog ICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3Jp ZXMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICBodHRwOi8vd3d3LmlldGYub3Jn L3NoYWRvdy5odG1sLg0KDQogICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwg ZXhwaXJlIG9uIEZlYnJ1YXJ5IDI5LCAyMDA0Lg0KDQpDb3B5cmlnaHQgTm90 aWNlDQoNCiAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkg KDIwMDMpLiBBbGwgUmlnaHRzIFJlc2VydmVkLg0KDQpBYnN0cmFjdA0KDQog ICBQIGlzIGEgc2ltcGxlIGNvbmZpZ3VyYXRpb24gbGFuZ3VhZ2UgZGVzaWdu ZWQgZm9yIGVmZmljaWVudCBhbmQNCiAgIGNvbXBhY3Qgc3BlY2lmaWNhdGlv biBvZiBtZXNzYWdlIHByb2Nlc3NpbmcgaW5zdHJ1Y3Rpb25zIGF0DQogICBh cHBsaWNhdGlvbiBwcm94aWVzLiBQIGNhbiBiZSB1c2VkIHRvIGluc3RydWN0 IGFuIGludGVybWVkaWFyeSBob3cgdG8NCiAgIG1hbmlwdWxhdGUgdGhlIGFw cGxpY2F0aW9uIG1lc3NhZ2UgYmVpbmcgcHJveGllZC4gU3VjaCBpbnN0cnVj dGlvbnMNCiAgIG5lZWRlZCBpbiBhbiBPcGVuIFBsdWdnYWJsZSBFZGdlIFNl cnZpY2VzIChPUEVTKSBjb250ZXh0Lg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN ClJvdXNza292ICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyOSwg MjAwNCAgICAgICAgICAgICAgICBbUGFnZSAxXQ0KDA0KSW50ZXJuZXQtRHJh ZnQgICAgICAgUDogTWVzc2FnZSBQcm9jZXNzaW5nIExhbmd1YWdlICAgICAg ICAgIEF1Z3VzdCAyMDAzDQoNCg0KVGFibGUgb2YgQ29udGVudHMNCg0KICAg MS4gIEludHJvZHVjdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzDQogICAyLiAgU3ludGF4IC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gIDUNCiAgIDMuICBMYW5ndWFnZSBlbGVtZW50cyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNg0KICAgMy4x IE9iamVjdHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICA2DQogICAzLjIgU3RhdGVtZW50cyAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDYNCiAgIDMuMyBFeHByZXNzaW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNg0KICAgMy40IEFz c2lnbm1lbnRzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICA3DQogICA0LiAgTW9kdWxlcyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDkNCiAgIDUuICBPUEVTIFNlcnZpY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMA0KICAgNi4gIFNlY3Vy aXR5IENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDExDQogICA3LiAgQ29tcGxpYW5jZSAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTIN CiAgIEEuICBFeGFtcGxlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMw0KICAgQi4gIENoYW5nZSBM b2cgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDE0DQogICAgICAgTm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTUNCiAg ICAgICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNg0KICAgICAgIEF1dGhvcidzIEFk ZHJlc3MgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDE2DQogICAgICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IGFuZCBD b3B5cmlnaHQgU3RhdGVtZW50cyAuIC4gLiAuIC4gLiAuIC4gMTcNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQpSb3Vzc2tvdiAgICAgICAgICAgICAgIEV4cGlyZXMg RmVicnVhcnkgMjksIDIwMDQgICAgICAgICAgICAgICAgW1BhZ2UgMl0NCgwN CkludGVybmV0LURyYWZ0ICAgICAgIFA6IE1lc3NhZ2UgUHJvY2Vzc2luZyBM YW5ndWFnZSAgICAgICAgICBBdWd1c3QgMjAwMw0KDQoNCjEuIEludHJvZHVj dGlvbg0KDQogICBUaGUgT3BlbiBQbHVnZ2FibGUgRWRnZSBTZXJ2aWNlcyAo T1BFUykgYXJjaGl0ZWN0dXJlDQogICBbSS1ELmlldGYtb3Blcy1hcmNoaXRl Y3R1cmVdLCBlbmFibGVzIGNvb3BlcmF0aXZlIGFwcGxpY2F0aW9uDQogICBz ZXJ2aWNlcyAoT1BFUyBzZXJ2aWNlcykgYmV0d2VlbiBhIGRhdGEgcHJvdmlk ZXIsIGEgZGF0YSBjb25zdW1lciwNCiAgIGFuZCB6ZXJvIG9yIG1vcmUgT1BF UyBwcm9jZXNzb3JzLiAgVGhlIGFwcGxpY2F0aW9uIHNlcnZpY2VzIHVuZGVy DQogICBjb25zaWRlcmF0aW9uIGFuYWx5emUgYW5kIHBvc3NpYmx5IHRyYW5z Zm9ybSBhcHBsaWNhdGlvbi1sZXZlbA0KICAgbWVzc2FnZXMgZXhjaGFuZ2Vk IGJldHdlZW4gdGhlIGRhdGEgcHJvdmlkZXIgYW5kIHRoZSBkYXRhIGNvbnN1 bWVyLg0KICAgT1BFUyBwcm9jZXNzb3JzIG5lZWQgdG8gYmUgdG9sZCB3aGF0 IHNlcnZpY2VzIGFyZSB0byBiZSBhcHBsaWVkIHRvDQogICB3aGF0IGFwcGxp Y2F0aW9uIG1lc3NhZ2VzLiBQIGxhbmd1YWdlIGNhbiBiZSB1c2VkIGZvciB0 aGlzDQogICBjb25maWd1cmF0aW9uIHRhc2suDQoNCiAgIEluIG90aGVyIHdv cmRzLCBQIGxhbmd1YWdlIHByaW1hcnkgb2JqZWN0aXZlIGlzIHRvIGV4cHJl c3Mgc3RhdGVtZW50cw0KICAgc2ltaWxhciB0bzoNCiAgIGlmIG1lc3NhZ2Ug bWVldHMgY3JpdGVyaWEgQywNCiAgIHRoZW4gYXBwbHkgc2VydmljZSBTOw0K DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAxDQoN CiAgIFRodXMsIFAgcHJvZ3JhbXMgbW9zdGx5IGRlYWwgd2l0aCBob3cgZm9y bXVsYXRpbmcgbWVzc2FnZS1kZXBlbmRlbnQNCiAgIGNvbmRpdGlvbnMgYW5k IGV4ZWN1dGluZyBzZXJ2aWNlcy4NCg0KICAgUCBkZXNpZ24gYXR0ZW1wdHMg dG8gc2F0aXNmeSBzZXZlcmFsIGNvbmZsaWN0aW5nIGdvYWxzOg0KDQogICBm bGV4aWJpbGl0eTogT1BFUyBpbnRlcm1lZGlhcmllcyBkZWFsIHdpdGggYSB3 aWRlIHJhbmdlIG9mDQogICAgICBhcHBsaWNhdGlvbnMgYW5kIHByb3RvY29s cyAoU01UUCwgSFRUUCwgUlRTUCwgSU0sIGV0Yy4pLiBUaGUNCiAgICAgIGxh bmd1YWdlIG11c3QgYmUgYWJsZSB0byBhY2NvbW1vZGF0ZSB2aXJ0dWFsbHkg YWxsIGtub3duIHRhc2tzIGluDQogICAgICBzZWxlY3RpbmcgYSBkZXNpcmVk IGFkYXB0YXRpb24gc2VydmljZSBmb3IgYSBtZXNzYWdlIG9mIGEga25vd24N CiAgICAgIGFwcGxpY2F0aW9uIHByb3RvY29sIChhbmQgY29uY2VpdmFibGUg ZnV0dXJlIGFwcGxpY2F0aW9ucykuDQoNCiAgIGVmZmljaWVuY3k6IExhbmd1 YWdlIGludGVycHJldGF0aW9uIG11c3QgYmUgZWZmaWNpZW50IGVub3VnaCB0 byBiZQ0KICAgICAgY29tcGFyYWJsZSB3aXRoIG90aGVyIG1lc3NhZ2UgcHJv Y2Vzc2luZyBvdmVyaGVhZHMgYXQgYSB0eXBpY2FsDQogICAgICBhcHBsaWNh dGlvbiBwcm94eSAoZS5nLiwgaW50ZXJwcmV0aW5nIEhUVFAgaGVhZGVycyB0 byBkZXRlcm1pbmUNCiAgICAgIHJlc3BvbnNlIGNhY2hhYmlsaXR5KS4NCg0K ICAgc2ltcGxpY2l0eTogVHlwaWNhbCBjb25maWd1cmF0aW9ucyBtdXN0IGJl IGVhc3kgdG8gd3JpdGUgYW5kDQogICAgICB1bmRlcnN0YW5kIGZvciBhIHR5 cGljYWwgT1BFUyBzeXN0ZW0gYWRtaW5pc3RyYXRvci4NCg0KICAgY29ycmVj dG5lc3M6IE1hbnkgbWVzc2FnZSBoYW5kbGluZyBjb25maWd1cmF0aW9ucyBh cmUgd3JpdHRlbiB3aXRob3V0DQogICAgICBkaXJlY3QgYWNjZXNzIHRvIGlu dGVybWVkaWFyaWVzIHRoYXQgd2lsbCB1c2UgdGhvc2UNCiAgICAgIGNvbmZp Z3VyYXRpb25zLiAgVGhlIGV4dGVudCBvZiBvZmYtbGluZSAoY29tcGlsZS10 aW1lKSBjb3JyZWN0bmVzcw0KICAgICAgY2hlY2tzIHNob3VsZCBjYXRjaCBh bGwgc3ludGF4IGVycm9ycyBhbmQgbWFueSBjb21tb24gc2VtYW50aWMNCiAg ICAgIGVycm9ycyBzdWNoIGFzIHVuZGVmaW5lZCB2YWx1ZXMgYW5kIHR5cGUg Y29uZmxpY3RzLg0KDQogICBjb21wYWN0bmVzczogSXQgaXMgcG9zc2libGUg dGhhdCBzb21lIHByb2Nlc3NpbmcgaW5zdHJ1Y3Rpb25zIHdpbGwgYmUNCiAg ICAgIHBpZ2d5YmFja2VkIGFzIGhlYWRlcnMvbWV0YWRhdGEgdG8gbWVzc2Fn ZXMgdGhleSByZWZlciB0bywgcGxhY2luZw0KICAgICAgc3RyaW5nZW50IHNp emUgcmVxdWlyZW1lbnRzIG9uIGxhbmd1YWdlIGNvZGUuDQoNCg0KDQoNClJv dXNza292ICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyOSwgMjAw NCAgICAgICAgICAgICAgICBbUGFnZSAzXQ0KDA0KSW50ZXJuZXQtRHJhZnQg ICAgICAgUDogTWVzc2FnZSBQcm9jZXNzaW5nIExhbmd1YWdlICAgICAgICAg IEF1Z3VzdCAyMDAzDQoNCg0KICAgc2VjdXJpdHk6IEl0IHNob3VsZCBiZSBk aWZmaWN1bHQgaWYgbm90IGltcG9zc2libGUgdG8gd3JpdGUgbWFsaWNpb3Vz DQogICAgICBjb2RlIHRoYXQgd291bGQgcmVzdWx0IGluIHNlY3VyaXR5IHZ1 bG5lcmFiaWxpdHkgb2YgY29tcGxpYW50DQogICAgICBsYW5ndWFnZSBpbnRl cnByZXRlci4NCg0KICAgUCBkZXNpZ24gaXMgYmFzZWQgb24gYSBtaW5pbWFs IHVzZWZ1bCBzdWJzZXQgb2YgZmVhdHVyZXMgZnJvbSBzZXZlcmFsDQogICBw cm9ncmFtbWluZyBsYW5ndWFnZXMgc3VjaCBhcyBSIChTKSBhbmQgU21hbGx0 YWxrLiBUZWNobmljYWxseQ0KICAgc3BlYWtpbmcsIFAgaXMgYSBzaW5nbGUt YXNzaWdubWVudCwgbGF6eSBldmFsdWF0aW9uLCBzdHJvbmdseSB0eXBlZA0K ICAgZnVuY3Rpb25hbCBwcm9ncmFtbWluZyBsYW5ndWFnZS4NCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUm91c3Nrb3YgICAg ICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDI5LCAyMDA0ICAgICAgICAg ICAgICAgIFtQYWdlIDRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICBQOiBN ZXNzYWdlIFByb2Nlc3NpbmcgTGFuZ3VhZ2UgICAgICAgICAgQXVndXN0IDIw MDMNCg0KDQoyLiBTeW50YXgNCg0KICAgUCBzeW50YXggaXMgZGVmaW5lZCBi eSB0aGUgZm9sbG93aW5nIEF1Z21lbnRlZCBCYWNrdXMtTmF1ciBGb3JtDQog ICAoQUJORikgW1JGQzIyMzRdOg0KDQogICBjb2RlID0gKihzdGF0ZW1lbnQg IjsiKQ0KDQogICBzdGF0ZW1lbnQgPSBhc3NpZ25tZW50IC8gZnVuY3Rpb24t Y2FsbCAvIGlmLXN0YXRlbWVudA0KDQogICBhc3NpZ25tZW50ID0gaWRlbnRp ZmllciAiOj0iIGV4cHJlc3Npb24NCg0KICAgaWYtc3RhdGVtZW50ID0gImlm IiAiKCIgZXhwcmVzc2lvbiAiKSIgInsiIGNvZGUgIn0iDQoNCiAgIGV4cHJl c3Npb24gPQ0KICAgCW5hbWUgLyBmdW5jdGlvbi1jYWxsIC8gInsiIGNvZGUg In0iDQogICAJLi4uIDsgbW9yZSB0byBiZSBkZWZpbmVkIChsb2dpY2FsIGFu ZCBhcml0aG1ldGljIGV4cHJlc3Npb25zKQ0KDQogICBuYW1lID0gaWRlbnRp ZmllciAqKCAiLiIgaWRlbnRpZmllcikNCg0KICAgZnVuY3Rpb24tY2FsbCA9 IG5hbWUgIigiIFtwYXJhbXNdICIpIg0KDQogICBwYXJhbXMgPSBleHByZXNz aW9uICooICIsIiBleHByZXNzaW9uKQ0KDQogICBpZGVudGlmaWVyID0gQUxQ SEEgKihBTFBIQSAvIERJR0lUIC8gIl8iKQ0KDQogICAuLi4gOyBtb3JlIHBy aW1pdGl2ZXMgdG8gYmUgZGVmaW5lZCBhcyBuZWVkZWQNCg0KDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAyDQoNCiAgIFhYWDog YWRkIC8qIGNvbW1lbnRzICovIGFuZCAvLyBjb21tZW50cy4NCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpSb3Vzc2tvdiAgICAg ICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjksIDIwMDQgICAgICAgICAg ICAgICAgW1BhZ2UgNV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgIFA6IE1l c3NhZ2UgUHJvY2Vzc2luZyBMYW5ndWFnZSAgICAgICAgICBBdWd1c3QgMjAw Mw0KDQoNCjMuIExhbmd1YWdlIGVsZW1lbnRzDQoNCjMuMSBPYmplY3RzDQoN CiAgIFAgaXMgY2VudGVyZWQgYXJvdW5kIHRoZSBjb25jZXB0IG9mIGFuICJv YmplY3QiIHRoYXQgaXMgc2ltaWxhciB0bw0KICAgb2JqZWN0cyBmcm9tIG90 aGVyIG9iamVjdC1vcmllbnRlZCBsYW5ndWFnZXMuIEFuIG9iamVjdCBpcyBh DQogICBjb2xsZWN0aW9uIG9mIG9iamVjdCBtZW1iZXJzOiBhdHRyaWJ1dGVz IGFuZCBtZXRob2RzLiBBdHRyaWJ1dGVzIGFyZQ0KICAgbmFtZWQgc2xvdHMg dGhhdCBzdG9yZSBvdGhlciBvYmplY3RzLiBNZXRob2RzIGFyZSBuYW1lZCBw aWVjZXMgb2YNCiAgIGNvZGUgdGhhdCBtYW5pcHVsYXRlIHRoZSBvYmplY3Qg dGhleSBiZWxvbmcgdG8gb3Igb3RoZXIgb2JqZWN0cy4gIFANCiAgIG9iamVj dHMgYXJlIGlkZW50aWZpZWQgYnkgdGhlaXIgbmFtZXMgKGUuZy4sIEh0dHAg b3IgdG1wKS4gQXR0cmlidXRlcw0KICAgYW5kIG1ldGhvZHMgYXJlIGFjY2Vz c2VkIHZpYSB0aGVpciBuYW1lcyB1c2luZyB0aGUgZG90ICgiLiIpIG9wZXJh dG9yDQogICBhcHBsaWVkIHRvIGEgbmFtZWQgb2JqZWN0LiAgRm9yIGV4YW1w bGUsIEh0dHAubWVzc2FnZS5oZWFkZXJzDQogICBleHByZXNzaW9uIGFjY2Vz c2VzIChuYW1lcykgaGVhZGVycyBpbnNpZGUgYSBtZXNzYWdlIGluc2lkZSB0 aGUgSFRUUA0KICAgbW9kdWxlLiBFdmVyeXRoaW5nIHRoYXQgY2FuIGJlIG5h bWVkIGluIFAgaXMgYW4gb2JqZWN0LiBTb21lIG9iamVjdHMNCiAgIG1heSBu b3QgaGF2ZSBhbnkgbWVtYmVycy4NCg0KICAgUCBkb2VzIG5vdCBoYXZlIGZh Y2lsaXRpZXMgZm9yIGRlc2NyaWJpbmcgb2JqZWN0cy4gV2hlbiB3cml0aW5n IGEgUA0KICAgcHJvZ3JhbSwgb25seSBvYmplY3RzIHN1cHBvcnRlZCBieSB0 aGUgaW50ZXJwcmV0b3IgY2FuIGJlIHVzZWQgYW5kIG5vDQogICBuZXcgb2Jq ZWN0cyBjYW4gYmUgYWRkZWQuIFAgc3VwcG9ydHMgbG9hZGFibGUgbW9kdWxl cyB0aGF0IGNhbiBiZQ0KICAgdXNlZCB0byBhZGQgb2JqZWN0cyB0byBzdXBw b3J0IG5ldyBhcHBsaWNhdGlvbiBwcm90b2NvbHMuICBJbiBmYWN0LCBQDQog ICBjb3JlIHN1cHBvcnRzIG5vIGFwcGxpY2F0aW9uIHByb3RvY29scyBkaXJl Y3RseS4gSW5zdGVhZCwgbW9kdWxlcw0KICAgbGlrZSAiSHR0cCIgY2FuIGJl IHVzZWQgdG8gcHJvY2VzcyBtZXNzYWdlcyBkZXBlbmRpbmcgb24gYXBwbGlj YXRpb24NCiAgIHByb3RvY29sIGJlaW5nIHByb3hpZWQuDQoNCiAgIEFsbCBQ IG9iamVjdHMgaGF2ZSB0eXBlcyBhbmQgbm8gZGVmYXVsdCAoc2lsZW50KSB0 eXBlIGNvbnZlcnNpb24gaXMNCiAgIHN1cHBvcnRlZC4gSG93ZXZlciwgZXhw bGljaXQgdHlwZSBjb252ZXJzaW9uIChjYXN0aW5nKSBpcyByYXJlbHkNCiAg IG5lZWRlZCBiZWNhdXNlIG1hbnkgb2JqZWN0IG1ldGhvZHMgYXJlIHBvbHlt b3JwaGljIChhY2NlcHQgc2V2ZXJhbA0KICAgdHlwZXMpLg0KICAgc2Vydmlj ZSA6PSBTZXJ2aWNlcy5maW5kT25lKCJodHRwOi8vaWFuYS5vcmcvb3Blcy9z ZXJ2aWNlcy9leGFtcGxlIik7DQoNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgRmlndXJlIDMNCg0KDQozLjIgU3RhdGVtZW50cw0KDQogICBP YmplY3RzIGFyZSBtYW5pcHVsYXRlZCB1c2luZyBpZi1zdGF0ZW1lbnRzIGFu ZCBmdW5jdGlvbi1jYWxscy4NCg0KICAgaWYgKEh0dHAucmVxdWVzdC5tZXRo b2QgPT0gIkdFVCIpIHsNCiAgIAlDb3JlLmV4ZWNTZXJ2aWNlKHNlcnZpY2Up Ow0KICAgfQ0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZp Z3VyZSA0DQoNCg0KMy4zIEV4cHJlc3Npb25zDQoNCiAgIFAgZXhwcmVzc2lv bnMgYXJlIHVzZWQgaW4gaWYtc3RhdGVtZW50cyB0byBzcGVjaWZ5IHRoZSBj b25kaXRpb24gZm9yDQogICB0aGUgaWYtc3RhdGVtZW50IGJvZHkgdG8gYmUg aW50ZXJwcmV0ZWQuDQoNCg0KDQpSb3Vzc2tvdiAgICAgICAgICAgICAgIEV4 cGlyZXMgRmVicnVhcnkgMjksIDIwMDQgICAgICAgICAgICAgICAgW1BhZ2Ug Nl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgIFA6IE1lc3NhZ2UgUHJvY2Vz c2luZyBMYW5ndWFnZSAgICAgICAgICBBdWd1c3QgMjAwMw0KDQoNCiAgIGlm IChIdHRwLnJlcXVlc3QubWV0aG9kID09ICJHRVQiIGFuZCB0aW1lLmN1cnJl bnQoKSA+IHRpbWUubm9vbikgew0KICAgCS4uLg0KICAgfQ0KDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSA1DQoNCiAgIEJpbmFy eSBvcGVyYXRvcnMgc3VjaCBhcyAiPT0iIG9yICIrIiBhcmUgbm90IGdsb2Jh bCBzcGVjaWFsIHN5bWJvbHMNCiAgIGJ1dCBhcmUgcGFzc2VkIHRvIHRoZSBv YmplY3Qgb24gdGhlIGxlZnQgZm9yIGludGVycHJldGF0aW9uLCBhbG9uZw0K ICAgd2l0aCB0aGUgZXhwcmVzc2lvbiBvbiB0aGUgcmlnaHQuICBBcHBseWlu ZyBhIGJpbmFyeSBvcGVyYXRvciBpcw0KICAgc2VtYW50aWNhbGx5IGVxdWl2 YWxlbnQgdG8gY2FsbGluZyBhbiBvYmplY3QgbWV0aG9kLiBGb3IgZXhhbXBs ZSwgdGhlDQogICBmb2xsb3dpbmcgdHdvIGV4cHJlc3Npb25zIGFyZSBlcXVp dmFsZW50Og0KICAgYSArIGIgKyBjDQogICAoYS4rKGIpKSArIGMNCiAgIChh LisoYikpLisoYykNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBGaWd1cmUgNg0KDQogICBUaGUgImEgKyBiICsgYyIgZm9ybSBpcyBwcmVm ZXJyZWQgZm9yIHB1cmVseSB2aXN1YWwgcmVhc29ucy4gIENvcmUgUA0KICAg bW9kdWxlIHByb3ZpZGVzIGJhc2ljIG9iamVjdHMgYW5kIG9wZXJhdG9ycyBm b3IgdGhlbSAoZS5nLiwgYm9vbGVhbg0KICAgYW5kIGludGVnZXIpLiBBcHBs aWNhdGlvbi1zcGVjaWZpYyBtb2R1bGVzIHVzdWFsbHkgcHJvdmlkZQ0KICAg YXBwbGljYXRpb25zLXNwZWNpZmljIG9iamVjdHM7IHRob3NlIG9iamVjdHMg dXN1YWxseSBoYXZlDQogICBhcHBsaWNhdGlvbi1zcGVjaWZpYyBtZXRob2Rz IGFuZCBtYXkgbm90IGhhdmUgbWV0aG9kcyB0byBzdXBwb3J0DQogICBvcGVy YXRpb25zIGNvbW1vbiBmb3IgYmFzaWMgdHlwZXMuIEZvciBleGFtcGxlLCBh biBIdHRwIG1vZHVsZQ0KICAgc3VwcGxpZXMgYW4gSFRUUCBoZWFkZXIgb2Jq ZWN0IHRoYXQgZG9lcyBub3QgaGF2ZSBhICIqIiBtZXRob2QuDQoNCiAgIFhY WDogZGVmaW5lIG9wZXJhdG9yIHByZWNlZGVuY2UsIGlmIGFueS4NCg0KMy40 IEFzc2lnbm1lbnRzDQoNCiAgIE1vc3QgcHJvY2VkdXJhbCBwcm9ncmFtbWlu ZyBsYW5ndWFnZXMgdXNlIHZhcmlhYmxlcyB0byBzdG9yZQ0KICAgaW50ZXJt ZWRpYXRlIHByb2Nlc3NpbmcgcmVzdWx0cy4gSW4gc3VjaCBsYW5ndWFnZXMs IGEgdmFyaWFibGUgaXMNCiAgIGVzc2VudGlhbGx5IGEgbmFtZWQgcGllY2Ug b2YgbWVtb3J5IHRoYXQgY2FuIGJlIGFzc2lnbmVkIGEgdmFsdWUgYW5kDQog ICBjYW4gYmUgdXBkYXRlZCB3aXRoIG5ldyB2YWx1ZXMgYXMgbmVlZGVkLiBQ IGRvZXMgbm90IGhhdmUgc3VjaA0KICAgdmFyaWFibGVzLiBJbnN0ZWFkLCBQ IHVzZXMgYSAic2luZ2xlIGFzc2lnbm1lbnQiIGFwcHJvYWNoOiBhbg0KICAg ZXhwcmVzc2lvbiBjYW4gYmUgdGFnZ2VkIHdpdGggYSBuYW1lIGFuZCB0aGF0 IG5hbWUgY2FuIGJlIHJldXNlZCBtYW55DQogICB0aW1lcyBpbiB0aGUgcHJv Z3JhbS4gT24gdGhlIHN1cmZhY2UsIHRoaXMgaXMgZXF1aXZhbGVudCB0byBo YXZpbmcNCiAgIGFsbCAidHJhZGl0aW9uYWwiIHZhcmlhYmxlcyBkZWNsYXJl ZCBhcyAiY29uc3RhbnQiLiBUaGUgZm9sbG93aW5nIHR3bw0KICAgaWYtc3Rh dGVtZW50cyBhcmUgc2VtYW50aWNhbGx5IGVxdWl2YWxlbnQgaW4gUDoNCg0K ICAgaWYgKEh0dHAucmVxdWVzdC5oZWFkZXJzLmhhdmUoSHR0cC5tYWtlSGVh ZGVyKCJDbGllbnQtSVAiKSkpIHsuLi59DQoNCiAgIGggOj0gSHR0cC5tYWtl SGVhZGVyKCJDbGllbnQtSVAiKTsNCiAgIGhzIDo9IEh0dHAucmVxdWVzdC5o ZWFkZXJzKCk7DQogICBpZiAoaHMuaGF2ZShoKSB7Li4ufQ0KDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSA3DQoNCiAgIElmIHRo ZSBleHByZXNzaW9uIGNoYW5nZXMsIGEgbmV3IG5hbWUgbXVzdCBiZSB1c2Vk IHRvIHRhZyB0aGUgbmV3DQoNCg0KDQpSb3Vzc2tvdiAgICAgICAgICAgICAg IEV4cGlyZXMgRmVicnVhcnkgMjksIDIwMDQgICAgICAgICAgICAgICAgW1Bh Z2UgN10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgIFA6IE1lc3NhZ2UgUHJv Y2Vzc2luZyBMYW5ndWFnZSAgICAgICAgICBBdWd1c3QgMjAwMw0KDQoNCiAg IGV4cHJlc3Npb24uIEFmdGVyIGFuIGFzc2lnbm1lbnQgc3RhdGVtZW50LCB0 aGUgdmFsdWUgb2YgdGhlIG5hbWUgaXMNCiAgIG5vdCB0aGUgdmFsdWUgb2Yg dGhlIGV4cHJlc3Npb24sIGJ1dCB0aGUgZXhwcmVzc2lvbiBpdHNlbGYuICBU aHVzLA0KICAgdGhlIGZvbGxvd2luZyB0d28gY29kZSBmcmFnbWVudHMgYXJl IGVxdWl2YWxlbnQgYW5kIG1ha2Ugbm8gc2Vuc2UgaW4NCiAgIFAgKHRoZSBm aXJzdCBmcmFnbWVudCB3b3VsZCBtYWtlIHNlbnNlIGluIGxhbmd1YWdlcyBz dWNoIGFzIEMrKyk6DQogICBoIDo9IEh0dHAubWFrZUhlYWRlcigiQ2xpZW50 LUlQIik7DQogICBoIDo9IEh0dHAubWFrZUhlYWRlcigiU2VydmVyLUlQIik7 DQoNCiAgIGggOj0gSHR0cC5tYWtlSGVhZGVyKCJDbGllbnQtSVAiKTsNCiAg IEh0dHAubWFrZUhlYWRlcigiQ2xpZW50LUlQIikgOj0gSHR0cC5tYWtlSGVh ZGVyKCJTZXJ2ZXItSVAiKTsNCg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBGaWd1cmUgOA0KDQogICBUaGUgaW50ZXJwcmV0ZXIgY2FuIGJ1 dCBkb2VzIG5vdCBoYXZlIHRvIGV2YWx1YXRlIHRoZSBleHByZXNzaW9uDQog ICBuYW1lZCBpbiB0aGUgYXNzaWdubWVudCBzdGF0ZW1lbnQgdW50aWwgdGhl IG5hbWUgaXMgYWN0dWFsbHkgdXNlZCBpbg0KICAgYW4gZXhwcmVzc2lvbiB0 aGF0IHJlcXVpcmVzIGV2YWx1YXRpb24gKGUuZy4sIGFzIGEgcGFyYW1ldGVy IG9mIGENCiAgIGZ1bmN0aW9uIGNhbGwgc3RhdGVtZW50KS4gVGhpcyBhbGxv d3MgZm9yIG9wdGlvbmFsIHBlcmZvcm1hbmNlDQogICBvcHRpbWl6YXRpb25z IHdoZXJlIG9ubHkgdXNlZCBleHByZXNzaW9ucyBhcmUgZXZhbHVhdGVkLg0K DQogICBQIGRvZXMgbm90IGhhdmUgdXNlci1kZWZpbmVkIGZ1bmN0aW9ucy4g SG93ZXZlciwgc29tZSBjb2RlIHJldXNlIGlzDQogICBwb3NzaWJsZSBiZWNh dXNlIFAgY29kZSBpcyBhIHZhbGlkIGV4cHJlc3Npb24gYW5kLCBoZW5jZSwg Y2FuIGJlDQogICBuYW1lZCBhbmQgcmV1c2VkOg0KICAgY29kZSA6PSB7IC4u LiBjb21wbGljYXRlZCBzZXJ2aWNlIGFjdGlvbiAuLi4gfTsNCiAgIGlmIChj b25kaXRpb24xKSB7IGNvZGU7IH07DQogICAuLi4NCiAgIGlmIChjb25kaXRp b24yKSB7IGNvZGU7IH07DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgRmlndXJlIDkNCg0KICAgWFhYOiBkb2N1bWVudCB3aGV0aGVyIGV4 cHJlc3Npb24gaGFzIHRvIGJlIGV2YWx1YXRlZCBpbiB0aGUNCiAgIGFzc2ln bm1lbnQgY29udGV4dCBvciB1c2UgY29udGV4dC4gRG9jdW1lbnQgbmFtZSBz Y29wZS4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNClJvdXNza292ICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAy OSwgMjAwNCAgICAgICAgICAgICAgICBbUGFnZSA4XQ0KDA0KSW50ZXJuZXQt RHJhZnQgICAgICAgUDogTWVzc2FnZSBQcm9jZXNzaW5nIExhbmd1YWdlICAg ICAgICAgIEF1Z3VzdCAyMDAzDQoNCg0KNC4gTW9kdWxlcw0KDQogICBBcHBs aWNhdGlvbi1zcGVjaWZpYyBzdXBwb3J0IGlzIGF2YWlsYWJsZSBpbiBQIHZp YSBtb2R1bGVzLiAgQmFzaWMgUA0KICAgcHJpbWl0aXZlcyBzdWNoIGFzIGlu dGVnZXIgdHlwZXMgYW5kIGJvb2xlYW4gb3BlcmF0aW9ucyBjb21wcmlzZSB0 aGUNCiAgIENvcmUgbW9kdWxlLiAgTW9kdWxlIGlzIGFuIG9iamVjdC4gVGhl IENvcmUgbW9kdWxlcyBzdXBwbGllcyB0aGUNCiAgIGZvbGxvd2luZyBtZXRo b2RzIHRvIG1hbmlwdWxhdGUgb3RoZXIgbW9kdWxlczoNCg0KICAgQ29yZS5p bXBvcnQoIk0iKTogbG9hZCBhIG1vZHVsZSBjYWxsZWQgIk0iIGFuZCByZXR1 cm4gaXQgYXMgdGhlDQogICAgICByZXN1bHQuDQoNCiAgIENvcmUubG9va3Vw KE0pOiBzdGFydCBsb29raW5nIHVwIHVucmVzb2x2ZWQgYXR0cmlidXRlcyBh bmQgbWV0aG9kDQogICAgICBpZGVudGlmaWVycyBpbiBhIHByZXZpb3VzbHkg bG9hZGVkIG1vZHVsZSBNLg0KDQogICBUaGUgQ29yZSBtb2R1bGUgaXMgYXNz dW1lZCB0byBiZSBsb2FkZWQgKGFuZCBiZWluZyBsb29rZWQgdXApIGJlZm9y ZQ0KICAgdGhlIGludGVycHJldGF0aW9uIHN0YXJ0cy4NCg0KICAgWFhYOiBk b2N1bWVudCBsb29rdXAgY29uZmxpY3QgcmVzb2x1dGlvbi4NCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KUm91c3Nrb3YgICAgICAgICAgICAgICBFeHBpcmVz IEZlYnJ1YXJ5IDI5LCAyMDA0ICAgICAgICAgICAgICAgIFtQYWdlIDldDQoM DQpJbnRlcm5ldC1EcmFmdCAgICAgICBQOiBNZXNzYWdlIFByb2Nlc3Npbmcg TGFuZ3VhZ2UgICAgICAgICAgQXVndXN0IDIwMDMNCg0KDQo1LiBPUEVTIFNl cnZpY2VzDQoNCiAgIFNlcnZpY2VzIG1vZHVsZSBjb250YWlucyBiYXNpYyBh dHRyaWJ1dGVzIGFuZCBtZXRob2RzIGZvciBzZWFyY2hpbmcNCiAgIGFuZCBl eGVjdXRpbmcgT1BFUyBzZXJ2aWNlczoNCg0KICAgU2VydmljZXMuZmluZE9u ZShVUkkpOiByZXR1cm5zIGEgc2VydmljZSBvYmplY3QgdGhhdCBjb3JyZXNw b25kcyB0bw0KICAgICAgdGhlIHNwZWNpZmllZCBVUkkuIEZhaWxzIGlmIG5v IGNvcnJlc3BvbmRpbmcgb2JqZWN0IGV4aXN0cy4NCg0KICAgU2VydmljZXMu YXBwbHlPbmUoc2VydmljZSwgLi4uKTogYXBwbGllcyB0aGUgc3BlY2lmaWVk IHNlcnZpY2UgdG8gdGhlDQogICAgICBjdXJyZW50IGFwcGxpY2F0aW9uIG1l c3NhZ2UgYW5kIG9wdGlvbmFsbHkgc3VwcGxpZXMNCiAgICAgIHNlcnZpY2Ut c3BlY2lmaWMgYXBwbGljYXRpb24gcGFyYW1ldGVycy4NCg0KICAgSGVyZSBp cyBhIHNlcnZpY2UgYXBwbGljYXRpb24gZXhhbXBsZSBmb3IgYSBHZXJtYW4g dG8gRnJlbmNoDQogICB0cmFuc2xhdGlvbiBzZXJ2aWNlOg0KICAgSHR0cCA6 PSBpbXBvcnQoIkh0dHAiKTsNCiAgIGlmIChIdHRwLnJlc3BvbnNlLmxhbmd1 YWdlX2lzKCJnZXJtYW4iKSkgew0KICAgCXNlcnZpY2UgOj0gU2VydmljZXMu ZmluZCgib3BlczovL3NlcnZpY2VzL3RyYW4vZ2VybWFuL2ZyZW5jaCIpOw0K ICAgCXNlcnZpY2UudG9EaWFsZWN0KCJzb3V0aGVybiIpOw0KICAgCVNlcnZp Y2VzLmFwcGx5KHNlcnZpY2UsIEh0dHAucmVxdWVzdC5oZWFkZXJzKTsNCiAg IH0NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAx MA0KDQogICBYWFg6IGV4cGxhaW4gaG93IGZhaWx1cmVzIGFyZSBwcm9wYWdh dGVkIGFuZCBjYW4gYmUgaGFuZGxlZA0KDQogICBYWFg6IGFkZCBDb3JlLmlu dGVycHJldGVyLnN0b3AgYW5kIENvcmUuaW50ZXJwcmV0ZXIucmVzdGFydCBt ZXRob2RzLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQpSb3Vzc2tvdiAgICAgICAgICAgICAgIEV4cGlyZXMg RmVicnVhcnkgMjksIDIwMDQgICAgICAgICAgICAgICBbUGFnZSAxMF0NCgwN CkludGVybmV0LURyYWZ0ICAgICAgIFA6IE1lc3NhZ2UgUHJvY2Vzc2luZyBM YW5ndWFnZSAgICAgICAgICBBdWd1c3QgMjAwMw0KDQoNCjYuIFNlY3VyaXR5 IENvbnNpZGVyYXRpb25zDQoNCiAgIFhYWDogZG9jdW1lbnQgbm9uLW9idmlv dXMgdnVsbmVyYWJpbGl0aWVzOiB0b28gbWFueSBuYW1lcywgdG9vIGRlZXAN CiAgIG5lc3RpbmcsIGludmFsaWQgbWF0aCwgdG9vIG11Y2ggZXJyb3IgbG9n Z2luZzsgZXhlY3V0aW9uIG9mDQogICB1bmF1dGhvcml6ZWQgc2VydmljZXMs IHVuYXV0aG9yaXplZCBleHBvc3VyZSBvZiBzZW5zaXRpdmUgaW5mb3JtYXRp b24NCiAgIHRvIGF1dGhvcml6ZWQgc2VydmljZXMuDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpSb3Vzc2tvdiAgICAg ICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjksIDIwMDQgICAgICAgICAg ICAgICBbUGFnZSAxMV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgIFA6IE1l c3NhZ2UgUHJvY2Vzc2luZyBMYW5ndWFnZSAgICAgICAgICBBdWd1c3QgMjAw Mw0KDQoNCjcuIENvbXBsaWFuY2UNCg0KICAgWFhYOiBkZWZpbmUgd2hhdCBh IGNvbXBsaWFudCBpbnRlcnByZXRlciBpcy4NCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClJvdXNza292ICAg ICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyOSwgMjAwNCAgICAgICAg ICAgICAgIFtQYWdlIDEyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgUDog TWVzc2FnZSBQcm9jZXNzaW5nIExhbmd1YWdlICAgICAgICAgIEF1Z3VzdCAy MDAzDQoNCg0KQXBwZW5kaXggQS4gRXhhbXBsZXMNCg0KICAgVGhpcyBhcHBl bmRpeCBjb250YWlucyBoYWxmLWJha2VkIGV4YW1wbGVzIHRvIGlsbHVzdHJh dGUgUCB1c2FnZSBpbg0KICAgY29tbW9uIE9QRVMgZW52aXJvbm1lbnRzLiBF eGFtcGxlIHRoZW1lcyBhcmUgdGFrZW4gZnJvbQ0KICAgW0ktRC5iZWNrLW9w ZXMtaXJtbF0gdG8gZWFzZSB0aGUgY29tcGFyaXNvbiB3aXRoIElSTUwuDQoN CiAgIEhlcmUgaXMgYSBkYXRhIHByb3ZpZGVyIGV4YW1wbGU6DQoNCiAgIGlu dGVycHJldGVyLmxhbmd1YWdlVmVyc2lvbigiMS4wIik7IC8vIGZhaWxzIGlm IGluY29tcGF0aWJsZQ0KDQogICBIdHRwIDo9IGltcG9ydCgiSHR0cCIpOw0K ICAgbG9va3VwKEh0dHApOw0KDQogICAvLyBJcyB0aGUgcmVxdWVzdGVkIHdl YiBkb2N1bWVudCBvdXIgaG9tZSBwYWdlPw0KICAgaXNIb21lIDo9IHJlcXVl c3QudXJpLmxvb2tzTGlrZUhvbWUoKTsNCg0KICAgLy8gRG9lcyB0aGUgdXNl ciBzZW5kIHVzIGEgc3BlY2lmaWMgY29va2llPw0KICAgY29va2llIDo9IG1h a2VIZWFkZXIoIkNvb2tpZSIsICJzZXc9MjMiKTsNCiAgIGhhdmVDb29raWUg Oj0gcmVxdWVzdC5oZWFkZXJzLmhhdmUoY29va2llKTsNCg0KICAgaWYgKGlz SG9tZSBhbmQgaGF2ZUNvb2tpZSkgew0KICAgCVNlcnZpY2VzIDo9IGltcG9y dCgiU2VydmljZXMiKTsNCiAgIAlzZXJ2aWNlIDo9IFNlcnZpY2VzLmZpbmRP bmUoIm9wZXM6Ly9sb2NhbC5uZXQvYWRkLWxjbC1jb250ZW50Iik7DQogICAJ c2VydmljZS5jbGllbnRJcChyZXF1ZXN0LmNsaWVudElwKTsNCiAgIAlTZXJ2 aWNlcy5hcHBseShzZXJ2aWNlKTsNCiAgIH0NCg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEZpZ3VyZSAxMQ0KDQogICBIZXJlIGlzIGEgZGF0 YSBjb25zdW1lciBleGFtcGxlOg0KDQogICBTZXJ2aWNlcyA6PSBpbXBvcnQo IlNlcnZpY2VzIik7DQogICBzZXJ2aWNlIDo9IFNlcnZpY2VzLmZpbmRPbmUo Im9wZXM6Ly9wcml2YWN5Lm5ldC9wcml2LXNlcnYiKTsNCiAgIHNlcnZpY2Uu YWN0aW9uKCJyZW1vdmUtcmVmZXJlciIpOw0KICAgU2VydmljZXMuYXBwbHko c2VydmljZSk7DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBG aWd1cmUgMTINCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpSb3Vzc2tv diAgICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjksIDIwMDQgICAg ICAgICAgICAgICBbUGFnZSAxM10NCgwNCkludGVybmV0LURyYWZ0ICAgICAg IFA6IE1lc3NhZ2UgUHJvY2Vzc2luZyBMYW5ndWFnZSAgICAgICAgICBBdWd1 c3QgMjAwMw0KDQoNCkFwcGVuZGl4IEIuIENoYW5nZSBMb2cNCg0KICAgSW50 ZXJuYWwgV0cgcmV2aXNpb24gY29udHJvbCBJRDogJElkOiBpYWItY29ucy54 bWwsdiAxLjE5IDIwMDMvMDgvMjgNCiAgIDAzOjQ4OjMyIHJvdXNza292IEV4 cCAkDQoNCiAgIEluaXRpYWwgcmV2aXNpb24uDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpSb3Vzc2tvdiAgICAgICAg ICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjksIDIwMDQgICAgICAgICAgICAg ICBbUGFnZSAxNF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgIFA6IE1lc3Nh Z2UgUHJvY2Vzc2luZyBMYW5ndWFnZSAgICAgICAgICBBdWd1c3QgMjAwMw0K DQoNCk5vcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCiAgIFtSRkMyMjM0XSAgQ3Jv Y2tlciwgRC4gYW5kIFAuIE92ZXJlbGwsICJBdWdtZW50ZWQgQk5GIGZvciBT eW50YXgNCiAgICAgICAgICAgICAgU3BlY2lmaWNhdGlvbnM6IEFCTkYiLCBS RkMgMjIzNCwgTm92ZW1iZXIgMTk5Ny4NCg0KICAgW0ktRC5pZXRmLW9wZXMt ZW5kLWNvbW1dDQogICAgICAgICAgICAgIEJhcmJpciwgQS4sICJPUEVTIHBy b2Nlc3NvciBhbmQgZW5kIHBvaW50cw0KICAgICAgICAgICAgICBjb21tdW5p Y2F0aW9ucyIsIGRyYWZ0LWlldGYtb3Blcy1lbmQtY29tbS0wMCAod29yayBp bg0KICAgICAgICAgICAgICBwcm9ncmVzcyksIEp1bmUgMjAwMy4NCg0KICAg W0ktRC5pZXRmLW9wZXMtYXJjaGl0ZWN0dXJlXQ0KICAgICAgICAgICAgICBC YXJiaXIsIEEuLCAiQW4gQXJjaGl0ZWN0dXJlIGZvciBPcGVuIFBsdWdnYWJs ZSBFZGdlDQogICAgICAgICAgICAgIFNlcnZpY2VzIChPUEVTKSIsIGRyYWZ0 LWlldGYtb3Blcy1hcmNoaXRlY3R1cmUtMDQgKHdvcmsgaW4NCiAgICAgICAg ICAgICAgcHJvZ3Jlc3MpLCBEZWNlbWJlciAyMDAyLg0KDQogICBbSS1ELmll dGYtb3Blcy1zY2VuYXJpb3NdDQogICAgICAgICAgICAgIEJhcmJpciwgQS4s ICJPUEVTIFVzZSBDYXNlcyBhbmQgRGVwbG95bWVudCBTY2VuYXJpb3MiLA0K ICAgICAgICAgICAgICBkcmFmdC1pZXRmLW9wZXMtc2NlbmFyaW9zLTAxICh3 b3JrIGluIHByb2dyZXNzKSwgQXVndXN0DQogICAgICAgICAgICAgIDIwMDIu DQoNCiAgIFtSRkMzMjM4XSAgRmxveWQsIFMuIGFuZCBMLiBEYWlnbGUsICJJ QUIgQXJjaGl0ZWN0dXJhbCBhbmQgUG9saWN5DQogICAgICAgICAgICAgIENv bnNpZGVyYXRpb25zIGZvciBPcGVuIFBsdWdnYWJsZSBFZGdlIFNlcnZpY2Vz IiwgUkZDDQogICAgICAgICAgICAgIDMyMzgsIEphbnVhcnkgMjAwMi4NCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KUm91c3Nrb3YgICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1 YXJ5IDI5LCAyMDA0ICAgICAgICAgICAgICAgW1BhZ2UgMTVdDQoMDQpJbnRl cm5ldC1EcmFmdCAgICAgICBQOiBNZXNzYWdlIFByb2Nlc3NpbmcgTGFuZ3Vh Z2UgICAgICAgICAgQXVndXN0IDIwMDMNCg0KDQpJbmZvcm1hdGl2ZSBSZWZl cmVuY2VzDQoNCiAgIFtSRkMyNjE2XSAgRmllbGRpbmcsIFIuLCBHZXR0eXMs IEouLCBNb2d1bCwgSi4sIE5pZWxzZW4sIEguLA0KICAgICAgICAgICAgICBN YXNpbnRlciwgTC4sIExlYWNoLCBQLiBhbmQgVC4gQmVybmVycy1MZWUsICJI eXBlcnRleHQNCiAgICAgICAgICAgICAgVHJhbnNmZXIgUHJvdG9jb2wgLS0g SFRUUC8xLjEiLCBSRkMgMjYxNiwgSnVuZSAxOTk5Lg0KDQogICBbSS1ELmJl Y2stb3Blcy1pcm1sXQ0KICAgICAgICAgICAgICBCZWNrLCBBLiBhbmQgTS4g SG9mbWFubiwgIklSTUw6IEEgUnVsZSBTcGVjaWZpY2F0aW9uDQogICAgICAg ICAgICAgIExhbmd1YWdlIGZvciBJbnRlcm1lZGlhcnkgU2VydmljZXMiLA0K ICAgICAgICAgICAgICBkcmFmdC1iZWNrLW9wZXMtaXJtbC0wMyAod29yayBp biBwcm9ncmVzcyksIEp1bmUgMjAwMy4NCg0KDQpBdXRob3IncyBBZGRyZXNz DQoNCiAgIEFsZXggUm91c3Nrb3YNCiAgIFRoZSBNZWFzdXJlbWVudCBGYWN0 b3J5DQoNCiAgIEVNYWlsOiByb3Vzc2tvdkBtZWFzdXJlbWVudC1mYWN0b3J5 LmNvbQ0KICAgVVJJOiAgIGh0dHA6Ly93d3cubWVhc3VyZW1lbnQtZmFjdG9y eS5jb20vDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUm91c3Nrb3YgICAgICAgICAg ICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDI5LCAyMDA0ICAgICAgICAgICAgICAg W1BhZ2UgMTZdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICBQOiBNZXNzYWdl IFByb2Nlc3NpbmcgTGFuZ3VhZ2UgICAgICAgICAgQXVndXN0IDIwMDMNCg0K DQpJbnRlbGxlY3R1YWwgUHJvcGVydHkgU3RhdGVtZW50DQoNCiAgIFRoZSBJ RVRGIHRha2VzIG5vIHBvc2l0aW9uIHJlZ2FyZGluZyB0aGUgdmFsaWRpdHkg b3Igc2NvcGUgb2YgYW55DQogICBpbnRlbGxlY3R1YWwgcHJvcGVydHkgb3Ig b3RoZXIgcmlnaHRzIHRoYXQgbWlnaHQgYmUgY2xhaW1lZCB0bw0KICAgcGVy dGFpbiB0byB0aGUgaW1wbGVtZW50YXRpb24gb3IgdXNlIG9mIHRoZSB0ZWNo bm9sb2d5IGRlc2NyaWJlZCBpbg0KICAgdGhpcyBkb2N1bWVudCBvciB0aGUg ZXh0ZW50IHRvIHdoaWNoIGFueSBsaWNlbnNlIHVuZGVyIHN1Y2ggcmlnaHRz DQogICBtaWdodCBvciBtaWdodCBub3QgYmUgYXZhaWxhYmxlOyBuZWl0aGVy IGRvZXMgaXQgcmVwcmVzZW50IHRoYXQgaXQNCiAgIGhhcyBtYWRlIGFueSBl ZmZvcnQgdG8gaWRlbnRpZnkgYW55IHN1Y2ggcmlnaHRzLiBJbmZvcm1hdGlv biBvbiB0aGUNCiAgIElFVEYncyBwcm9jZWR1cmVzIHdpdGggcmVzcGVjdCB0 byByaWdodHMgaW4gc3RhbmRhcmRzLXRyYWNrIGFuZA0KICAgc3RhbmRhcmRz LXJlbGF0ZWQgZG9jdW1lbnRhdGlvbiBjYW4gYmUgZm91bmQgaW4gQkNQLTEx LiBDb3BpZXMgb2YNCiAgIGNsYWltcyBvZiByaWdodHMgbWFkZSBhdmFpbGFi bGUgZm9yIHB1YmxpY2F0aW9uIGFuZCBhbnkgYXNzdXJhbmNlcyBvZg0KICAg bGljZW5zZXMgdG8gYmUgbWFkZSBhdmFpbGFibGUsIG9yIHRoZSByZXN1bHQg b2YgYW4gYXR0ZW1wdCBtYWRlIHRvDQogICBvYnRhaW4gYSBnZW5lcmFsIGxp Y2Vuc2Ugb3IgcGVybWlzc2lvbiBmb3IgdGhlIHVzZSBvZiBzdWNoDQogICBw cm9wcmlldGFyeSByaWdodHMgYnkgaW1wbGVtZW50b3JzIG9yIHVzZXJzIG9m IHRoaXMgc3BlY2lmaWNhdGlvbiBjYW4NCiAgIGJlIG9idGFpbmVkIGZyb20g dGhlIElFVEYgU2VjcmV0YXJpYXQuDQoNCiAgIFRoZSBJRVRGIGludml0ZXMg YW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJpbmcgdG8gaXRzIGF0dGVudGlv biBhbnkNCiAgIGNvcHlyaWdodHMsIHBhdGVudHMgb3IgcGF0ZW50IGFwcGxp Y2F0aW9ucywgb3Igb3RoZXIgcHJvcHJpZXRhcnkNCiAgIHJpZ2h0cyB3aGlj aCBtYXkgY292ZXIgdGVjaG5vbG9neSB0aGF0IG1heSBiZSByZXF1aXJlZCB0 byBwcmFjdGljZQ0KICAgdGhpcyBzdGFuZGFyZC4gUGxlYXNlIGFkZHJlc3Mg dGhlIGluZm9ybWF0aW9uIHRvIHRoZSBJRVRGIEV4ZWN1dGl2ZQ0KICAgRGly ZWN0b3IuDQoNCg0KRnVsbCBDb3B5cmlnaHQgU3RhdGVtZW50DQoNCiAgIENv cHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDMpLiBBbGwg UmlnaHRzIFJlc2VydmVkLg0KDQogICBUaGlzIGRvY3VtZW50IGFuZCB0cmFu c2xhdGlvbnMgb2YgaXQgbWF5IGJlIGNvcGllZCBhbmQgZnVybmlzaGVkIHRv DQogICBvdGhlcnMsIGFuZCBkZXJpdmF0aXZlIHdvcmtzIHRoYXQgY29tbWVu dCBvbiBvciBvdGhlcndpc2UgZXhwbGFpbiBpdA0KICAgb3IgYXNzaXN0IGlu IGl0cyBpbXBsZW1lbnRhdGlvbiBtYXkgYmUgcHJlcGFyZWQsIGNvcGllZCwg cHVibGlzaGVkDQogICBhbmQgZGlzdHJpYnV0ZWQsIGluIHdob2xlIG9yIGlu IHBhcnQsIHdpdGhvdXQgcmVzdHJpY3Rpb24gb2YgYW55DQogICBraW5kLCBw cm92aWRlZCB0aGF0IHRoZSBhYm92ZSBjb3B5cmlnaHQgbm90aWNlIGFuZCB0 aGlzIHBhcmFncmFwaCBhcmUNCiAgIGluY2x1ZGVkIG9uIGFsbCBzdWNoIGNv cGllcyBhbmQgZGVyaXZhdGl2ZSB3b3Jrcy4gSG93ZXZlciwgdGhpcw0KICAg ZG9jdW1lbnQgaXRzZWxmIG1heSBub3QgYmUgbW9kaWZpZWQgaW4gYW55IHdh eSwgc3VjaCBhcyBieSByZW1vdmluZw0KICAgdGhlIGNvcHlyaWdodCBub3Rp Y2Ugb3IgcmVmZXJlbmNlcyB0byB0aGUgSW50ZXJuZXQgU29jaWV0eSBvciBv dGhlcg0KICAgSW50ZXJuZXQgb3JnYW5pemF0aW9ucywgZXhjZXB0IGFzIG5l ZWRlZCBmb3IgdGhlIHB1cnBvc2Ugb2YNCiAgIGRldmVsb3BpbmcgSW50ZXJu ZXQgc3RhbmRhcmRzIGluIHdoaWNoIGNhc2UgdGhlIHByb2NlZHVyZXMgZm9y DQogICBjb3B5cmlnaHRzIGRlZmluZWQgaW4gdGhlIEludGVybmV0IFN0YW5k YXJkcyBwcm9jZXNzIG11c3QgYmUNCiAgIGZvbGxvd2VkLCBvciBhcyByZXF1 aXJlZCB0byB0cmFuc2xhdGUgaXQgaW50byBsYW5ndWFnZXMgb3RoZXIgdGhh bg0KICAgRW5nbGlzaC4NCg0KICAgVGhlIGxpbWl0ZWQgcGVybWlzc2lvbnMg Z3JhbnRlZCBhYm92ZSBhcmUgcGVycGV0dWFsIGFuZCB3aWxsIG5vdCBiZQ0K ICAgcmV2b2tlZCBieSB0aGUgSW50ZXJuZXQgU29jaWV0eSBvciBpdHMgc3Vj Y2Vzc29ycyBvciBhc3NpZ25lZXMuDQoNCiAgIFRoaXMgZG9jdW1lbnQgYW5k IHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGlzIHByb3ZpZGVk IG9uIGFuDQogICAiQVMgSVMiIGJhc2lzIGFuZCBUSEUgSU5URVJORVQgU09D SUVUWSBBTkQgVEhFIElOVEVSTkVUIEVOR0lORUVSSU5HDQogICBUQVNLIEZP UkNFIERJU0NMQUlNUyBBTEwgV0FSUkFOVElFUywgRVhQUkVTUyBPUiBJTVBM SUVELCBJTkNMVURJTkcNCiAgIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FS UkFOVFkgVEhBVCBUSEUgVVNFIE9GIFRIRSBJTkZPUk1BVElPTg0KDQoNCg0K Um91c3Nrb3YgICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDI5LCAy MDA0ICAgICAgICAgICAgICAgW1BhZ2UgMTddDQoMDQpJbnRlcm5ldC1EcmFm dCAgICAgICBQOiBNZXNzYWdlIFByb2Nlc3NpbmcgTGFuZ3VhZ2UgICAgICAg ICAgQXVndXN0IDIwMDMNCg0KDQogICBIRVJFSU4gV0lMTCBOT1QgSU5GUklO R0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElFRCBXQVJSQU5USUVTIE9GDQog ICBNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFS IFBVUlBPU0UuDQoNCg0KQWNrbm93bGVkZ2VtZW50DQoNCiAgIEZ1bmRpbmcg Zm9yIHRoZSBSRkMgRWRpdG9yIGZ1bmN0aW9uIGlzIGN1cnJlbnRseSBwcm92 aWRlZCBieSB0aGUNCiAgIEludGVybmV0IFNvY2lldHkuDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClJvdXNza292ICAgICAg ICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyOSwgMjAwNCAgICAgICAgICAg ICAgIFtQYWdlIDE4XQ0KDA0K --0-893559119-1062480914=:41427-- From owner-ietf-openproxy@mail.imc.org Tue Sep 2 11:59:14 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10777 for ; Tue, 2 Sep 2003 11:59:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uDYs-0006Q7-00 for opes-archive@ietf.org; Tue, 02 Sep 2003 11:59:18 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19uDYr-0006Q4-00 for opes-archive@ietf.org; Tue, 02 Sep 2003 11:59:17 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82Fiegc025197 for ; Tue, 2 Sep 2003 08:44:40 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h82Fiews025196 for ietf-openproxy-bks; Tue, 2 Sep 2003 08:44:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82Ficgc025182 for ; Tue, 2 Sep 2003 08:44:39 -0700 (PDT) (envelope-from markus@mhof.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h82Fid9Y053707 for ; Tue, 2 Sep 2003 11:44:39 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h82FiX2e019059 for ; Tue, 2 Sep 2003 11:44:33 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h82FiWFU001340 for ; Tue, 2 Sep 2003 11:44:32 -0400 (EDT) Message-ID: <3F54BB3E.3070604@mhof.com> Date: Tue, 02 Sep 2003 11:46:06 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES WG Subject: Re: moving along on rules language References: <20030822115516.4abe1229.mrose@dbc.mtview.ca.us> <20030822140828.168c71e3.mrose@dbc.mtview.ca.us> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Alex - I'd suggest you publish this as individual ID right away rather than just having a URL as reference. Would give us all a formal reference for the document. All - please have a look at Alex proposal and at the IRML draft (Andre is working on an updated version addressing Alex comments, but he's on vacation this week, and the general approach behind IRML should be clear from the current draft-beck-opes-irml-03.txt). We need to decide on how to move forward and whether to adopt one of the documents as WG draft. Please comment on the list. Thanks, Markus Alex Rousskov wrote: >>On Fri, 22 Aug 2003, Marshall Rose wrote: >> >>great. if your confident with an alternative approach, put an >>initial document together and submit it. i don't want to forestall >>alternatives, but we need to be wrapping things up. > > > An alternative draft is attached in plain text. HTML rendering is at > http://www.measurement-factory.com/tmp/opes/snapshots/current/p.html > > As we discussed, this draft is not as detailed or as polished as the > IRML draft. The draft purpose is to illustrate the "killer idea" > behind the alternative approach: a minimalistic and efficient > configuration language designed specifically for the problem domain, > but with a room to grow. See draft introduction for more detailed > treatment of design goals. > > I hope this draft is sufficient to pick one direction over the other, > but I would be happy to clarify or add as needed, of course. I do > realize that there has been a lot more work put into IRML already. I > wish I knew about its existence earlier. If nothing else, this draft > is probably the ultimate form of "constructive comments" IRML folks > are asking for :-). > > On the positive side, many IRML ideas/developments can be easily > reused if an alternative approach is chosen. The reverse is probably > not as true because P capitalizes on being a language rather than a > hierarchical collection of attributes (but it is all relative and > equivalent from Turing point of view, of course). > > HTH, > > Alex. > > P.S. If "P" is already taken as a language name, please let me know. > My quick search yielded no matches. "PL" does not count, IMHO. > > > ------------------------------------------------------------------------ > > > > Open Pluggable Edge Services A. Rousskov > Internet-Draft The Measurement Factory > Expires: February 29, 2004 August 31, 2003 > > > P: Message Processing Language > draft-rousskov-opes-rules > > Status of this Memo > > This document is an Internet-Draft and is in full conformance with > all provisions of Section 10 of RFC2026. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that other > groups may also distribute working documents as Internet-Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at http:// > www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on February 29, 2004. > > Copyright Notice > > Copyright (C) The Internet Society (2003). All Rights Reserved. > > Abstract > > P is a simple configuration language designed for efficient and > compact specification of message processing instructions at > application proxies. P can be used to instruct an intermediary how to > manipulate the application message being proxied. Such instructions > needed in an Open Pluggable Edge Services (OPES) context. > > > > > > > > > > > > Rousskov Expires February 29, 2004 [Page 1] > > Internet-Draft P: Message Processing Language August 2003 > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 > 3. Language elements . . . . . . . . . . . . . . . . . . . . . . 6 > 3.1 Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 > 3.2 Statements . . . . . . . . . . . . . . . . . . . . . . . . . . 6 > 3.3 Expressions . . . . . . . . . . . . . . . . . . . . . . . . . 6 > 3.4 Assignments . . . . . . . . . . . . . . . . . . . . . . . . . 7 > 4. Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 > 5. OPES Services . . . . . . . . . . . . . . . . . . . . . . . . 10 > 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 > 7. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 12 > A. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 > B. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 14 > Normative References . . . . . . . . . . . . . . . . . . . . . 15 > Informative References . . . . . . . . . . . . . . . . . . . . 16 > Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16 > Intellectual Property and Copyright Statements . . . . . . . . 17 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Rousskov Expires February 29, 2004 [Page 2] > > Internet-Draft P: Message Processing Language August 2003 > > > 1. Introduction > > The Open Pluggable Edge Services (OPES) architecture > [I-D.ietf-opes-architecture], enables cooperative application > services (OPES services) between a data provider, a data consumer, > and zero or more OPES processors. The application services under > consideration analyze and possibly transform application-level > messages exchanged between the data provider and the data consumer. > OPES processors need to be told what services are to be applied to > what application messages. P language can be used for this > configuration task. > > In other words, P language primary objective is to express statements > similar to: > if message meets criteria C, > then apply service S; > > Figure 1 > > Thus, P programs mostly deal with how formulating message-dependent > conditions and executing services. > > P design attempts to satisfy several conflicting goals: > > flexibility: OPES intermediaries deal with a wide range of > applications and protocols (SMTP, HTTP, RTSP, IM, etc.). The > language must be able to accommodate virtually all known tasks in > selecting a desired adaptation service for a message of a known > application protocol (and conceivable future applications). > > efficiency: Language interpretation must be efficient enough to be > comparable with other message processing overheads at a typical > application proxy (e.g., interpreting HTTP headers to determine > response cachability). > > simplicity: Typical configurations must be easy to write and > understand for a typical OPES system administrator. > > correctness: Many message handling configurations are written without > direct access to intermediaries that will use those > configurations. The extent of off-line (compile-time) correctness > checks should catch all syntax errors and many common semantic > errors such as undefined values and type conflicts. > > compactness: It is possible that some processing instructions will be > piggybacked as headers/metadata to messages they refer to, placing > stringent size requirements on language code. > > > > > Rousskov Expires February 29, 2004 [Page 3] > > Internet-Draft P: Message Processing Language August 2003 > > > security: It should be difficult if not impossible to write malicious > code that would result in security vulnerability of compliant > language interpreter. > > P design is based on a minimal useful subset of features from several > programming languages such as R (S) and Smalltalk. Technically > speaking, P is a single-assignment, lazy evaluation, strongly typed > functional programming language. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Rousskov Expires February 29, 2004 [Page 4] > > Internet-Draft P: Message Processing Language August 2003 > > > 2. Syntax > > P syntax is defined by the following Augmented Backus-Naur Form > (ABNF) [RFC2234]: > > code = *(statement ";") > > statement = assignment / function-call / if-statement > > assignment = identifier ":=" expression > > if-statement = "if" "(" expression ")" "{" code "}" > > expression = > name / function-call / "{" code "}" > ... ; more to be defined (logical and arithmetic expressions) > > name = identifier *( "." identifier) > > function-call = name "(" [params] ")" > > params = expression *( "," expression) > > identifier = ALPHA *(ALPHA / DIGIT / "_") > > ... ; more primitives to be defined as needed > > > Figure 2 > > XXX: add /* comments */ and // comments. > > > > > > > > > > > > > > > > > > > > > Rousskov Expires February 29, 2004 [Page 5] > > Internet-Draft P: Message Processing Language August 2003 > > > 3. Language elements > > 3.1 Objects > > P is centered around the concept of an "object" that is similar to > objects from other object-oriented languages. An object is a > collection of object members: attributes and methods. Attributes are > named slots that store other objects. Methods are named pieces of > code that manipulate the object they belong to or other objects. P > objects are identified by their names (e.g., Http or tmp). Attributes > and methods are accessed via their names using the dot (".") operator > applied to a named object. For example, Http.message.headers > expression accesses (names) headers inside a message inside the HTTP > module. Everything that can be named in P is an object. Some objects > may not have any members. > > P does not have facilities for describing objects. When writing a P > program, only objects supported by the interpretor can be used and no > new objects can be added. P supports loadable modules that can be > used to add objects to support new application protocols. In fact, P > core supports no application protocols directly. Instead, modules > like "Http" can be used to process messages depending on application > protocol being proxied. > > All P objects have types and no default (silent) type conversion is > supported. However, explicit type conversion (casting) is rarely > needed because many object methods are polymorphic (accept several > types). > service := Services.findOne("http://iana.org/opes/services/example"); > > Figure 3 > > > 3.2 Statements > > Objects are manipulated using if-statements and function-calls. > > if (Http.request.method == "GET") { > Core.execService(service); > } > > Figure 4 > > > 3.3 Expressions > > P expressions are used in if-statements to specify the condition for > the if-statement body to be interpreted. > > > > Rousskov Expires February 29, 2004 [Page 6] > > Internet-Draft P: Message Processing Language August 2003 > > > if (Http.request.method == "GET" and time.current() > time.noon) { > ... > } > > Figure 5 > > Binary operators such as "==" or "+" are not global special symbols > but are passed to the object on the left for interpretation, along > with the expression on the right. Applying a binary operator is > semantically equivalent to calling an object method. For example, the > following two expressions are equivalent: > a + b + c > (a.+(b)) + c > (a.+(b)).+(c) > > Figure 6 > > The "a + b + c" form is preferred for purely visual reasons. Core P > module provides basic objects and operators for them (e.g., boolean > and integer). Application-specific modules usually provide > applications-specific objects; those objects usually have > application-specific methods and may not have methods to support > operations common for basic types. For example, an Http module > supplies an HTTP header object that does not have a "*" method. > > XXX: define operator precedence, if any. > > 3.4 Assignments > > Most procedural programming languages use variables to store > intermediate processing results. In such languages, a variable is > essentially a named piece of memory that can be assigned a value and > can be updated with new values as needed. P does not have such > variables. Instead, P uses a "single assignment" approach: an > expression can be tagged with a name and that name can be reused many > times in the program. On the surface, this is equivalent to having > all "traditional" variables declared as "constant". The following two > if-statements are semantically equivalent in P: > > if (Http.request.headers.have(Http.makeHeader("Client-IP"))) {...} > > h := Http.makeHeader("Client-IP"); > hs := Http.request.headers(); > if (hs.have(h) {...} > > Figure 7 > > If the expression changes, a new name must be used to tag the new > > > > Rousskov Expires February 29, 2004 [Page 7] > > Internet-Draft P: Message Processing Language August 2003 > > > expression. After an assignment statement, the value of the name is > not the value of the expression, but the expression itself. Thus, > the following two code fragments are equivalent and make no sense in > P (the first fragment would make sense in languages such as C++): > h := Http.makeHeader("Client-IP"); > h := Http.makeHeader("Server-IP"); > > h := Http.makeHeader("Client-IP"); > Http.makeHeader("Client-IP") := Http.makeHeader("Server-IP"); > > Figure 8 > > The interpreter can but does not have to evaluate the expression > named in the assignment statement until the name is actually used in > an expression that requires evaluation (e.g., as a parameter of a > function call statement). This allows for optional performance > optimizations where only used expressions are evaluated. > > P does not have user-defined functions. However, some code reuse is > possible because P code is a valid expression and, hence, can be > named and reused: > code := { ... complicated service action ... }; > if (condition1) { code; }; > ... > if (condition2) { code; }; > > Figure 9 > > XXX: document whether expression has to be evaluated in the > assignment context or use context. Document name scope. > > > > > > > > > > > > > > > > > > > > > > Rousskov Expires February 29, 2004 [Page 8] > > Internet-Draft P: Message Processing Language August 2003 > > > 4. Modules > > Application-specific support is available in P via modules. Basic P > primitives such as integer types and boolean operations comprise the > Core module. Module is an object. The Core modules supplies the > following methods to manipulate other modules: > > Core.import("M"): load a module called "M" and return it as the > result. > > Core.lookup(M): start looking up unresolved attributes and method > identifiers in a previously loaded module M. > > The Core module is assumed to be loaded (and being looked up) before > the interpretation starts. > > XXX: document lookup conflict resolution. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Rousskov Expires February 29, 2004 [Page 9] > > Internet-Draft P: Message Processing Language August 2003 > > > 5. OPES Services > > Services module contains basic attributes and methods for searching > and executing OPES services: > > Services.findOne(URI): returns a service object that corresponds to > the specified URI. Fails if no corresponding object exists. > > Services.applyOne(service, ...): applies the specified service to the > current application message and optionally supplies > service-specific application parameters. > > Here is a service application example for a German to French > translation service: > Http := import("Http"); > if (Http.response.language_is("german")) { > service := Services.find("opes://services/tran/german/french"); > service.toDialect("southern"); > Services.apply(service, Http.request.headers); > } > > Figure 10 > > XXX: explain how failures are propagated and can be handled > > XXX: add Core.interpreter.stop and Core.interpreter.restart methods. > > > > > > > > > > > > > > > > > > > > > > > > > > Rousskov Expires February 29, 2004 [Page 10] > > Internet-Draft P: Message Processing Language August 2003 > > > 6. Security Considerations > > XXX: document non-obvious vulnerabilities: too many names, too deep > nesting, invalid math, too much error logging; execution of > unauthorized services, unauthorized exposure of sensitive information > to authorized services. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Rousskov Expires February 29, 2004 [Page 11] > > Internet-Draft P: Message Processing Language August 2003 > > > 7. Compliance > > XXX: define what a compliant interpreter is. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Rousskov Expires February 29, 2004 [Page 12] > > Internet-Draft P: Message Processing Language August 2003 > > > Appendix A. Examples > > This appendix contains half-baked examples to illustrate P usage in > common OPES environments. Example themes are taken from > [I-D.beck-opes-irml] to ease the comparison with IRML. > > Here is a data provider example: > > interpreter.languageVersion("1.0"); // fails if incompatible > > Http := import("Http"); > lookup(Http); > > // Is the requested web document our home page? > isHome := request.uri.looksLikeHome(); > > // Does the user send us a specific cookie? > cookie := makeHeader("Cookie", "sew=23"); > haveCookie := request.headers.have(cookie); > > if (isHome and haveCookie) { > Services := import("Services"); > service := Services.findOne("opes://local.net/add-lcl-content"); > service.clientIp(request.clientIp); > Services.apply(service); > } > > Figure 11 > > Here is a data consumer example: > > Services := import("Services"); > service := Services.findOne("opes://privacy.net/priv-serv"); > service.action("remove-referer"); > Services.apply(service); > > Figure 12 > > > > > > > > > > > > > > > Rousskov Expires February 29, 2004 [Page 13] > > Internet-Draft P: Message Processing Language August 2003 > > > Appendix B. Change Log > > Internal WG revision control ID: $Id: iab-cons.xml,v 1.19 2003/08/28 > 03:48:32 rousskov Exp $ > > Initial revision. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Rousskov Expires February 29, 2004 [Page 14] > > Internet-Draft P: Message Processing Language August 2003 > > > Normative References > > [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax > Specifications: ABNF", RFC 2234, November 1997. > > [I-D.ietf-opes-end-comm] > Barbir, A., "OPES processor and end points > communications", draft-ietf-opes-end-comm-00 (work in > progress), June 2003. > > [I-D.ietf-opes-architecture] > Barbir, A., "An Architecture for Open Pluggable Edge > Services (OPES)", draft-ietf-opes-architecture-04 (work in > progress), December 2002. > > [I-D.ietf-opes-scenarios] > Barbir, A., "OPES Use Cases and Deployment Scenarios", > draft-ietf-opes-scenarios-01 (work in progress), August > 2002. > > [RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy > Considerations for Open Pluggable Edge Services", RFC > 3238, January 2002. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Rousskov Expires February 29, 2004 [Page 15] > > Internet-Draft P: Message Processing Language August 2003 > > > Informative References > > [RFC2616] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., > Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext > Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. > > [I-D.beck-opes-irml] > Beck, A. and M. Hofmann, "IRML: A Rule Specification > Language for Intermediary Services", > draft-beck-opes-irml-03 (work in progress), June 2003. > > > Author's Address > > Alex Rousskov > The Measurement Factory > > EMail: rousskov@measurement-factory.com > URI: http://www.measurement-factory.com/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Rousskov Expires February 29, 2004 [Page 16] > > Internet-Draft P: Message Processing Language August 2003 > > > Intellectual Property Statement > > The IETF takes no position regarding the validity or scope of any > intellectual property or other rights that might be claimed to > pertain to the implementation or use of the technology described in > this document or the extent to which any license under such rights > might or might not be available; neither does it represent that it > has made any effort to identify any such rights. Information on the > IETF's procedures with respect to rights in standards-track and > standards-related documentation can be found in BCP-11. Copies of > claims of rights made available for publication and any assurances of > licenses to be made available, or the result of an attempt made to > obtain a general license or permission for the use of such > proprietary rights by implementors or users of this specification can > be obtained from the IETF Secretariat. > > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary > rights which may cover technology that may be required to practice > this standard. Please address the information to the IETF Executive > Director. > > > Full Copyright Statement > > Copyright (C) The Internet Society (2003). All Rights Reserved. > > This document and translations of it may be copied and furnished to > others, and derivative works that comment on or otherwise explain it > or assist in its implementation may be prepared, copied, published > and distributed, in whole or in part, without restriction of any > kind, provided that the above copyright notice and this paragraph are > included on all such copies and derivative works. However, this > document itself may not be modified in any way, such as by removing > the copyright notice or references to the Internet Society or other > Internet organizations, except as needed for the purpose of > developing Internet standards in which case the procedures for > copyrights defined in the Internet Standards process must be > followed, or as required to translate it into languages other than > English. > > The limited permissions granted above are perpetual and will not be > revoked by the Internet Society or its successors or assignees. > > This document and the information contained herein is provided on an > "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING > TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING > BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION > > > > Rousskov Expires February 29, 2004 [Page 17] > > Internet-Draft P: Message Processing Language August 2003 > > > HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF > MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > Acknowledgement > > Funding for the RFC Editor function is currently provided by the > Internet Society. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Rousskov Expires February 29, 2004 [Page 18] > From owner-ietf-openproxy@mail.imc.org Tue Sep 2 13:11:36 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15986 for ; Tue, 2 Sep 2003 13:11:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uEgt-0000O5-00 for opes-archive@ietf.org; Tue, 02 Sep 2003 13:11:39 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19uEgs-0000Nu-00 for opes-archive@ietf.org; Tue, 02 Sep 2003 13:11:38 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82Gvhgc030367 for ; Tue, 2 Sep 2003 09:57:43 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h82Gvh6B030366 for ietf-openproxy-bks; Tue, 2 Sep 2003 09:57:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82Gvfgc030357 for ; Tue, 2 Sep 2003 09:57:41 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h82Gvhqh046219 for ; Tue, 2 Sep 2003 10:57:43 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h82Gvh0a046218; Tue, 2 Sep 2003 10:57:43 -0600 (MDT) (envelope-from rousskov) Date: Tue, 2 Sep 2003 10:57:43 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: Re: moving along on rules language In-Reply-To: <3F54BB3E.3070604@mhof.com> Message-ID: References: <20030822115516.4abe1229.mrose@dbc.mtview.ca.us> <20030822140828.168c71e3.mrose@dbc.mtview.ca.us> <3F54BB3E.3070604@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 2 Sep 2003, Markus Hofmann wrote: > Alex - I'd suggest you publish this as individual ID right away > rather than just having a URL as reference. Would give us all a > formal reference for the document. Submitted with minor polishing touches. Alex. From owner-ietf-openproxy@mail.imc.org Wed Sep 10 06:38:24 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25030 for ; Wed, 10 Sep 2003 06:38:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x2Mn-0002fP-00 for opes-archive@ietf.org; Wed, 10 Sep 2003 06:38:29 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19x2Mm-0002fL-00 for opes-archive@ietf.org; Wed, 10 Sep 2003 06:38:28 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8AAOqeo012387 for ; Wed, 10 Sep 2003 03:24:52 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8AAOqb6012386 for ietf-openproxy-bks; Wed, 10 Sep 2003 03:24:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail2.webwasher.com ([213.70.80.10]) by above.proper.com (8.12.9/8.12.8) with SMTP id h8AAOoeo012357 for ; Wed, 10 Sep 2003 03:24:51 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] id 2USY9AMY; 10 Sep 2003 14:31:37 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: moving along on rules language X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 10 Sep 2003 12:24:39 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D0551C3@mail.webwasher.com> Thread-Topic: moving along on rules language Thread-Index: AcNxd6f8QEYlGk7IR2OoruHGbIwMTQGCqpAw From: "Martin Stecher" To: "OPES WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h8AAOpeo012382 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi, back from holiday I just read draft-rousskov-opes-rules-00 quickly. In a first reaction, it makes a lot of sense to me and I find it easier to understand and more powerful than IRML. Though I have a little problem with the example in Figure 10: "toDialect" is a term that is very specific for the selected service. Does this example assume that "toDialect" is a supported term of standard P or how could a service dynamically add new identifiers and functions calls? While I can follow Alex comments about IRML and like P better than IRML in the moment, I admit that I did not deal a lot with the rule language requirements all the time, so I may oversea important aspects. I would very much appreciate if an IRML advocate (Andre?!?) could comment on Alex draft and list problems and aspects that IRML solves better. Such as Alex did before with IRML. Regards Martin > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Tuesday, September 02, 2003 6:58 PM > To: OPES WG > Subject: Re: moving along on rules language > > > > > On Tue, 2 Sep 2003, Markus Hofmann wrote: > > > Alex - I'd suggest you publish this as individual ID right away > > rather than just having a URL as reference. Would give us all a > > formal reference for the document. > > Submitted with minor polishing touches. > > Alex. > > ------------------------------------------------------------ > This mail has been scanned by debian3-smtp > (WebWasher 4.4.1 fcs Build 580) > ------------------------------------------------------------ > From owner-ietf-openproxy@mail.imc.org Wed Sep 10 08:55:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28054 for ; Wed, 10 Sep 2003 08:55:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x4Vt-0003c3-00 for opes-archive@ietf.org; Wed, 10 Sep 2003 08:56:01 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19x4Vs-0003c0-00 for opes-archive@ietf.org; Wed, 10 Sep 2003 08:56:00 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8ACkDeo040072 for ; Wed, 10 Sep 2003 05:46:13 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8ACkDEh040071 for ietf-openproxy-bks; Wed, 10 Sep 2003 05:46:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8ACkBeo040063 for ; Wed, 10 Sep 2003 05:46:11 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h8ACkCVH024406; Wed, 10 Sep 2003 06:46:12 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h8ACkBhl024405; Wed, 10 Sep 2003 06:46:11 -0600 (MDT) (envelope-from rousskov) Date: Wed, 10 Sep 2003 06:46:11 -0600 (MDT) From: Alex Rousskov To: Martin Stecher cc: OPES WG Subject: RE: moving along on rules language In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D0551C3@mail.webwasher.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D0551C3@mail.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 10 Sep 2003, Martin Stecher wrote: > Though I have a little problem with the example in Figure 10: > "toDialect" is a term that is very specific for the selected > service. Does this example assume that "toDialect" is a supported > term of standard P or how could a service dynamically add new > identifiers and functions calls? You have asked a very important question. P "as is" supports only a few "terms" or objects methods -- those defined in Core and Services modules. Everything else is provided by other modules that are, essentially, extensions. When P interpreter finds an expression like .() it passes the name of the method to that other module/object to handle. P Core does not know a priory whether the other object supports that method, but there is an interface that allows modules to report unsupported errors back to Core. The above scheme allows P modules like Http or Smtp to evolve without affecting P Core. I believe it can be implemented efficiently. The same trick can probably be applied to services. Any service will be implemented as an internal program or some kind of callout service (via OCP, SOAP, or whatever). For OCP, we will document how to map service.method-name(params) call to something that OCP callout service can understand. This trick will allow services to evolve without affecting P Core. If we find it is too much overhead/complexity to support this marshaling, we will restrict services to a few well-known and general-enough methods. Hope this clarifies, Alex. From owner-ietf-openproxy@mail.imc.org Wed Sep 10 10:22:44 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01592 for ; Wed, 10 Sep 2003 10:22:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x5ru-0004BX-00 for opes-archive@ietf.org; Wed, 10 Sep 2003 10:22:50 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19x5rt-0004BU-00 for opes-archive@ietf.org; Wed, 10 Sep 2003 10:22:49 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8AE8peo050369 for ; Wed, 10 Sep 2003 07:08:51 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8AE8oTv050368 for ietf-openproxy-bks; Wed, 10 Sep 2003 07:08:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8AE8neo050362 for ; Wed, 10 Sep 2003 07:08:50 -0700 (PDT) (envelope-from abeck@bell-labs.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h8AE8oHa013450; Wed, 10 Sep 2003 10:08:50 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h8AE8h2e011259; Wed, 10 Sep 2003 10:08:43 -0400 (EDT) Received: from bell-labs.com (abeck.lra.lucent.com [192.11.61.196]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h8AE8gFU003265; Wed, 10 Sep 2003 10:08:43 -0400 (EDT) Message-ID: <3F5F306B.2020908@bell-labs.com> Date: Wed, 10 Sep 2003 10:08:43 -0400 From: Andre Beck User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Stecher CC: OPES WG Subject: Re: moving along on rules language References: <75F7E67FC45F6744A7D328D41E35376D0551C3@mail.webwasher.com> In-Reply-To: <75F7E67FC45F6744A7D328D41E35376D0551C3@mail.webwasher.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi, I also came back from vacation this week and just had a quick look at P. I still don't believe that the problem we are trying to solve calls for a (albeit limited) programming language like P. In fact, I think a rule module written in P would be more difficult to understand and write by people who don't already have experience with programming languages. What I like about an XML-based language like IRML is that by design it limits the complexity of rule modules. IRML rule modules can be represented as well es edited graphically (using a generic XML editor) in a tree where nodes represent rule conditions and leaves resulting actions. I think such a representation would be more intuitive and easier to understand than a piece of P code. Also, when editing IRML rules generic XML editors can provide rule authors with immediate feedback if rule modules violate the IRML DTD or XML syntax. I don't think this can be easily done with P. I also don't agree with all of the design goals that Alex lists in the introction to P. For example, I don't see a need for the rule language to be so compact and efficient that it can be interpreted on the fly. I cannot imagine that an ISP would let an OPES system process arbitrary rules in real time as it receives them from data providers/consumers. I think there will have to be an offline validation and optimization step. That way the OPES system can rewrite or throw out inefficient or malicious rule modules that would slow down the OPES system excessively or unnecessarily otherwise. That having said, I believe that there is still a lot of potential to further improve IRML if the WG decides to pursue an XML-based rule language. For example, CPL (which solves a very similar problem in the IP tel. space and is also XML-based) has a mechanism that allows CPL script authors to easily re-use parts of a CPL script through a reference to it. I would be willing to work on a new IRML draft version to incorporate such a mechanism as well as address some of Alex' comments on IRML. I guess what is needed at this time is for more people on the list to speak up and voice their opinion on the two rule language proposals. -Andre Martin Stecher wrote: > Hi, > > back from holiday I just read draft-rousskov-opes-rules-00 quickly. > > In a first reaction, it makes a lot of sense to me and I find it easier to understand and more powerful than IRML. > > Though I have a little problem with the example in Figure 10: > "toDialect" is a term that is very specific for the selected service. > Does this example assume that "toDialect" is a supported term of standard P or how could a service dynamically add new identifiers and functions calls? > > While I can follow Alex comments about IRML and like P better than IRML in the moment, I admit that I did not deal a lot with the rule language requirements all the time, so I may oversea important aspects. > > I would very much appreciate if an IRML advocate (Andre?!?) could comment on Alex draft and list problems and aspects that IRML solves better. Such as Alex did before with IRML. > > Regards > Martin > > >>-----Original Message----- >>From: Alex Rousskov [mailto:rousskov@measurement-factory.com] >>Sent: Tuesday, September 02, 2003 6:58 PM >>To: OPES WG >>Subject: Re: moving along on rules language >> >> >> >> >>On Tue, 2 Sep 2003, Markus Hofmann wrote: >> >> >>>Alex - I'd suggest you publish this as individual ID right away >>>rather than just having a URL as reference. Would give us all a >>>formal reference for the document. >> >>Submitted with minor polishing touches. >> >>Alex. >> >>------------------------------------------------------------ >>This mail has been scanned by debian3-smtp >>(WebWasher 4.4.1 fcs Build 580) >>------------------------------------------------------------ >> From owner-ietf-openproxy@mail.imc.org Wed Sep 10 11:12:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03348 for ; Wed, 10 Sep 2003 11:12:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x6eW-0004ce-00 for opes-archive@ietf.org; Wed, 10 Sep 2003 11:13:04 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19x6eW-0004cb-00 for opes-archive@ietf.org; Wed, 10 Sep 2003 11:13:04 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8AEx8eo061843 for ; Wed, 10 Sep 2003 07:59:08 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8AEx8ah061842 for ietf-openproxy-bks; Wed, 10 Sep 2003 07:59:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8AEx6eo061830 for ; Wed, 10 Sep 2003 07:59:07 -0700 (PDT) (envelope-from markus@mhof.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h8AEx79Y031777 for ; Wed, 10 Sep 2003 10:59:07 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h8AEx12e019604 for ; Wed, 10 Sep 2003 10:59:01 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h8AEx0FU004712 for ; Wed, 10 Sep 2003 10:59:00 -0400 (EDT) Message-ID: <3F5F3C94.3090609@mhof.com> Date: Wed, 10 Sep 2003 11:00:36 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES WG Subject: Re: moving along on rules language References: <75F7E67FC45F6744A7D328D41E35376D0551C3@mail.webwasher.com> <3F5F306B.2020908@bell-labs.com> In-Reply-To: <3F5F306B.2020908@bell-labs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Andre Beck wrote: > [...] I guess what is needed at this time is for more people > on the list to speak up and voice their opinion on the two rule language > proposals. Folks, this is exactly what we need - we need to get consensus on which approach to follow - and we need to get that ASAP. We were expected to have an iniial rules WG document in August! Real conensus can only be achieved if more people take the time and look at both approaches and communicate their thoughts. So, please start-up your email clients and post your thoughts. Thanks, Markus From owner-ietf-openproxy@mail.imc.org Wed Sep 10 11:25:34 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03723 for ; Wed, 10 Sep 2003 11:25:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x6qh-0004la-00 for opes-archive@ietf.org; Wed, 10 Sep 2003 11:25:39 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19x6qh-0004lX-00 for opes-archive@ietf.org; Wed, 10 Sep 2003 11:25:39 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8AFBreo064735 for ; Wed, 10 Sep 2003 08:11:53 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8AFBrQ5064733 for ietf-openproxy-bks; Wed, 10 Sep 2003 08:11:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail02.powweb.com (mail02.powweb.com [63.251.216.35]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8AFBqeo064725 for ; Wed, 10 Sep 2003 08:11:52 -0700 (PDT) (envelope-from lee@isoeasy.com) Received: from leecoxv2qdje8b (bgp599974bgs.midltn01.nj.comcast.net [68.39.49.47]) by mail02.powweb.com (Postfix) with ESMTP id 9A3A2DEF8A for ; Wed, 10 Sep 2003 08:20:24 -0700 (PDT) Message-ID: <0a0701c377ad$e2048360$0500a8c0@leecoxv2qdje8b> From: "Lee Beaumont" To: "OPES WG" Subject: Fw: Divide and Conquer Date: Wed, 10 Sep 2003 11:11:58 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0A04_01C3778C.59C42760" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0A04_01C3778C.59C42760 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am interested in the IRML vs. P debate going on here. With the = proposal of P I believe Alex has tackled two problems at once. Perhaps = if these are separated, more clarity can lead to more progress. The two = problems I see being confounded and addressed are: 1) What style syntax should be used in the language?, and 2) What expressive power should be allowed. These issues go to the root of the requirements for a rules language, = and also involve some parochial preferences. Regarding syntax, people naturally have a prejudice toward either a = verbose (e.g. COBOL and XML) style of syntax, or a preference for a = terse style (e.g. C and its derivatives, like java and P). My preference = is for the terse "C" style, and I believe the success of "C" gives some = broader support to that preference. Perhaps this debate over syntax = style can be put on a more objective footing by examining: 1) Ease of writing,=20 2) Ease of (human) reading, 3) Availability of editors, visulaizers, and verifiers. 4) ease of machine interpretation, including speed, and size Related to expressive power, I believe the debate needs to focus first = on the types of rules that need to be expressed. For example, can the WG = establish a "working set" of "pseudo code (or structured English) rules = that need to be accommodated. This might include access control , = Anonymization, local preferences, natural language translation and other = examples chosen from the OPES documents. Then this working set can be = expressed (or not) in IRML and P and the results compared. I hope this is helpful Lee Beaumont ------=_NextPart_000_0A04_01C3778C.59C42760 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I am interested in the IRML vs. P = debate going on=20 here. With the proposal of P I believe Alex has tackled two problems at = once.=20 Perhaps if these are separated, more clarity can lead to more progress. = The two=20 problems I see being confounded and addressed are:
1) What style syntax should be used in = the=20 language?, and
2) What expressive power should be=20 allowed.
 
These issues go to the root of the = requirements for a rules language, and also involve some parochial=20 preferences.
 
Regarding syntax, people naturally have = a prejudice toward either a verbose (e.g. COBOL and XML) style = of=20 syntax, or a preference for a terse style (e.g. C and its derivatives, = like java=20 and P). My preference is for the terse "C" style, and I believe the = success of=20 "C" gives some broader support to that preference. Perhaps this = debate over=20 syntax style can be put on a more objective footing=20 by examining:
1) Ease of writing,
2) Ease of (human) = reading,
3) Availability of editors, = visulaizers, and=20 verifiers.
4) ease of machine interpretation, = including speed,=20 and size
 
Related to expressive power, I believe = the debate=20 needs to focus first on the types of rules that need to be expressed. = For=20 example, can the WG establish a "working set" of "pseudo code (or = structured=20 English) rules that need to be accommodated. This might include access = control ,=20 Anonymization, local preferences, natural language translation and other = examples chosen from the OPES documents. Then this working set can be = expressed=20 (or not) in IRML and P and the results compared.
 
I hope this is helpful
 
Lee Beaumont
 
 
------=_NextPart_000_0A04_01C3778C.59C42760-- From owner-ietf-openproxy@mail.imc.org Wed Sep 10 13:12:42 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08478 for ; Wed, 10 Sep 2003 13:12:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x8WO-0006lu-00 for opes-archive@ietf.org; Wed, 10 Sep 2003 13:12:48 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19x8WN-0006ln-00 for opes-archive@ietf.org; Wed, 10 Sep 2003 13:12:47 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8AGxpeo081699 for ; Wed, 10 Sep 2003 09:59:51 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8AGxpl2081698 for ietf-openproxy-bks; Wed, 10 Sep 2003 09:59:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8AGxleo081685 for ; Wed, 10 Sep 2003 09:59:49 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h8AGxkVH030461; Wed, 10 Sep 2003 10:59:46 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h8AGxkNJ030460; Wed, 10 Sep 2003 10:59:46 -0600 (MDT) (envelope-from rousskov) Date: Wed, 10 Sep 2003 10:59:46 -0600 (MDT) From: Alex Rousskov To: Andre Beck cc: OPES WG Subject: Re: moving along on rules language In-Reply-To: <3F5F306B.2020908@bell-labs.com> Message-ID: References: <75F7E67FC45F6744A7D328D41E35376D0551C3@mail.webwasher.com> <3F5F306B.2020908@bell-labs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 10 Sep 2003, Andre Beck wrote: > I still don't believe that the problem we are trying to solve calls > for a (albeit limited) programming language like P. Let's avoid the undefined term "programming language". IRML is no less or no more programming language than P, IMO. Just a different language. > In fact, I think a rule module written in P would be more difficult > to understand and write by people who don't already have experience > with programming languages. It probably depends on the complexity of a rule module. As a counter argument (also subjective), I believe a rule module in XML would be more difficult to understand and write by people who don't already have experience with XML. Let's define "programmer" as a person familiar with simple shell/Basic/Perl/Python/whatever scripts. I would like to assert the following generalizations: 1a) programmers can handle both IRML and P 1b) programmers would prefer P to IRML 2a) non-programmers would have difficulty handling both raw P and raw IRML 2b) non-programmers would prefer a GUI (graphical) way of specifying rules 2c) a human unfamiliar with both scripting and XML, would learn P at least as fast as she would learn IRML; P is a higher-level language than IRML 3a) both P and IRML rules can be created using a GUI 3b) P GUI can be identical to IRML GUI or can have an "advance" mode for those who want more control or more processing efficiency 4a) most rule writers are programmers 5a) efficient rule execution is important 5b) P allows for important optional optimizations that IRML-03 does not allow for, given an average P/IRML interpreter > What I like about an XML-based language like IRML is that by design > it limits the complexity of rule modules. Agreed as long as "complexity" is viewed as a trade-off rather than a pure negative characteristic. P allows expressing something that IRML cannot express. That additional functionality may be useful is some scenarios. The question is whether there is sufficient number of such scenarios. This is the question this WG would have to answer. Another point of view would be a "so what?" question. In other words, does it hurt to have support for more complex expressions? Do we expect the interpreter to become much more difficult to write or slower to run than an IRML interpreter? I do not. Any other good reasons optional complexity is bad? > IRML rule modules can be represented as well es edited graphically > (using a generic XML editor) in a tree where nodes represent rule > conditions and leaves resulting actions. I think such a > representation would be more intuitive and easier to understand than > a piece of P code. I disagree that a generic XML editor would help non-programmers much. Trees, leaves, conditions are foreign terms to them. Is GUI helpful to non-programmers? Yes! Is a generic XML editor helpful to non-programmers? Not really. A nice GUI can be developed for both IRML and P. > Also, when editing IRML rules generic XML editors can provide rule > authors with immediate feedback if rule modules violate the IRML DTD > or XML syntax. I don't think this can be easily done with P. There are generic editors that support syntax highlighting for nearly arbitrary programming languages. For a non-programmer, those would be as (if not more) useful than XML DTD validators. Also, the value of edit-time syntax checking is marginal, IMO. It would take just a few seconds to verify written syntax using a stand-alone P interpreter. Finally, P syntax is so simple/limited that I doubt a reasonable person would have hard time using it after the first few hours of learning. > I also don't agree with all of the design goals that Alex lists in > the introction to P. For example, I don't see a need for the rule > language to be so compact and efficient that it can be interpreted > on the fly. I cannot imagine that an ISP would let an OPES system > process arbitrary rules in real time as it receives them from data > providers/consumers. ISP will not. A surrogate or CDN intermediary will. Surrogates and CDN nodes have close relationships with origin servers where anything coming from the servers is assumed to be valid/authorized so there is no security concern. The performance issue remains but it is a flexibility versus speed trade-off that does not have a one-size-fits-all resolution. In fact, it is possible that OPES nodes will be more common in closely controlled environments like server acceleration or CDNs than at ISPs. > I think there will have to be an offline validation and optimization > step. That way the OPES system can rewrite or throw out inefficient > or malicious rule modules that would slow down the OPES system > excessively or unnecessarily otherwise. Yes, and that is possible with both P and IRML, of course. > That having said, I believe that there is still a lot of potential > to further improve IRML if the WG decides to pursue an XML-based > rule language. For example, CPL (which solves a very similar problem > in the IP tel. space and is also XML-based) has a mechanism that > allows CPL script authors to easily re-use parts of a CPL script > through a reference to it. I would be willing to work on a new IRML > draft version to incorporate such a mechanism as well as address > some of Alex' comments on IRML. If things like that are done to IRML (and they certainly can be!), you would eventually get two equally complex/powerful languages, but you would be constantly fighting XML boundaries in IRML because what you will be doing will be less and less similar to describing static hierarchical data (what XML is designed for). XML may be appropriate for IRML-03. However, I would think that if rules language has code and value reuse, it is a bad idea to use XML. As you have noted, we need feedback from other people on the list. Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Wed Sep 10 16:52:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17931 for ; Wed, 10 Sep 2003 16:52:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xBwf-0003Ec-00 for opes-archive@ietf.org; Wed, 10 Sep 2003 16:52:09 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19xBwf-0003EU-00 for opes-archive@ietf.org; Wed, 10 Sep 2003 16:52:09 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8AKWkeo020053 for ; Wed, 10 Sep 2003 13:32:46 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8AKWkF9020051 for ietf-openproxy-bks; Wed, 10 Sep 2003 13:32:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8AKWieo020040 for ; Wed, 10 Sep 2003 13:32:44 -0700 (PDT) (envelope-from abeck@bell-labs.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h8AKWd9Y034676; Wed, 10 Sep 2003 16:32:39 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h8AKWW2e074049; Wed, 10 Sep 2003 16:32:32 -0400 (EDT) Received: from bell-labs.com (abeck-hopc [135.180.240.202]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h8AKWVFU012721; Wed, 10 Sep 2003 16:32:32 -0400 (EDT) Message-ID: <3F5F8950.7010300@bell-labs.com> Date: Wed, 10 Sep 2003 16:28:00 -0400 From: Andre Beck User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES WG CC: Jonathan Lennox Subject: [Fwd: Re: CPL and XML] Content-Type: multipart/mixed; boundary="------------060700050103030105020407" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. --------------060700050103030105020407 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit As I mentioned before, the IPTEL WG has specified CPL as a processing language for IP telephony and I believe that IPTEL had similar requirements for CPL as we have for the OPES rule language. So I asked Jonathan Lennox (who co-authored CPL) if he remembered the reasons why the IPTEL WG decided to base CPL on XML and he kindly provided the following response. -Andre --------------060700050103030105020407 Content-Type: message/rfc822; name="Re: CPL and XML.eml" Content-Disposition: inline; filename="Re: CPL and XML.eml" Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h8AHiaFU008252 for ; Wed, 10 Sep 2003 13:44:36 -0400 (EDT) Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id NAA20580 for ; Wed, 10 Sep 2003 13:44:35 -0400 (EDT) Received: from scummy.research.bell-labs.com (localhost [127.0.0.1]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h8AHiY2e045489 for ; Wed, 10 Sep 2003 13:44:34 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h8AHiW2e045475 for ; Wed, 10 Sep 2003 13:44:32 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by dusty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h8AHlrnD061149 for ; Wed, 10 Sep 2003 13:47:53 -0400 (EDT) Received: from cnr.cs.columbia.edu (cnr.cs.columbia.edu [128.59.19.133]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h8AHiT4n003173 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 10 Sep 2003 13:44:30 -0400 (EDT) Received: from cnr.cs.columbia.edu (localhost [127.0.0.1]) by cnr.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h8AHiOYj012471 for ; Wed, 10 Sep 2003 13:44:24 -0400 (EDT) (envelope-from lennox@cnr.cs.columbia.edu) Received: (from lennox@localhost) by cnr.cs.columbia.edu (8.12.9/8.12.9/Submit) id h8AHiKP6012452; Wed, 10 Sep 2003 13:44:20 -0400 (EDT) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <16223.25332.277766.149958@cnr.cs.columbia.edu> Date: Wed, 10 Sep 2003 13:44:20 -0400 To: Andre Beck Subject: Re: CPL and XML In-Reply-To: <3F5E9365.2080704@bell-labs.com> References: <3F5E9365.2080704@bell-labs.com> X-Mailer: VM 7.17 under Emacs 20.7.1 Content-Transfer-Encoding: 7bit On Tuesday, September 9 2003, "Andre Beck" wrote to "lennox@cs.columbia.edu" saying: > Hi Jonathan, > > The OPES wg is currently debating whether or not to base the OPES rule > specification language on XML. The purpose of the rule language is to > let OPES users specify rules that determine which (HTTP) messages > require additional processing by one or more OPES services. It seems to > me that CPL solves a similar problem for IP tel. So I was wondering if > we can learn from your experience with CPL. Do you remember why you > decided to base CPL on XML? Did you ever consider using other formats > for CPL, e.g. a simple programming/configuration language? I did consider using other languages for CPL -- the two main thoughts were "something kind of like Tcl" and "something based on sieve". There were a number of reasons for basing CPL on XML, though. First of all, XML's tree structure maps naturally onto the decision-tree model of telephony services: try this, and if it doesn't work, try that. While "programming" languages generally support this, "configuration" languages usually don't -- they tend to be more in the attribute/value model. I'm not sure how significant this is for OPES; I've not followed it very much. XML has a number of nice features because it's so widely supported. A student here at Columbia has done a project to display CPL scripts in an easy-to-read graphical format, using XSL-T; the same project would have been rather more complicated, requiring writing new parsers and the like, if a custom grammar had been used. Possibly the most significant reason for using XML, though, is that it avoids the "Bikeshed problem" (http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING). Working groups can get terribly tied up in grammar and syntax; everyone has their own opinion on their favorite format for comments, for example. Using an established, flexible language forces the group to concentrate on the actual hard problems -- *what* information should be encoded by the format, and what it should mean, rather than *how* it's encoded. XML also lets you use existing (debugged) parsers, rather than writing your own, which is very useful. I hope this is helpful for you! -- Jonathan Lennox lennox@cs.columbia.edu --------------060700050103030105020407-- From owner-ietf-openproxy@mail.imc.org Wed Sep 10 21:02:30 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25583 for ; Wed, 10 Sep 2003 21:02:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xFr0-0001vU-00 for opes-archive@ietf.org; Wed, 10 Sep 2003 21:02:34 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19xFr0-0001vM-00 for opes-archive@ietf.org; Wed, 10 Sep 2003 21:02:34 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8B0maeo060150 for ; Wed, 10 Sep 2003 17:48:36 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8B0mavY060149 for ietf-openproxy-bks; Wed, 10 Sep 2003 17:48:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8B0mYeo060144 for ; Wed, 10 Sep 2003 17:48:34 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h8B0mNVH043240; Wed, 10 Sep 2003 18:48:23 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h8B0mM0l043239; Wed, 10 Sep 2003 18:48:22 -0600 (MDT) (envelope-from rousskov) Date: Wed, 10 Sep 2003 18:48:22 -0600 (MDT) From: Alex Rousskov To: Andre Beck cc: OPES WG , Jonathan Lennox Subject: Re: [Fwd: Re: CPL and XML] In-Reply-To: <3F5F8950.7010300@bell-labs.com> Message-ID: References: <3F5F8950.7010300@bell-labs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 10 Sep 2003, Andre Beck wrote: > As I mentioned before, the IPTEL WG has specified CPL as a > processing language for IP telephony and I believe that IPTEL had > similar requirements for CPL as we have for the OPES rule language. > So I asked Jonathan Lennox (who co-authored CPL) if he remembered > the reasons why the IPTEL WG decided to base CPL on XML and he > kindly provided the following response. Andre, It is great that you were able to get a first-hand explanation. Thank you, Jonathan, for providing a detailed response. I think your reasons and reasons that you do _not_ mention will help this WG a lot. I will summarize Jonathan's (IPTEL WG) points regarding XML use for CPL and will try to map that to OPES WG situation. This mapping is all my subjective opinion, of course. > XML's tree structure maps naturally onto the decision-tree model of > telephony services: try this, and if it doesn't work, try that. In the OPES services world, the focus is on the if-statement condition and service execution parameters rather than fallback mechanisms. Fallback mechanism must be supported, of course. > While "programming" languages generally support this, > "configuration" languages usually don't -- they tend to be more in > the attribute/value model. Both proposed rules languages support this. > XML has a number of nice features because it's so widely supported. As a developer, I was not that impressed with XML "support" 6 month or so ago, when I last needed it. There are only a few decent libraries. When you add cost/licensing, language, and size into the mix, you are often left with pretty much nothing. Fortunately, a simple/limited XML parser is easy to write. > A student here at Columbia has done a project to display CPL scripts > in an easy-to-read graphical format, using XSL-T; the same project > would have been rather more complicated, requiring writing new > parsers and the like, if a custom grammar had been used. IMHO, if P takes 100 man/hours to visialize and IRML takes 1 man/hours to visualize, they are about the same as far as visialization is concerned. Note that im most cases there should be no need for a _new_ parser (for visualization) in either case bacause a parser is required to interpret either language anyway. 1 man/hour is better, of course, but only marginally if we consider production application of the technology. I am also not yet convinced that visualization is important for OPES. Most proxy administrators I know prefer editing configuration files to using GUIs. Their bosses prefer reading MS Word files to editing via GUIs. From another point of view, with parser generators like Spirit, it takes very little time to parse a BNF. So even if you do work from scratch, there are tools available to help you. > Possibly the most significant reason for using XML, though, is that > it avoids the "Bikeshed problem" > (http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING). > Working groups can get terribly tied up in grammar and syntax; > everyone has their own opinion on their favorite format for > comments, for example. "Fortunately", OPES WG group does not have enough active participants for the above to become a problem :-/. You did not mention any performance considerations. I guess they were not very important becuase you just needed to support an execution of a static set of alternatives, with each alternative being cheap to evaluate. In OPES, evaluation can be expensive (e.g., is this HTTP request going to be a cache hit or miss?) and non-trivial (hit and request headers contain FooBar but previous service failed). Thus, we need to optimize and reuse code. Thanks again, Alex. From owner-ietf-openproxy@mail.imc.org Wed Sep 10 21:39:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26377 for ; Wed, 10 Sep 2003 21:39:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xGRF-0005Bk-00 for opes-archive@ietf.org; Wed, 10 Sep 2003 21:40:01 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19xGRE-0005Be-00 for opes-archive@ietf.org; Wed, 10 Sep 2003 21:40:00 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8B1Sweo061593 for ; Wed, 10 Sep 2003 18:28:58 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8B1Svbx061592 for ietf-openproxy-bks; Wed, 10 Sep 2003 18:28:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8B1Sueo061587 for ; Wed, 10 Sep 2003 18:28:56 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h8B1SxVH044216; Wed, 10 Sep 2003 19:28:59 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h8B1SxJJ044215; Wed, 10 Sep 2003 19:28:59 -0600 (MDT) (envelope-from rousskov) Date: Wed, 10 Sep 2003 19:28:59 -0600 (MDT) From: Alex Rousskov To: Lee Beaumont cc: OPES WG Subject: Re: Fw: Divide and Conquer In-Reply-To: <0a0701c377ad$e2048360$0500a8c0@leecoxv2qdje8b> Message-ID: References: <0a0701c377ad$e2048360$0500a8c0@leecoxv2qdje8b> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Furthermore, in order to move to a conclusion faster, I think we should start with what you propose last: a good set of specific examples that rules language can handle. I will try to contribute some real-world ACL examples soon. Thank you, Alex. On Wed, 10 Sep 2003, Lee Beaumont wrote: > I am interested in the IRML vs. P debate going on here. With the > proposal of P I believe Alex has tackled two problems at once. > Perhaps if these are separated, more clarity can lead to more > progress. The two problems I see being confounded and addressed are: > > 1) What style syntax should be used in the language?, and > 2) What expressive power should be allowed. > > These issues go to the root of the requirements for a rules > language, and also involve some parochial preferences. > > Regarding syntax, people naturally have a prejudice toward either a > verbose (e.g. COBOL and XML) style of syntax, or a preference for a > terse style (e.g. C and its derivatives, like java and P). My > preference is for the terse "C" style, and I believe the success of > "C" gives some broader support to that preference. Perhaps this > debate over syntax style can be put on a more objective footing by > examining: > > 1) Ease of writing, > 2) Ease of (human) reading, > 3) Availability of editors, visulaizers, and verifiers. > 4) ease of machine interpretation, including speed, and size > > Related to expressive power, I believe the debate needs to focus > first on the types of rules that need to be expressed. For example, > can the WG establish a "working set" of "pseudo code (or structured > English) rules that need to be accommodated. This might include > access control , Anonymization, local preferences, natural language > translation and other examples chosen from the OPES documents. Then > this working set can be expressed (or not) in IRML and P and the > results compared. > > I hope this is helpful > > Lee Beaumont > > From owner-ietf-openproxy@mail.imc.org Wed Sep 10 22:55:13 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27593 for ; Wed, 10 Sep 2003 22:55:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xHc6-0003tW-00 for opes-archive@ietf.org; Wed, 10 Sep 2003 22:55:18 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19xHc5-0003tN-00 for opes-archive@ietf.org; Wed, 10 Sep 2003 22:55:17 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8B2jLeo064274 for ; Wed, 10 Sep 2003 19:45:21 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8B2jLSr064273 for ietf-openproxy-bks; Wed, 10 Sep 2003 19:45:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8B2jKeo064267 for ; Wed, 10 Sep 2003 19:45:20 -0700 (PDT) (envelope-from markus@mhof.com) Received: from mhof.com (pcp04243305pcs.eatntn01.nj.comcast.net[68.38.30.212]) by comcast.net (rwcrmhc13) with SMTP id <20030911024517015000v3fee> (Authid: mhofmann); Thu, 11 Sep 2003 02:45:18 +0000 Message-ID: <3F5FE1BF.8040907@mhof.com> Date: Wed, 10 Sep 2003 22:45:19 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES WG CC: Jonathan Lennox Subject: Re: [Fwd: Re: CPL and XML] References: <3F5F8950.7010300@bell-labs.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Alex Rousskov wrote: >>Possibly the most significant reason for using XML, though, is that >>it avoids the "Bikeshed problem" >>(http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING). >>Working groups can get terribly tied up in grammar and syntax; >>everyone has their own opinion on their favorite format for >>comments, for example. > > "Fortunately", OPES WG group does not have enough active participants > for the above to become a problem :-/. Well, then it's even more dangerous - with only so few active participants, we cannot afford to be distracted by disucssions on grammar/syntax at all - we should leverage whatever we can. If we decide to move forward with "P", I would assume that its current grammar/syntax is accepted as is, and that we won't get distracted by discussions about style preferences. > You did not mention any performance considerations. I guess they were > not very important becuase you just needed to support an execution of > a static set of alternatives, with each alternative being cheap to > evaluate. In OPES, evaluation can be expensive (e.g., is this HTTP > request going to be a cache hit or miss?) and non-trivial (hit and > request headers contain FooBar but previous service failed). Thus, we > need to optimize and reuse code. I do *not* believe that the OPES rules language needs to be designed for performance, simply because I don't assume that OPES processors will use this language as internal representation for rules evaluation anyway. An OPES processor will receive a rules description in the format to be specified, and then (in my view) will translate it into an internal (proprietary) and highly efficient data representation - something tree based comes to mind. -Markus From owner-ietf-openproxy@mail.imc.org Thu Sep 11 11:02:40 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26552 for ; Thu, 11 Sep 2003 11:02:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xSy5-00025l-00 for opes-archive@ietf.org; Thu, 11 Sep 2003 11:02:45 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19xSy4-00024z-00 for opes-archive@ietf.org; Thu, 11 Sep 2003 11:02:45 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BEmoeo046277 for ; Thu, 11 Sep 2003 07:48:50 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8BEmouB046275 for ietf-openproxy-bks; Thu, 11 Sep 2003 07:48:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BEmneo046267 for ; Thu, 11 Sep 2003 07:48:49 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h8BEmnVH062952; Thu, 11 Sep 2003 08:48:49 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h8BEmdvp062951; Thu, 11 Sep 2003 08:48:39 -0600 (MDT) (envelope-from rousskov) Date: Thu, 11 Sep 2003 08:48:39 -0600 (MDT) From: Alex Rousskov To: OPES WG cc: "Anwar M. Haneef" Subject: RE: moving along on rules language Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -- Posted on behalf of Anwar M. Haneef ---------- Forwarded message ---------- Date: Wed, 10 Sep 2003 13:45:54 -0500 From: Anwar M. Haneef To: rousskov@measurement-factory.com Subject: RE: moving along on rules language I haven't been an active participant on this list, but have worked on OPES for a while (2 years) from an academic standpoint. I agree with Andre regarding the compactness of the rule expression language. The reason for this is because I don't see the need for these rules to be interepreted on the fly. A more realistic scenario from my perspective would be an intermediary pulling out pre-interpreted rules that are stored in 'bytecode' native to an intermediary at the processing points. This would reduce the processing overhead at the intermediary since the pre-processing and archiving of processing point rules could be done offline. On the other hand, Alex's proposed P language seems to entertain a more flexible mechanism for expressing expressions. Maybe this is due to my lack of experience in languages, but this is one major issue I had with developing IRML-based Processing Point rules for content delivery based on QoS and device characteristics. My Master's Thesis on an OPES-based approach for content delivery for heterogeneous multi-deviced user environments is accessible at: http://anwarhaneef.home.comcast.net/publications/publications.htm#thesis for those who might be interested. Another concern I had regarding P is the relative ease or complexity of auto-generation P language rules. For instance, from my previous experience (mentioned above), it is relatively simple to generate an XML-based IRML rule by parsing a restricted clickable-web form that allows users to define their preferences. I guess most of these concerns boil down to my apprehensions regarding the amount of expertise in the market with XML-parsers as opposed to BNF parsers-generators. Should ease of development be a criterion ? Also, would it be possible to mix the features in IRML and P to develop a mechanism by which structure could be defined by the XML-based IRML while P syntax is used for expressions, something like: _DIALUP := 288000; client := Http.request.property("User-Agent"); if ( client == "WAP Browser" or client.bandwidth() < _DIALUP ) { _irml( opes://compressme.com/textcompress ); } opes://altavista.com/babelfish I hope I haven't confused people here. But, C/C++ programmers would note that this is similar to how ASM code can be placed inline in a C/C++ program. As you can note, we could allow P language script to include IRML and vice versa. Would this be a technical noghtmare to develop ? Any comments on this approach ? Regards, Anwar --------------------------------------- Anwar M. Haneef Senior Research Engineer Mobile Platforms and Services Lab Motorola Labs, Schaumburg, IL 60196 Phone: (847)-576-4939 (o) Mobile:(847)-514-5192 (m) Pvt.ID: 934 http://www-unix.ecs.umass.edu/~ahaneef ---------------------------------------- From owner-ietf-openproxy@mail.imc.org Thu Sep 11 11:56:31 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28710 for ; Thu, 11 Sep 2003 11:56:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xToC-0002hx-00 for opes-archive@ietf.org; Thu, 11 Sep 2003 11:56:36 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19xToB-0002hu-00 for opes-archive@ietf.org; Thu, 11 Sep 2003 11:56:35 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BFjaeo052855 for ; Thu, 11 Sep 2003 08:45:36 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8BFjZT6052854 for ietf-openproxy-bks; Thu, 11 Sep 2003 08:45:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BFjWeo052847 for ; Thu, 11 Sep 2003 08:45:34 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h8BFjVVH064269; Thu, 11 Sep 2003 09:45:31 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h8BFjVuP064268; Thu, 11 Sep 2003 09:45:31 -0600 (MDT) (envelope-from rousskov) Date: Thu, 11 Sep 2003 09:45:31 -0600 (MDT) From: Alex Rousskov To: Markus Hofmann cc: OPES WG , Jonathan Lennox Subject: Re: [Fwd: Re: CPL and XML] In-Reply-To: <3F5FE1BF.8040907@mhof.com> Message-ID: References: <3F5F8950.7010300@bell-labs.com> <3F5FE1BF.8040907@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 10 Sep 2003, Markus Hofmann wrote: > Alex Rousskov wrote: > > > "Fortunately", OPES WG group does not have enough active participants > > for the above to become a problem :-/. > > Well, then it's even more dangerous - with only so few active > participants, we cannot afford to be distracted by disucssions on > grammar/syntax at all - we should leverage whatever we can. > > If we decide to move forward with "P", I would assume that its > current grammar/syntax is accepted as is, and that we won't get > distracted by discussions about style preferences. That's my expectation. There will be some additions and polishing actions as the current grammar is not 100% complete, but I really doubt we will run into Bikeshed problems due to P syntax. We can run into them due to P/IRML semantics, of course. > I do *not* believe that the OPES rules language needs to be designed > for performance, simply because I don't assume that OPES processors > will use this language as internal representation for rules > evaluation anyway. Let's use English then :-) Seriously, compilers and interpreters can do only so much. If we care about performance and the problem domain is not trivial, we must include human code writers into the loop. We are not talking Assembly language here, but some major human-hints would be requried in rule modules for them to be interpreted efficiently. This is the same as writing programs in modern programming languages like C++ or Java -- the languages are high-level, but have enough knobs to optimize performance where it counts. If compilers were so smart as you may be implying, we would be writing all programs in Prolog or a similar declarative language. > An OPES processor will receive a rules description in the format to > be specified, and then (in my view) will translate it into an > internal (proprietary) and highly efficient data representation - > something tree based comes to mind. Yes, but building an efficient bytecode requires programmer hints (i.e., language support). Alex. From owner-ietf-openproxy@mail.imc.org Thu Sep 11 12:10:23 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29066 for ; Thu, 11 Sep 2003 12:10:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xU1c-0002py-00 for opes-archive@ietf.org; Thu, 11 Sep 2003 12:10:28 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19xU1b-0002pv-00 for opes-archive@ietf.org; Thu, 11 Sep 2003 12:10:27 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BFwBeo053308 for ; Thu, 11 Sep 2003 08:58:11 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8BFwBLl053307 for ietf-openproxy-bks; Thu, 11 Sep 2003 08:58:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BFw9eo053301 for ; Thu, 11 Sep 2003 08:58:09 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h8BFwAVH064608; Thu, 11 Sep 2003 09:58:10 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h8BFwAfB064607; Thu, 11 Sep 2003 09:58:10 -0600 (MDT) (envelope-from rousskov) Date: Thu, 11 Sep 2003 09:58:10 -0600 (MDT) From: Alex Rousskov To: OPES WG cc: "Anwar M. Haneef" Subject: RE: moving along on rules language In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 10 Sep 2003, Anwar M. Haneef wrote: > I haven't been an active participant on this list, but have worked > on OPES for a while (2 years) from an academic standpoint. I agree > with Andre regarding the compactness of the rule expression > language. The reason for this is because I don't see the need for > these rules to be interepreted on the fly. For the record: even if we decide that compactness is not important for OPES applications, it is not a negative characteristic either. > On the other hand, Alex's proposed P language seems to entertain a > more flexible mechanism for expressing expressions. Maybe this is due > to my lack of experience in languages, but this is one major issue I > had with developing IRML-based Processing Point rules for content > delivery based on QoS and device characteristics. Could you please post an example or two where IRML lacked expression power you needed? > Another concern I had regarding P is the relative ease or complexity > of auto-generation P language rules. For instance, from my previous > experience (mentioned above), it is relatively simple to generate an > XML-based IRML rule by parsing a restricted clickable-web form that > allows users to define their preferences. I assert that is it equally easy to generate IRML and P rules from Web forms. Given a form that both languages can support, the code to generate P or IRML statements would be virtually identical. With P, the generator MAY perform additional optimizations and/or use additional form entries, but that is a different story. > I guess most of these concerns boil down to my apprehensions > regarding the amount of expertise in the market with XML-parsers as > opposed to BNF parsers-generators. Should ease of development be a > criterion ? I am not sure whether you are saying that there is more expertise with XML parser generators. If you are, I strongly disagree. Parser generators existed well before XML and are very well known. In fact, most XML parsers are written using the knowledge gained from the good old parsing theory. > Also, would it be possible to mix the features in IRML and P to > develop a mechanism by which structure could be defined by the > XML-based IRML while P syntax is used for expressions, What would be the benefit of using XML then? Alex. From owner-ietf-openproxy@mail.imc.org Thu Sep 11 12:31:32 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00052 for ; Thu, 11 Sep 2003 12:31:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xUM5-00036Y-00 for opes-archive@ietf.org; Thu, 11 Sep 2003 12:31:37 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19xUM4-00036S-00 for opes-archive@ietf.org; Thu, 11 Sep 2003 12:31:36 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BGKSeo054105 for ; Thu, 11 Sep 2003 09:20:28 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8BGKSs0054104 for ietf-openproxy-bks; Thu, 11 Sep 2003 09:20:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BGKReo054099 for ; Thu, 11 Sep 2003 09:20:27 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h8BGKSVH065086; Thu, 11 Sep 2003 10:20:28 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h8BGKShK065085; Thu, 11 Sep 2003 10:20:28 -0600 (MDT) (envelope-from rousskov) Date: Thu, 11 Sep 2003 10:20:28 -0600 (MDT) From: Alex Rousskov To: OPES WG cc: Lee Beaumont Subject: Re: Fw: Divide and Conquer In-Reply-To: Message-ID: References: <0a0701c377ad$e2048360$0500a8c0@leecoxv2qdje8b> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 10 Sep 2003, Alex Rousskov wrote: > Furthermore, in order to move to a conclusion faster, I think we > should start with what you propose last: a good set of specific > examples that rules language can handle. I will try to contribute > some real-world ACL examples soon. Here is a real-world rule example just posted on one of the mailing lists for network admins. I think the rules are using F5 (f5.com) language, but I am not sure. Pasted as-is: if ((exists http_cookie JSESSIONID) and http_cookie starts_with "1") { use slice1-pool } else ((exists http_cookie JSESSIONID) and http_cookie starts_with "2") { use slice2-pool } else { use all-pool } Load balancing is not a 100% OPES application, but here is how the above could be implemented in P, approximately: cookie := Http.message.headers.findCookie("JSESSIONID"); if (cookie and cookie.value.starts_with("1")) { service := Services.find("slice1-pool"); } else if (cookie and cookie.value.starts_with("2")) { service := Services.find("slice2-pool"); } else { service := Services.find("all-pool"); } Services.applyOne(service); Depending on the interpreter, the above P code could be more efficient that the above F5 code because the cookie header will be looked up only once, even if its value does not start with "1". Also note that if graceful handling of absent/down services is required, the above P code can handle such error in one place (the last line where the service variable is used) rather than three places in the original F5 code. HTH, Alex. P.S. Can anybody point me to F5 rule language specification? From owner-ietf-openproxy@mail.imc.org Thu Sep 11 14:21:44 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03910 for ; Thu, 11 Sep 2003 14:21:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xW4h-00042u-00 for opes-archive@ietf.org; Thu, 11 Sep 2003 14:21:47 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19xW4h-00042l-00 for opes-archive@ietf.org; Thu, 11 Sep 2003 14:21:47 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BI6xeo060645 for ; Thu, 11 Sep 2003 11:06:59 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8BI6xV2060644 for ietf-openproxy-bks; Thu, 11 Sep 2003 11:06:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BI6veo060631 for ; Thu, 11 Sep 2003 11:06:57 -0700 (PDT) (envelope-from markus@mhof.com) Received: from mail.messagingengine.com (localhost [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 6C9001BE715; Thu, 11 Sep 2003 14:06:58 -0400 (EDT) Received: from 10.202.2.150 ([10.202.2.150] helo=mail.messagingengine.com) by messagingengine.com with SMTP; Thu, 11 Sep 2003 14:06:58 -0400 X-Epoch: 1063303618 X-Sasl-enc: be2Br7wN7l321gHN7/8gOA Received: from mhof.com (unknown [135.104.86.28]) by www.fastmail.fm (Postfix) with ESMTP id 08BB31B84E5; Thu, 11 Sep 2003 14:06:58 -0400 (EDT) Message-ID: <3F60BA5F.6070904@mhof.com> Date: Thu, 11 Sep 2003 14:09:35 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES WG Cc: Jonathan Lennox Subject: Re: [Fwd: Re: CPL and XML] References: <3F5F8950.7010300@bell-labs.com> <3F5FE1BF.8040907@mhof.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > Yes, but building an efficient bytecode requires programmer hints > (i.e., language support). This is why somthing XML-based might be of interest - it maps naturally into a tree-based structure, which IMHO makes a cood base for an efficiednt bytecode. -Markus PS: Jonathan - sorry for swamping you with OPES stuff, if you want to get off the discussion, please say so. From owner-ietf-openproxy@mail.imc.org Thu Sep 11 15:47:12 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10980 for ; Thu, 11 Sep 2003 15:47:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xXPQ-0005e6-00 for opes-archive@ietf.org; Thu, 11 Sep 2003 15:47:16 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19xXPP-0005dy-00 for opes-archive@ietf.org; Thu, 11 Sep 2003 15:47:15 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BJXTeo068101 for ; Thu, 11 Sep 2003 12:33:29 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8BJXTK2068100 for ietf-openproxy-bks; Thu, 11 Sep 2003 12:33:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BJXReo068093 for ; Thu, 11 Sep 2003 12:33:27 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h8BJWsVH070750; Thu, 11 Sep 2003 13:32:54 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h8BJWs1e070749; Thu, 11 Sep 2003 13:32:54 -0600 (MDT) (envelope-from rousskov) Date: Thu, 11 Sep 2003 13:32:54 -0600 (MDT) From: Alex Rousskov To: Markus Hofmann cc: OPES WG , Jonathan Lennox Subject: Re: [Fwd: Re: CPL and XML] In-Reply-To: <3F60BA5F.6070904@mhof.com> Message-ID: References: <3F5F8950.7010300@bell-labs.com> <3F5FE1BF.8040907@mhof.com> <3F60BA5F.6070904@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 11 Sep 2003, Markus Hofmann wrote: > Alex Rousskov wrote: > > > Yes, but building an efficient bytecode requires programmer hints > > (i.e., language support). > > This is why somthing XML-based might be of interest - it maps > naturally into a tree-based structure, which IMHO makes a cood base > for an efficiednt bytecode. True. The question is whether all we want to support has a natural mapping into a tree-based structure. If yes, XML is OK. If no, XML is an obstacle. I do not think that all rule modules we need to support naturally come with a tree-based structure. I disagree that the problem worth solving is that simple. Of course, any procedural program can be forced into a tree-based structure. I do not want to force rule writers to do unnatural things. Natural expression is the whole point of having a domain-specific language. Alex. From owner-ietf-openproxy@mail.imc.org Thu Sep 11 17:18:18 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14269 for ; Thu, 11 Sep 2003 17:18:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xYpb-0006U0-00 for opes-archive@ietf.org; Thu, 11 Sep 2003 17:18:23 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19xYpa-0006Tx-00 for opes-archive@ietf.org; Thu, 11 Sep 2003 17:18:22 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BK50eo070143 for ; Thu, 11 Sep 2003 13:05:00 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8BK50oO070142 for ietf-openproxy-bks; Thu, 11 Sep 2003 13:05:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BK4xeo070133 for ; Thu, 11 Sep 2003 13:04:59 -0700 (PDT) (envelope-from markus@mhof.com) Received: from mail.messagingengine.com (localhost [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 906471BE4E2; Thu, 11 Sep 2003 16:05:00 -0400 (EDT) Received: from 10.202.2.150 ([10.202.2.150] helo=mail.messagingengine.com) by messagingengine.com with SMTP; Thu, 11 Sep 2003 16:05:00 -0400 X-Epoch: 1063310700 X-Sasl-enc: Q/rbeXaXNf1Bu541wnHDgA Received: from mhof.com (H-135-104-86-15.research.bell-labs.com [135.104.86.15]) by www.fastmail.fm (Postfix) with ESMTP id 2381C1BE506; Thu, 11 Sep 2003 16:05:00 -0400 (EDT) Message-ID: <3F60D611.3030603@mhof.com> Date: Thu, 11 Sep 2003 16:07:45 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES WG Cc: Jonathan Lennox Subject: Re: [Fwd: Re: CPL and XML] References: <3F5F8950.7010300@bell-labs.com> <3F5FE1BF.8040907@mhof.com> <3F60BA5F.6070904@mhof.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > True. The question is whether all we want to support has a natural > mapping into a tree-based structure. We need input and views from more folks here - specific examples will also help. -Markus From owner-ietf-openproxy@mail.imc.org Thu Sep 11 20:21:14 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19939 for ; Thu, 11 Sep 2003 20:21:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xbgc-00000e-00 for opes-archive@ietf.org; Thu, 11 Sep 2003 20:21:18 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19xbgb-00000b-00 for opes-archive@ietf.org; Thu, 11 Sep 2003 20:21:17 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8C07reo085323 for ; Thu, 11 Sep 2003 17:07:53 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8C07r7Q085322 for ietf-openproxy-bks; Thu, 11 Sep 2003 17:07:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail02.powweb.com (mail02.powweb.com [63.251.216.35]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8C07qeo085317 for ; Thu, 11 Sep 2003 17:07:52 -0700 (PDT) (envelope-from lee@isoeasy.com) Received: from leecoxv2qdje8b (bgp599974bgs.midltn01.nj.comcast.net [68.39.49.47]) by mail02.powweb.com (Postfix) with ESMTP id 23C22DF0B8 for ; Thu, 11 Sep 2003 17:16:40 -0700 (PDT) Message-ID: <0d4001c378c1$d4871670$0500a8c0@leecoxv2qdje8b> From: "Lee Beaumont" To: "OPES WG" Subject: Converging on Selection of a Rules Language Concept Date: Thu, 11 Sep 2003 20:07:17 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0D3D_01C378A0.4CE93C00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0D3D_01C378A0.4CE93C00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Fortunately there is a direct and effective process for converging on = the selection of a concept when developing a new product. Perhaps it can = help the team settle the IRML / P issue. I learned it as "Pugh concept selection" but it is called "Controlled = Convergence" in this reference: http://www.betterproductdesign.net/tools/concept/convergence.htm (A more complete description is in Stewart Pugh's book: http://www.amazon.com/exec/obidos/tg/detail/-/0201416395/qid=3D1063324278= /sr=3D1-1/ref=3Dsr_1_1/104-1770677-0827969?v=3Dglance&s=3Dbooks Those who have read both the IRML spec and the P spec have completed = step 1 of the process. I believe step 2 is a difficult one. Basically the team has to agree on = a list of requirements or specifications for the solution. This actually = seems to be where the debate has centered. Here is a starting point: 1) Easy to write (by programmers or non programmers? Using a simple = editor, a structured editor, or a GUI? seems like this has to be = decided) 2) Easy to read (by whom, similar set of issues) 3) Easy to edit and update (by whom, similar set of issues, do we need = hot slide in?) 4) Easy and clear expression of rules logic including . . . (fill in the = blank - I think if / then / else does a lot. what more is needed? = Perhaps Alex's reference set of rules can help here) 5) easy to write parser / interpreter (this begs the question of the run = time representation - text, byte code, object code, or else?) 6) easy / fast to run (how fast is needed?) 7) Compact storage on the processor 8) etc. 9) etc. 10) etc. I propose the working group continue to debate the list of requirements, = (perhaps using the above list as a starting point.) When the list of = requirements converges, I would be happy to lead the team through the = remaining steps of the convergence process. Is this sensible and helpful? Lee Beaumont=20 ------=_NextPart_000_0D3D_01C378A0.4CE93C00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Fortunately there is a direct and = effective process=20 for converging on the selection of a concept when developing a new = product.=20 Perhaps it can help the team settle the IRML / P issue.
I learned it as "Pugh concept = selection" but it is=20 called "Controlled Convergence" in this reference:
http://www.betterproductdesign.net/tools/concept/convergence.htm
(A more complete description is in = Stewart Pugh's=20 book:
http://www.amazon.com/exec/obidos/tg/detail/-/0201416395/qid=3D106332= 4278/sr=3D1-1/ref=3Dsr_1_1/104-1770677-0827969?v=3Dglance&s=3Dbooks
 
Those who have read both the IRML spec = and the P=20 spec have completed step 1 of the process.
 
I believe step 2 is a difficult one. = Basically the=20 team has to agree on a list of requirements or specifications for the = solution.=20 This actually seems to be where the debate has centered. Here is a = starting=20 point:
 
1) Easy to write (by programmers or non = programmers? Using a simple editor, a structured editor, or a GUI? seems = like=20 this has to be decided)
2) Easy to read (by whom, similar set = of=20 issues)
3) Easy to edit and update (by whom, = similar set of=20 issues, do we need hot slide in?)
4) Easy and clear expression of rules = logic=20 including . . . (fill in the blank - I think if / then / else does a = lot. what=20 more is needed? Perhaps Alex's reference set of rules can help=20 here)
5) easy to write parser / interpreter = (this begs=20 the question of the run time representation - text, byte code, object = code, or=20 else?)
6) easy / fast to run (how fast is=20 needed?)
7) Compact storage on the = processor
8) etc.
9) etc.
10) etc.
 
I propose the working group continue to = debate the=20 list of requirements, (perhaps using the above list as a starting = point.)=20 When the list of requirements converges, I would be happy to lead the = team=20 through the remaining steps of the convergence process.
 
Is this sensible and = helpful?
 
Lee Beaumont 
 
 
 
------=_NextPart_000_0D3D_01C378A0.4CE93C00-- From owner-ietf-openproxy@mail.imc.org Fri Sep 12 01:09:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26058 for ; Fri, 12 Sep 2003 01:09:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xgBA-0001w2-00 for opes-archive@ietf.org; Fri, 12 Sep 2003 01:09:08 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19xgBA-0001vz-00 for opes-archive@ietf.org; Fri, 12 Sep 2003 01:09:08 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8C4v6eo000693 for ; Thu, 11 Sep 2003 21:57:06 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8C4v6as000692 for ietf-openproxy-bks; Thu, 11 Sep 2003 21:57:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8C4v4eo000687 for ; Thu, 11 Sep 2003 21:57:05 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h8C4v8VH084141; Thu, 11 Sep 2003 22:57:08 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h8C4v7P4084140; Thu, 11 Sep 2003 22:57:07 -0600 (MDT) (envelope-from rousskov) Date: Thu, 11 Sep 2003 22:57:07 -0600 (MDT) From: Alex Rousskov To: OPES WG cc: "Anwar M. Haneef" Subject: RE: moving along on rules language Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > From: Anwar M. Haneef --Alex, Please repost this (inclusing the confession) in case it does not get broadcasted via the mailing list :-) Before I begin this discussion, I have a confession to make: I have to admit that I have a bias towards an XML-based approach since it's the norm these days and its considered 'cool'. I also have a friend running a very successful company that develops devices for XML-based transaction processing. Inspite of these reasons for a bias, I believe P does seem rather interesting for rule processing. I hope that our mailing list can help identify which solution would be most suitable for our needs. >> On the other hand, Alex's proposed P language seems to entertain a >> more flexible mechanism for expressing expressions. Maybe this is >> due to my lack of experience in languages, but this is one major >> issue I had with developing IRML-based Processing Point rules for >> content delivery based on QoS and device characteristics. > >Could you please post an example or two where IRML lacked expression >power you needed? Maybe most of the examples I could give could be represented using IRML, but the difficulty in writing it in XML (esp. in case the rules are generated by hand) seem daunting. Its when I sat down and tried to express a few of the rules I needed in a content delivery system for multi-homed mobile devices that I realized how compact P language rules can be as compared to an IRML rule - again this is a comparison of manually generated and written rules. An example of my requirement would be: device := identify_device_category( Http.request.property("User-Agent") ); if( (device.category == "smartPhone") && (device.hasCapabilityToRender(Http.response.property("Content-Type"))) ) { //nic = network interface card for each ( nic in device.getNICs() ) { leastDloadTime := _LARGE_VALUE; if( (downloadTime := nic.timeToDownload(Http.response.property("Content-Length"))) <= _MAX_WAIT_TIME ) { if (downloadTime < leastDloadTime ) { leastDloadTime = downloadTime; selected_nic := nic; break; } } } } send_content_to_nic(nic, Http.response.message); Again, this might be a specific area (that I work in) that might have such complex rules for processing at, say processing point 4 in an OPES box, but as more and more network connected multi-homed mobile devices become popular, maybe we need to identify a rule language that can accomodate future needs. The related earlier work by Ng, Tan and Cheng from Panasonic (draft-ng-opes-irmlqos-00.txt) seemed to try to develop an IRML subsystem for QoS considerations. I wonder what happened to that. Using IRML for evaluating expressions seemed very clumsy - forgive me for saying this :-) >> Also, would it be possible to mix the features in IRML and P to >> develop a mechanism by which structure could be defined by the >> XML-based IRML while P syntax is used for expressions, > >What would be the benefit of using XML then? The assumptions under which I made that statement was that P language parsing would be more difficult to implement, and the assumptions that an XML-based rule language would be easier to edit visually. Alex says otherwise, which is most probably true since there has been not objections to that from the list. I admit I have limited experience in this area to debate it. Even in case proponents of XML-based rules can give a convincing argument for converging to an XML-based rule language, which I am sure must be there, IMHO, I would still think that the relative ease with which more complex rules can be expressed via 'P' make it something even IRML-based rules engines should support, at least as an add-on - much like how Javascript may be included with HTML to enhance the user experience or, like in my earlier example, how ASM code is implanted into C/C++ code for delegating more flexibility and control to the developer - or administrator in our case. Regards, Anwar --------------------------------------- Anwar M. Haneef Senior Research Engineer Mobile Platforms and Services Lab Motorola Labs, Schaumburg, IL 60196 Phone: (847)-576-4939 (o) Mobile:(847)-514-5192 (m) Pvt.ID: 934 http://www-unix.ecs.umass.edu/~ahaneef ---------------------------------------- From owner-ietf-openproxy@mail.imc.org Fri Sep 12 13:36:41 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06166 for ; Fri, 12 Sep 2003 13:36:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xrqg-0002no-00 for opes-archive@ietf.org; Fri, 12 Sep 2003 13:36:46 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19xrqf-0002nj-00 for opes-archive@ietf.org; Fri, 12 Sep 2003 13:36:45 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8CH5Veo085980 for ; Fri, 12 Sep 2003 10:05:31 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8CH5Vj9085979 for ietf-openproxy-bks; Fri, 12 Sep 2003 10:05:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8CH5Teo085972 for ; Fri, 12 Sep 2003 10:05:30 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8CH5Os14935 for ; Fri, 12 Sep 2003 13:05:24 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 12 Sep 2003 13:05:24 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD75406DCC623@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: ietf-openproxy@imc.org Subject: FW: Request To Publish: draft-ietf-opes-end-comm-01 Date: Fri, 12 Sep 2003 13:05:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C37950.0CFFEA8E" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C37950.0CFFEA8E Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37950.0CFFEA8E" ------_=_NextPart_001_01C37950.0CFFEA8E Content-Type: text/plain fyi, Abbie > -----Original Message----- > From: Barbir, Abbie [CAR:1A11:EXCH] > Sent: Friday, September 12, 2003 12:58 PM > To: internet-drafts@ietf.org > Cc: Barbir, Abbie [CAR:1A11:EXCH]; Markus Hofmann; Marshall > Rose; Alex Rousskov > Subject: Request To Publish: draft-ietf-opes-end-comm-01 > > > Please publish the attached > > draft-ietf-opes-end-comm-01 > > > as an OPES working group Internet Draft. > > Thank you, > > > Abbie > ------_=_NextPart_001_01C37950.0CFFEA8E Content-Type: text/html FW: Request To Publish: draft-ietf-opes-end-comm-01

fyi,

Abbie

> -----Original Message-----
> From: Barbir, Abbie [CAR:1A11:EXCH]
> Sent: Friday, September 12, 2003 12:58 PM
> To: internet-drafts@ietf.org
> Cc: Barbir, Abbie [CAR:1A11:EXCH]; Markus Hofmann; Marshall
> Rose; Alex Rousskov
> Subject: Request To Publish: draft-ietf-opes-end-comm-01
>
>
> Please publish the attached
>
> draft-ietf-opes-end-comm-01
>
>
> as an OPES working group Internet Draft.
>
> Thank you,
>
>
> Abbie
>

  ------_=_NextPart_001_01C37950.0CFFEA8E-- ------_=_NextPart_000_01C37950.0CFFEA8E Content-Type: text/plain; name="draft-ietf-opes-end-comm-01.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-opes-end-comm-01.txt" Content-Transfer-Encoding: quoted-printable Network Working Group A. = Barbir Internet-Draft Nortel = Networks Expires: March 12, 2004 September 12, = 2003 OPES processor and end points communications draft-ietf-opes-end-comm-01 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that = other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six = months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 12, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This memo documents tracing requirements for Open Pluggable Edge Services (OPES). Barbir Expires March 12, 2004 [Page = 1] =0C Internet-Draft OPES processor and end points communications = September 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 3 2. OPES Domain and OPES System . . . . . . . . . . . . . . . . = 4 3. OPES Tracing . . . . . . . . . . . . . . . . . . . . . . . . = 6 3.1 What is traceable in an OPES Flow? . . . . . . . . . . . . . = 6 3.2 Requirements for Information Related to Traceable Entities? . . . . . . . . . . . . . . . . . . . . . . . . . = 7 4. Requirements for OPES processors . . . . . . . . . . . . . . = 8 5. Requirements for callout servers . . . . . . . . . . . . . . = 9 6. Privacy considerations . . . . . . . . . . . . . . . . . . . = 10 6.1 Tracing and Trust Domains . . . . . . . . . . . . . . . . . = 10 7. How to Support Tracing . . . . . . . . . . . . . . . . . . . = 11 7.1 Tracing and OPES System Granularity . . . . . . . . . . . . = 11 7.2 Requirements for In-Band Tracing . . . . . . . . . . . . . . = 12 7.2.1 Tracing Information Granularity and Persistence levels Requirements . . . . . . . . . . . . . . . . . . . . . . . . = 12 7.3 Protocol Binding . . . . . . . . . . . . . . . . . . . . . . = 13 7.4 Tracing scenarios and examples . . . . . . . . . . . . . . . = 13 8. Optional Notification . . . . . . . . . . . . . . . . . . . = 14 9. IANA considerations . . . . . . . . . . . . . . . . . . . . = 16 10. Security Considerations . . . . . . . . . . . . . . . . . . = 17 Normative References . . . . . . . . . . . . . . . . . . . . = 18 Informative References . . . . . . . . . . . . . . . . . . . = 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . = 19 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . = 20 Intellectual Property and Copyright Statements . . . . . . . = 21 Barbir Expires March 12, 2004 [Page = 2] =0C Internet-Draft OPES processor and end points communications = September 2003 1. Introduction The Open Pluggable Edge Services (OPES) architecture [8] enables cooperative application services (OPES services) between a data provider, a data consumer, and zero or more OPES processors. The application services under consideration analyze and possibly transform application-level messages exchanged between the data provider and the data consumer. The execution of such services is governed by a set of rules installed on the OPES processor. The rules enforcement can trigger the execution of service applications local to the OPES processor. Alternatively, the OPES processor can distribute the responsibility of service execution by communicating and collaborating with one or more remote callout servers. As described in [8], an OPES processor communicates with and invokes services on a callout server by using = a callout protocol. The work specify the requirements for providing tracing = functionality for the OPES architecture [8]. This document specifies tracing mechanisms that the OPES architecture could provide that enable data provider application to detect inappropriate clinet centric actions by OPES entities. The work focus on developing tracing requirements that can be used to fulfil the notification and Non-Blocking requirements [2]. In the OPES architecture document [8], there is a requirement of relaying tracing information in-band. This work investigates this possibility and discusses possible methods that could be used to detect faulty OPES processors or callout servers by end points in an OPES flow. The document is organized as follows: Section 2 defines OPES Domain and OPES System. Section 3 discusses entities that are traceable in an OPES Flow. Sections 4 and 5 discuss tracing requirements for OPES systems and callout servers. Section 6 focus on Tracing and Trust Domains. Section 7 discusses how to support tracing and provides = uses cases. Section 8 examines Optional Notofication. Section 9 looks into IANA considerations. Section 10 examines security considerations. Barbir Expires March 12, 2004 [Page = 3] =0C Internet-Draft OPES processor and end points communications = September 2003 2. OPES Domain and OPES System This sections clarifies the terms OPES system and OPES Domain [8]. These terms are needed in order to define what is traceable in an OPES Flow [8]. An OPES domain describes the collection of OPES entities that a single provider operates. OPES domains can be based on trust or = other operational boundaries. All elements of an "OPES Domain" MUST be in the same trust domain. This would be independent of any specific = OPES flow. An OPES system consists of a limited set of OPES entities, parts of = a single or of multiple OPES operators domains, organized by (or on behalf) of either a data provider application or a data consumer application to perform authorized services on a given application message. Each OPES entity in an OPES system MUST be directly addressable on IP level by a data consumer application. An OPES system can be formed in a recursive manner. An OPES system can start with either a data provider application or a data consumer application (for a given message). The OPES system then includes any OPES entity trusted by (accepting authority from) an entity that is already in the OPES system. The trust and authority delegation is viewed in the context of the given application message. As implied by the above definition, some OPES entities in the system may not participate in the processing of a given message. An OPES domain MUST not be an OPES sub-system. An OPES domain MUST require external resources to provide services. An OPES domain is a part of an OPES system belonging to a given operator. OPES domains have no incidence on the structure of an OPES system, but they may influence its organization for different reasons such as security, payment, quality of service, delivery parameters among others. In Figure 1 an OPES Flow is shown that traverses across various OPES Domains. A data consumer application MUST be able to recive tracing information on per message basis that enable it to determine the set of transformations that were perfomed on the data for a particular OPES Flow. The formation of an OPES flow can be static or dynamic, meaning that the determination of which OPES Domains will = participate in a given OPES Flow (per message basis) can be a function of business arrangements. Barbir Expires March 12, 2004 [Page = 4] =0C Internet-Draft OPES processor and end points communications = September 2003 +------------------------------------------+ | Data Consumer Application | +------------------------------------------+ ^ | +-------------------------------------------+ | OPES System | O | | | | | +-------------------------+ | P | | | OPES Domain | | | | | +---------------+ | | E | | | | OPES Entity | | | | | | +---------------+ | | S | | | . | | | | | . | | | | | +---------------+ | | F | | | |Callout Server | | | | | | +---------------+ | | L | | | | | | | +-------------------------+ | O | | . | | | . | W | | +-------------------------+ | | | | OPES Domain | | | | | +---------------+ | | | | | | OPES Entity | | | | | | +---------------+ | | | | | . | | | | | . | | | | | +---------------+ | | | | | | OPES Entity | | | | | | +---------------+ | | | | +-------------------------+ | | | v | | +-----------------------------------+ | | | Data Provider Application | | | +-----------------------------------+ | | | +-------------------------------------------+ Figure 1: OPES System Barbir Expires March 12, 2004 [Page = 5] =0C Internet-Draft OPES processor and end points communications = September 2003 3. OPES Tracing Before discussing what is traceable in an OPES flow, it is = beneficial to define what tracing means. Tracing is defined as the inclusion of necessary information within a message in an OPES flow that could be used to identify the set of transformations or adpatations that have been performed on its content in an OPES System before its delivery to an end point (the data consumer application). o OPES trace: application message information about OPES entities = in an OPES System that adapted that message. o OPES tracing: the process of including, manipulating, and interpreting an OPES trace in an OPES System. To emphasize, the above definition means that OPES tracing SHOULD be performed on per message basis. Trace format is dependent on the application protocol that is being adapted by OPES. Data consumer application can use OPES trace to infer the actions that have been performed by the OPES system. The architecture document requires = [8] that tracing be supported in-band. In an OPES System the task of providing tracing information, must take into account the following considerations: o Providers may be hesitant to reveal information about their internal network infrastructure. o Within a service provider network, OPES processors may be configured to use non-routable, private IP addresses. o A Data consumer applications would prefer to have a single point of contact regarding the trace information. o TBD 3.1 What is traceable in an OPES Flow? This section focuses on identifying the traceable entities in an = OPES Flow. Tracing information MUST be able to provide a data consumer application with useful information without tracing the exact OPES Processor or callout servers that adapted the data. It is up to the OPES service provider to have maintained appropriate internal detailed traces to find the answer to the data consumer applications inquiry. At the implementation level, for a given trace, an OPES entity Barbir Expires March 12, 2004 [Page = 6] =0C Internet-Draft OPES processor and end points communications = September 2003 involved in handling the corresponding application message is "traceable" or "traced" if information about it appears in that trace. OPES entities have different levels of traceability requirements. Specifically, o An OPES system MUST add its entry to the trace. o An OPES processor SHOULD add its entry to the trace. o An OPES service SHOULD add its entry to the trace. o An OPES entity MAY manage trace information from entities that = are under its control. For example, an OPES processor may add or remove callout service entries in order to manage the size of a trace. Other considerations include: * The OPES processor may have a fixed configuration that enable it to respond to tracing inquires. * The OPES processor may insert a summary of the services that = it controls. The summary can be used to respond to tracing inquiries. * The OPES processor may package tracing information related to the entities that it control based on the policy of a given OPES System. From an OPES context, a good tracing approach is similar to a = trouble ticket ready for submission to a known address. The trace in itself is not necessarily a detailed description of what has happened. It = is the resposibility of the operator to resolve the problems. 3.2 Requirements for Information Related to Traceable Entities? The requirements for information as related to entities that are terceable in an OPES flow are: o The privacy policy at the time it dealt with the message o Identification of the party responsible for setting and = enforcing that policy o Information pointing to a technical contact o Information that identifies, to the technical contact, the OPES processors involved in processing the messag o TBD Barbir Expires March 12, 2004 [Page = 7] =0C Internet-Draft OPES processor and end points communications = September 2003 4. Requirements for OPES processors In order to facilitate compliance, the concept of an "OPES system" being traceable, requires that each OPES processor MUST support tracing. Policy can be set that defines which domain has authorization to turn on tracing and its granularity. An OPES provider can have its private policy for trace information, but it MUST support tracing mechanisms and it MUST reveal it's policy. The requirements for OPES processors that are applicatble to tracing are: o Each OPES processor MUST belong to a single OPES Domain. o Each OPES processor MUST have a Unique Identity in that Domain. o Each OPES processor MUST support tracing, policy can be used to turn tracing on and.to determine granuality. o TBD Barbir Expires March 12, 2004 [Page = 8] =0C Internet-Draft OPES processor and end points communications = September 2003 5. Requirements for callout servers If it is the task of an OPES processor to add trace records to application messages, then callout servers that uses the OCP = protocol are not affected by tracing requirements. In order for an OCP protocol to be tracing neutral, the OPES server SHOULD be able to meet the following requirements: o Callout services adapt payload regardless of the application protocol in use and leave header adjustment to OPES processor. o OPES processor SHOULD be able to trace it's own invocation and service(s) execution since they understand the application protocol. o Callout servers MAY be able to add their own OPES trace records to application level messages. o TBD Barbir Expires March 12, 2004 [Page = 9] =0C Internet-Draft OPES processor and end points communications = September 2003 6. Privacy considerations 6.1 Tracing and Trust Domains A trust domain may include several OPES systems and entities. Within a trust domain, there MUST be at least support for one trace entry per system. Entities outside of that system may or may not see any traces, depending on domain policies or configuration. For example, if an OPES system is on the content provider "side", end-users are not guaranteed any traces. If an OPES system is working inside end-user domain, the origin server is not guaranteed any traces related to user requests. Barbir Expires March 12, 2004 [Page = 10] =0C Internet-Draft OPES processor and end points communications = September 2003 7. How to Support Tracing In order to support tracing, the following aspects must be = addressed: o There MUST be a System Identifier that identify a domain that is employing an OPES system. o An OPES processor MUST be able to be uniquely identified (MUST have an Identifier) within a system. o An OPES processor MUST add its identification to the trace. o An OPES processor SHOULD add to the trace identification of = every callout service that received the application message. o An OPES processor MUST add to the trace identification of the "system/entity" it belongs to. "System" ID MUST make it possible to access "system" privacy policy. o An OPES processor MAY group the above information for sequential trace entries having the same "system/entity" ID. In other = words, trace entries produced within the same "system/entity" MAY be merged/aggregated into a single less detailed trace entry. o An OPES processor MAY delegate trace management to a callout service within the same "system/entity". TBD 7.1 Tracing and OPES System Granularity There are two distinct uses of traces. First, is to SHOULD enable = the "end (content producer or consumer) to detect OPES processor = presence within end's trust domain. Such "end" should be able to see a trace entry, but does not need to be able to interpret it beyond identification of the trust domain(s). Second, the domain administrator SHOULD be able to take a trace = entry (possibly supplied by an "end? as an opaque string) and interpret = it. The administrator must be able to identify OPES processor(s) = involved and may be able to identify applied adaptation services along with other message-specific information. That information SHOULD help to explain what OPES agent(s) were involved and what they did. It may = be impractical to provide all the required information in all cases. This document view a trace record as a hint, as opposed to an exhaustive audit. Since the administrators of various trust domains can have various Barbir Expires March 12, 2004 [Page = 11] =0C Internet-Draft OPES processor and end points communications = September 2003 ways of looking into tracing, they MAY require the choice of freedom in what to put in trace records and how to format them. Trace = records should be easy to extend beyond basic OPES requirements. Trace management algorithms should treat trace records as opaque data to the extent possible. It is not expected that entities in one trust domain to be able to get all OPES-related feedback from entities in other trust domains. For example, if an end-user suspects that a served is corrupted by a callout service, there is no guarantee that the use will be able to identify that service, contact its owner, or debug it _unless_ the service is within my trust domain. This is no different from the current situation where it is impossible, in general, to know the contact person for an application on an origin server that generates corrupted HTML; and even if the person is known, one should not expect that person to respond to end-user queries. 7.2 Requirements for In-Band Tracing The OPES architecture [8] states that traces must be in-band. The support of this design specification is dependent on the specifics = of the message application level protocol that is being used in an OPES flow. In-band tracing limits the type of application protocols that OPES can support. The details of what a trace record can convey is also dependent on the choice of the application level protocol. For these reasons, the work will document requirements for application protocols that need to support OPES traces. However, the architecture does not prevent implementers of developing out-of-band protocols and techniques to address the above limitation. 7.2.1 Tracing Information Granularity and Persistence levels Requirements In order to be able to trace entities that have acted on an application message in an OPES flow, there may be requirements to keep information that is related to the following: o Message-related informatio: All data that describes specific actions performed on the message SHOULD be provided with that message, as there is no other way to find message level details later. o Session related information: Session level data MUST be preserved for the duration of the session. OPES processor is responsible = for inserting notifications if session-level information changes. o End-point related data: What profile is activated? Where to get Barbir Expires March 12, 2004 [Page = 12] =0C Internet-Draft OPES processor and end points communications = September 2003 profile details? Where to set preferences? o TBD 7.3 Protocol Binding How tracing is added is application protocol-specific and will be documented in separate drafts. This work documents what tracing information is required and some common tracing elements. 7.4 Tracing scenarios and examples TBD Barbir Expires March 12, 2004 [Page = 13] =0C Internet-Draft OPES processor and end points communications = September 2003 8. Optional Notification This section examines IAB [2] considerations (3.1) and (3.2) regarding notification in an OPES architecture. Notification propagates in opposite direction of tracing and cannot be attached to application messages that it notifies about. Notification can be done out-band and may require the development of a new protocol. The direction of data flow for tracing and notification are depicted in Figure 2. Notification +----------------------------------------------- | | | V +---------------+ +-------+ = +---------------+ | | | | | Data Provider = | | Data Consumer | Tracing | OPES |<----->| Application = | | Application |<-----------| | = +---------------+ +---------------+ +-------+ ^ |OCP | V +---------+ | Callout | | Server | +---------+ Figure 2: Notification Flow In [9] it was argued that Notification is an expensive approach for providing tracing information. However, the current work does not prevent an OPES System from publishing policy and specifications = that allow Optional Notification. For example, an OPES System can adopt a mechanism that uses a flag that would allow a data consumer and a data provider application to signal to each other that they are interested to receive an explicit notification if an OPES service = is applied to a specific message. The value of this optional flag/field can be a URI that identifies notification method plus parameters. If a processor understands the method, it would be able to further decode the field and send a notification. The specification of the field name and format for an application protocol can be stated in the associated binding document. The details of the notification Barbir Expires March 12, 2004 [Page = 14] =0C Internet-Draft OPES processor and end points communications = September 2003 protocol is beyond the scope of this Working Group. For example, the following HTTP header: o OPES-Notify: URI *(pname=3Dpvalue) Or, o My-OPES-Notify: foo=3Dbar q=3D0.5 can be used. Barbir Expires March 12, 2004 [Page = 15] =0C Internet-Draft OPES processor and end points communications = September 2003 9. IANA considerations TBD Barbir Expires March 12, 2004 [Page = 16] =0C Internet-Draft OPES processor and end points communications = September 2003 10. Security Considerations TBD Barbir Expires March 12, 2004 [Page = 17] =0C Internet-Draft OPES processor and end points communications = September 2003 Normative References [1] McHenry, S., et. al, "OPES Scenarios and Use Cases", Internet-Draft TBD, May 2002. [2] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002. [3] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [4] OPES working group, "OPES Service Authorization and Enforcement Requirements", Internet-Draft TBD, May 2002. [5] OPES working group, "OPES Ruleset Schema", Internet-Draft TBD, May 2002. [6] A. Beck et al., "Requirements for OPES Callout Protocols", Internet-Draft http://www.ietf.org/internet-drafts/ draft-ietf-opes-protocol-reqs-03.txt, December 2002. [7] A. Barbir et al., "Security Threats and Risks for Open = Pluggable Edge Services", Internet-Draft http://www.ietf.org/ internet-drafts/draft-ietf-opes-threats-00.txt, October 2002. [8] A. Barbir et al., "An Architecture for Open Pluggable Edge Services (OPES)", Internet-Draft http://www.ietf.org/ internet-drafts/draft-ietf-opes-architecture-04, December = 2002. [9] A. Barbir et al., "OPES Treatment of IAB Considerations", Internet-Draft http://www.ietf.org/internet-drafts/ draft-ietf-opes-iab-01.txt, February 2004. Barbir Expires March 12, 2004 [Page = 18] =0C Internet-Draft OPES processor and end points communications = September 2003 Informative References [10] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and = S. Waldbusser, "Terminology for Policy-Based Management", RFC 3198, November 2001. [11] L. Cranor, et. al, "The Platform for Privacy Preferences 1.0 (P3P1.0) Specification", W3C Recommendation 16 http:// www.w3.org/TR/2002/REC-P3P-20020416/ , April 2002. [12] "Hit Metering", RFC . Author's Address Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean, Ontario K2H 8E9 Canada Phone: +1 613 763 5229 EMail: abbieb@nortelnetworks.com Barbir Expires March 12, 2004 [Page = 19] =0C Internet-Draft OPES processor and end points communications = September 2003 Appendix A. Acknowledgements TBD Barbir Expires March 12, 2004 [Page = 20] =0C Internet-Draft OPES processor and end points communications = September 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances = of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification = can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph = are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Barbir Expires March 12, 2004 [Page = 21] =0C Internet-Draft OPES processor and end points communications = September 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Barbir Expires March 12, 2004 [Page = 22] =0C ------_=_NextPart_000_01C37950.0CFFEA8E-- From owner-ietf-openproxy@mail.imc.org Fri Sep 12 15:06:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10556 for ; Fri, 12 Sep 2003 15:06:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xtFC-0004B2-00 for opes-archive@ietf.org; Fri, 12 Sep 2003 15:06:10 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19xtFB-0004Ay-00 for opes-archive@ietf.org; Fri, 12 Sep 2003 15:06:09 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8CIsNeo097024 for ; Fri, 12 Sep 2003 11:54:23 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8CIsN8D097023 for ietf-openproxy-bks; Fri, 12 Sep 2003 11:54:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8CIsLeo097009 for ; Fri, 12 Sep 2003 11:54:22 -0700 (PDT) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h8CIsK9Y052953 for ; Fri, 12 Sep 2003 14:54:23 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h8CIsDF2087184 for ; Fri, 12 Sep 2003 14:54:13 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h8CIsCFU024571 for ; Fri, 12 Sep 2003 14:54:12 -0400 (EDT) Message-ID: <3F6216B6.30402@mhof.com> Date: Fri, 12 Sep 2003 14:55:50 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Decision on Rules Language Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Folks, in order to move forward with the rules language, we'd like to do the following: Since both proposals - IRML and "P" - can basically do the job, it's more a question of personal style preference. From the discussions on this mailing list, it looks like only two people are leaning toward IRML, while four are leaning toward "P". As such, we'd like to move forward with "P" and drop IRML. As mentioned earlier, we'd assume that the "P" syntax as specified so far is accepted and we won't have to start discussions on syntax modifications. We're already late with the rules document, so we'd expect a first WG document on "P" to be published by 9/20. Alex, can you please take the responsibility to do so. Andre indicated that he'd be available to help and write text as well, if this would be helpful, please get in touch with him. Thanks, Markus and Marshall From owner-ietf-openproxy@mail.imc.org Fri Sep 12 15:21:38 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11939 for ; Fri, 12 Sep 2003 15:21:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xtUG-0004Jf-00 for opes-archive@ietf.org; Fri, 12 Sep 2003 15:21:44 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19xtUF-0004Jc-00 for opes-archive@ietf.org; Fri, 12 Sep 2003 15:21:43 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8CJ7Aeo097803 for ; Fri, 12 Sep 2003 12:07:10 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8CJ79SQ097802 for ietf-openproxy-bks; Fri, 12 Sep 2003 12:07:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8CJ78eo097797 for ; Fri, 12 Sep 2003 12:07:08 -0700 (PDT) (envelope-from markus@mhof.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h8CJ7A9Y053030 for ; Fri, 12 Sep 2003 15:07:10 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h8CJ732e071417 for ; Fri, 12 Sep 2003 15:07:03 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h8CJ73FU024946 for ; Fri, 12 Sep 2003 15:07:03 -0400 (EDT) Message-ID: <3F6219B8.1090300@mhof.com> Date: Fri, 12 Sep 2003 15:08:40 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Timeline for wrapping up Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Folks, according to our charter, we're expected to finish all work items by October this year. The next IETF meeting will be in November in Minneapolis. We want to use this meeting to review the final output of the WG prior to issuing the WG last call on all documents. The timeframe for doing this would be: Rules Language "P" ------------------ - 09/20: initial WG rules document - 11/01: final document candidate to be reviewd in Minneapolis - 11/28: final WG rules document; issue WG last call - 12/05: close WG last call on rules document; submit to IESG IAB Treatments: --------------- - 9/20: next version of document (e.g. adding text on optional notification); send to Sally for feedback - 11/1: final document candidate to be reviewd in Minneapolis - 11/28: final version ; issue WG last call - 12/05: close WG last call, submit to IESG OCP Core: --------- - 11/1: final document candidate to be reviewd in Minneapolis - 11/28: final version; issue WG last call - 12/05: close WG last call; submit to IESG HTTP binding: ------------- - 11/1: final document candidate to be reviewd in Minneapolis - 11/28: final version ; issue WG last call - 12/05: close WG last call; submit to IESG OPES processor and end points communications (tracing): ------------------------------------------------------- - 11/1: final document candidate to be reviewd in Minneapolis - 11/28: final version ; issue WG last call - 12/05: close WG last call; submit to IESG Intermediate versions as needed - up to the authors. Authors - please let us know asap if you see any problems with the timelines. Thanks, Markus, Marshall From owner-ietf-openproxy@mail.imc.org Fri Sep 12 16:24:15 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13881 for ; Fri, 12 Sep 2003 16:24:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xuSr-0004vX-00 for opes-archive@ietf.org; Fri, 12 Sep 2003 16:24:21 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19xuSq-0004vU-00 for opes-archive@ietf.org; Fri, 12 Sep 2003 16:24:20 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8CK15eo004041 for ; Fri, 12 Sep 2003 13:01:05 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8CK15Jl004040 for ietf-openproxy-bks; Fri, 12 Sep 2003 13:01:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8CK13eo004031 for ; Fri, 12 Sep 2003 13:01:03 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h8CK15VH006425 for ; Fri, 12 Sep 2003 14:01:05 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h8CK15KH006424; Fri, 12 Sep 2003 14:01:05 -0600 (MDT) (envelope-from rousskov) Date: Fri, 12 Sep 2003 14:01:05 -0600 (MDT) From: Alex Rousskov To: OPES Group Subject: Re: Decision on Rules Language In-Reply-To: <3F6216B6.30402@mhof.com> Message-ID: References: <3F6216B6.30402@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 12 Sep 2003, Markus Hofmann wrote: > As mentioned earlier, we'd assume that the "P" syntax as specified > so far is accepted and we won't have to start discussions on syntax > modifications. We would need to add the following items that will have minor affect on P syntax. Again, I expect no Bikeshed problems, but I think I have to mention these for correctness sake. 1. Fault/error detection/recovery mechanism. This will most likely be something simple that resembles boolean expressions while having core benefits of "exceptions" mechanism common to modern languages: { // piece of any code } or { // piece of code executed if the above // piece fails for any reason } or { // piece of code executed if the above // two pieces fail for any reason } In other words, the "expression value" of a piece of code is "true" unless the code fails for any reason. Actually, I do not think this changes existing syntax, but that's an important missing feature. 2. Constants: - boolean true/false - "strings" (already used but not documented) - numbers (decimal only or both decimal and hex?) - other (IP addresses: '127.0.0.1' or '1::h:5')? Note that XML-based language would have to document this as well 3. Comments: - none supported - /* block comments */ - // line comments - block and line comments I like line comments a lot, but would probably vote against them in P because they introduce a notion of a "line", which may be a bad idea if we are going to use P expressions in interesting contexts like HTTP headers where there are no lines. 4. International support (i18n) Can we just say that everything is UTF-8 encoded? Does Unicode define "space characters"? Or do we have to say explicitly what those [ASCII] characters are? If you have a strong opinion regarding any of the above or know more about UTF/Unicode, please let me know. > We're already late with the rules document, so we'd expect a first > WG document on "P" to be published by 9/20. Alex, can you please > take the responsibility to do so. Sure. I will wait for objections until Tuesday night before submitting. > Andre indicated that he'd be available to help and write text as > well, if this would be helpful, please get in touch with him. Done. Thanks Andre for not holding this against me. I am sure P will reuse most of your work. Alex. From owner-ietf-openproxy@mail.imc.org Mon Sep 15 10:26:17 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04440 for ; Mon, 15 Sep 2003 10:26:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yuJ5-0004gk-00 for opes-archive@ietf.org; Mon, 15 Sep 2003 10:26:23 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19yuJ4-0004gT-00 for opes-archive@ietf.org; Mon, 15 Sep 2003 10:26:22 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FEBjeo056983 for ; Mon, 15 Sep 2003 07:11:45 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8FEBj4f056982 for ietf-openproxy-bks; Mon, 15 Sep 2003 07:11:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FEBieo056977 for ; Mon, 15 Sep 2003 07:11:44 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01952; Mon, 15 Sep 2003 10:11:38 -0400 (EDT) Message-Id: <200309151411.KAA01952@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-openproxy@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-opes-end-comm-01.txt Date: Mon, 15 Sep 2003 10:11:37 -0400 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Pluggable Edge Services Working Group of the IETF. Title : OPES processor and end points communications Author(s) : A. Barbir Filename : draft-ietf-opes-end-comm-01.txt Pages : 22 Date : 2003-9-15 This memo documents tracing requirements for Open Pluggable Edge Services (OPES) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opes-end-comm-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-opes-end-comm-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-opes-end-comm-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-15100452.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-opes-end-comm-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-opes-end-comm-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-15100452.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-openproxy@mail.imc.org Mon Sep 15 15:40:42 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22630 for ; Mon, 15 Sep 2003 15:40:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yzDL-0005GD-00 for opes-archive@ietf.org; Mon, 15 Sep 2003 15:40:47 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19yzDL-0005GA-00 for opes-archive@ietf.org; Mon, 15 Sep 2003 15:40:47 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FJRteo079807 for ; Mon, 15 Sep 2003 12:27:55 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8FJRtRj079806 for ietf-openproxy-bks; Mon, 15 Sep 2003 12:27:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail6-red-R.bigfish.com (mail-red.bigfish.com [216.148.222.61]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FJRseo079798 for ; Mon, 15 Sep 2003 12:27:55 -0700 (PDT) (envelope-from internet-drafts@ietf.org) Received: from mail6-red.bigfish.com (localhost.localdomain [127.0.0.1]) by mail6-red-R.bigfish.com (Postfix) with ESMTP id 9DE762B3108 for ; Mon, 15 Sep 2003 19:27:51 +0000 (UCT) Received: by mail6-red (MessageSwitch) id 1063654071532101_6312; Mon, 15 Sep 2003 19:27:51 +0000 (UCT) Received: from smtpgw6.it.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14]) by mail6-red.bigfish.com (Postfix) with ESMTP id 752E52B311D for ; Mon, 15 Sep 2003 19:27:13 +0000 (UCT) Received: from mailhost.sprintspectrum.com (smtpgw8.it.sprintspectrum.com [207.40.65.56]) by smtpgw6.it.sprintspectrum.com (8.12.9/8.12.8) with ESMTP id h8FJRCie021109 for ; Mon, 15 Sep 2003 14:27:12 -0500 (CDT) Received: from PDAWG02A.corp.sprint.com (localhost [127.0.0.1]) by mailhost.sprintspectrum.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h8FJRA721850 for ; Mon, 15 Sep 2003 14:27:10 -0500 (CDT) Received: from mail pickup service by PDAWG02A.corp.sprint.com with Microsoft SMTPSVC; Mon, 15 Sep 2003 14:27:06 -0500 Received: from mailhost.sprintspectrum.com ([207.40.65.55]) by PKDWG01A.ad.sprint.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 15 Sep 2003 12:27:48 -0500 Received: from smtpgw5.sprintspectrum.com (localhost [127.0.0.1]) by mailhost.sprintspectrum.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h8FHRit06512 for ; Mon, 15 Sep 2003 12:27:44 -0500 (CDT) Received: from mail3-haw-R.bigfish.com (mail-haw.bigfish.com [12.129.199.61]) by smtpgw5.sprintspectrum.com (8.12.9/8.12.8) with ESMTP id h8FEKev7010277 for ; Mon, 15 Sep 2003 09:22:30 -0500 (CDT) Received: from mail3-haw.bigfish.com (localhost.localdomain [127.0.0.1]) by mail3-haw-R.bigfish.com (Postfix) with ESMTP id CDECB1C6667 for ; Mon, 15 Sep 2003 14:19:12 +0000 (UCT) Received: by mail3-haw (MessageSwitch) id 1063635552334151_31481; Mon, 15 Sep 2003 14:19:12 +0000 (UCT) Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mail3-haw.bigfish.com (Postfix) with ESMTP id B0A681C65A9; Mon, 15 Sep 2003 14:19:11 +0000 (UCT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19yu58-0006fU-2Z for ietf-announce-list@asgard.ietf.org; Mon, 15 Sep 2003 10:11:58 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19yu4w-0006V0-4V for all-ietf@asgard.ietf.org; Mon, 15 Sep 2003 10:11:46 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01952; Mon, 15 Sep 2003 10:11:38 -0400 (EDT) Message-Id: <200309151411.KAA01952@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-openproxy@imc.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-opes-end-comm-01.txt Date: Mon, 15 Sep 2003 10:11:37 -0400 X-BigFish: cs-64(z60di60eiz14c3M13bfIzz2cfRzz1033ILz1IV)v X-OriginalArrivalTime: 15 Sep 2003 17:27:49.0789 (UTC) FILETIME=[AFA57CD0:01C37BAE] Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Pluggable Edge Services Working Group of the IETF. Title : OPES processor and end points communications Author(s) : A. Barbir Filename : draft-ietf-opes-end-comm-01.txt Pages : 22 Date : 2003-9-15 This memo documents tracing requirements for Open Pluggable Edge Services (OPES) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opes-end-comm-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-opes-end-comm-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-opes-end-comm-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-15100452.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-opes-end-comm-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-opes-end-comm-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-15100452.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-openproxy@mail.imc.org Mon Sep 15 20:51:21 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04836 for ; Mon, 15 Sep 2003 20:51:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19z43x-00015j-00 for opes-archive@ietf.org; Mon, 15 Sep 2003 20:51:25 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19z43x-00015Y-00 for opes-archive@ietf.org; Mon, 15 Sep 2003 20:51:25 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8G0edeo092599 for ; Mon, 15 Sep 2003 17:40:39 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8G0ed6b092598 for ietf-openproxy-bks; Mon, 15 Sep 2003 17:40:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8G0eceo092593 for ; Mon, 15 Sep 2003 17:40:38 -0700 (PDT) (envelope-from haneef@labs.mot.com) Received: from il06exr02.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h8G0eeAn001901; Mon, 15 Sep 2003 17:40:40 -0700 (MST) Received: from dryden ([10.7.68.49]) by il06exr02.mot.com (Motorola/il06exr02) with SMTP id h8G0ebVo014252; Mon, 15 Sep 2003 19:40:38 -0500 From: "Anwar M. Haneef" To: "Alex Rousskov" , "OPES Group" Subject: RE: Decision on Rules Language Date: Mon, 15 Sep 2003 19:40:37 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi Alex, I had a few notes (mostly half or quarter-baked) in addition to your last posting: Scope: - Do we need to define the scope of code within which identifiers are recognized ? Can there be a case such as : h := Http.makeHeader("Client-IP"); quick_code := { h := Http.makeHeader("Server-IP"); contact_server(h); }; Single assignment/Or not?: - Should we be able to de-assign a variable (I guess this goes against the very definition of single-assignment)? Something like: h := Http.makeHeader("Client-IP"); free(h); h := Http.makeHeader("Server-IP"); - Is there any specific reason we would want single-assignment ? Processing Point Identification: - Mechanism for identifying the processing points identifier (PPID) as the points of activity for the rule - Something such as interpretor.processingPoint("X"){} could be defined -> This info can be used by the interpretor to classify the rules based on PPIDs for quicker retrieval by the OPES processor. Or else allow something like: Core.PPID("X") { code; } to deliniate the processing point associated with the code. Primitive types: - Could we include support for arrays or lists of elements/objects ? - Can we modify the 'identifier' to be defined as (for us C/Java programmers who prefer using this for global static variables): identifier = "_"/ALPHA *(ALPHA/DIGIT/"_") Loops and Iterators: - This is a powerful feature P-language could easily integrate but difficult in an XML-based language - 'for each element in ', 'while (expression){code}', 'do-while' Subsystems: - I am assuming the IRML subsytem equivalent for extended functionality would be encompassed by the Core.import("M") functionality Failure detection/capture: - Should we have a structure similar to 'try-catch-final' in contemporary languages like Java/C# etc ? - What happens in case a service cannot be found when doing 'Service.find' ? - see notes on the interpretor below. - What happens in case a method called in an object does not exist/fails/throws an error/returns invalid value Interpretor & Security: - Should the specs for the interpretor be defined or is it left for the implementor? - Should security be enforced by the interpretor that does the underlying processing based on P language commands? - IMHO, If we assume that the P language runs via the interpretor that acts as a 'Virtual Machine', all security/error handling/authentication features are delegated to the interpretor. Regards, Anwar -----Original Message----- From: owner-ietf-openproxy@mail.imc.org [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of Alex Rousskov Sent: Friday, September 12, 2003 3:01 PM To: OPES Group Subject: Re: Decision on Rules Language On Fri, 12 Sep 2003, Markus Hofmann wrote: > As mentioned earlier, we'd assume that the "P" syntax as specified > so far is accepted and we won't have to start discussions on syntax > modifications. We would need to add the following items that will have minor affect on P syntax. Again, I expect no Bikeshed problems, but I think I have to mention these for correctness sake. 1. Fault/error detection/recovery mechanism. This will most likely be something simple that resembles boolean expressions while having core benefits of "exceptions" mechanism common to modern languages: { // piece of any code } or { // piece of code executed if the above // piece fails for any reason } or { // piece of code executed if the above // two pieces fail for any reason } In other words, the "expression value" of a piece of code is "true" unless the code fails for any reason. Actually, I do not think this changes existing syntax, but that's an important missing feature. 2. Constants: - boolean true/false - "strings" (already used but not documented) - numbers (decimal only or both decimal and hex?) - other (IP addresses: '127.0.0.1' or '1::h:5')? Note that XML-based language would have to document this as well 3. Comments: - none supported - /* block comments */ - // line comments - block and line comments I like line comments a lot, but would probably vote against them in P because they introduce a notion of a "line", which may be a bad idea if we are going to use P expressions in interesting contexts like HTTP headers where there are no lines. 4. International support (i18n) Can we just say that everything is UTF-8 encoded? Does Unicode define "space characters"? Or do we have to say explicitly what those [ASCII] characters are? If you have a strong opinion regarding any of the above or know more about UTF/Unicode, please let me know. > We're already late with the rules document, so we'd expect a first > WG document on "P" to be published by 9/20. Alex, can you please > take the responsibility to do so. Sure. I will wait for objections until Tuesday night before submitting. > Andre indicated that he'd be available to help and write text as > well, if this would be helpful, please get in touch with him. Done. Thanks Andre for not holding this against me. I am sure P will reuse most of your work. Alex. From owner-ietf-openproxy@mail.imc.org Mon Sep 15 21:23:09 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05813 for ; Mon, 15 Sep 2003 21:23:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19z4Yk-0001OT-00 for opes-archive@ietf.org; Mon, 15 Sep 2003 21:23:14 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19z4Yj-0001OQ-00 for opes-archive@ietf.org; Mon, 15 Sep 2003 21:23:13 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8G1BXeo093617 for ; Mon, 15 Sep 2003 18:11:33 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8G1BXSj093616 for ietf-openproxy-bks; Mon, 15 Sep 2003 18:11:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8G1BVeo093611 for ; Mon, 15 Sep 2003 18:11:31 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h8G1BXVH020744; Mon, 15 Sep 2003 19:11:33 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h8G1BXaH020743; Mon, 15 Sep 2003 19:11:33 -0600 (MDT) (envelope-from rousskov) Date: Mon, 15 Sep 2003 19:11:33 -0600 (MDT) From: Alex Rousskov To: "Anwar M. Haneef" cc: OPES Group Subject: RE: Decision on Rules Language In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 15 Sep 2003, Anwar M. Haneef wrote: > I had a few notes (mostly half or quarter-baked) in addition to your > last posting: You will find mostly half-baked answers below :-) > Scope: > - Do we need to define the scope of code within which identifiers are > recognized ? Can there be a case such as : > h := Http.makeHeader("Client-IP"); > quick_code := { > h := Http.makeHeader("Server-IP"); > contact_server(h); > }; P uses global scope. There is no big benefit from a local scope because we do not have user-defined functions. Global scope makes it easy to support/interpret/explain single-assignment. This is not yet documented. > Single assignment/Or not?: > - Should we be able to de-assign a variable (I guess this goes against the > very definition of single-assignment)? Yes, this goes against the very definition/purpose of a single-assignment. You will get a lot more complexity and fewer easy optimizations with multiple assignments (true variables). Single assignment along with lazy evaluation allows you to treat assignments as macros -- very easy to support and relatively easy to optimize. > - Is there any specific reason we would want single-assignment ? Simplicity and performance. Single assignment allows you to manipulate large protocol structures with little overhead. Without variables, you cannot reuse computed values. With true variables, you get into all sorts of complexity and memory management problems, even if you do not want to optimize. Single-assignment makes slow interpreters simple and complex interpreters fast. Single assignment allows you to reuse code as well. See current draft (the retry example: A or A or A). > Processing Point Identification: > - Mechanism for identifying the processing points identifier (PPID) as the > points of activity for the rule This is application-specific, IMO. Each module like "HTTP" would define its own notion of processing points. You should be able to find my rant about this on the OPES list archives ("Subject: processing points in draft-beck-opes-irml-03"). > - Something such as interpretor.processingPoint("X"){} could be defined -> > This info can be used by the interpretor to classify the rules based on > PPIDs for quicker retrieval by the OPES processor. Or else allow something > like: > Core.PPID("X") > { > code; > } > to deliniate the processing point associated with the code. See above. Also, I believe that in many situations, the rules will be assigned to a processing point by a higher-level interface. Again, processing point is not a uniform concept that Core should support, IMO. > Primitive types: > - Could we include support for arrays or lists of elements/objects ? Not explicitly because there would be no way to iterate them. Remember that there are no loops in P. However, modules can implement structures and containers of any complexity; they would need to provide appropriate access methods, of course (find, for_each, etc.) For example, Services module is, essentially, a searchable map of services. > - Can we modify the 'identifier' to be defined as (for us C/Java programmers > who prefer using this for global static variables): > identifier = "_"/ALPHA *(ALPHA/DIGIT/"_") Yes. Please remind me if I forget. > Loops and Iterators: > - This is a powerful feature P-language could easily integrate but difficult > in an XML-based language > - 'for each element in ', 'while (expression){code}', 'do-while' I agree that it would be relatively easy to add loops to P. The rationale for not including explicit loops is that they are error/leak prone and difficult to check for correctness. We want to reduce chances that some P code loops forever or starves the proxy to death. I think this is a weak argument because time-based and memory-based limits for rule execution must be implemented at the proxy anyway. But, I guess, we do not want to push too far. See my comment about module-defined structures above as well. > Subsystems: > - I am assuming the IRML subsytem equivalent for extended functionality > would be encompassed by the Core.import("M") functionality Yes. > Failure detection/capture: > - Should we have a structure similar to 'try-catch-final' in contemporary > languages like Java/C# etc ? See current draft for how it is handled today (section "Failures"): http://www.measurement-factory.com/tmp/opes/ > - What happens in case a service cannot be found when doing 'Service.find' > ? - see notes on the interpretor below. In this case, find() returns some kind of an "undefined"/"nil" object. If used, this object will result in a failed expression or statement. This needs to be documented, of course. We also need a way to test for nil values (and for member presence, for that matter). > - What happens in case a method called in an object does not > exist/fails/throws an error/returns invalid value ... the corresponding expression fails. See section Failures in current draft at the above URL. > Interpretor & Security: > - Should the specs for the interpretor be defined or is it left for the > implementor? We already have a few interpreter-specific MUSTs. Is that what you mean by the "specs for the interpreter"? P draft _is_ the specs for the interpreter, is it not? > - Should security be enforced by the interpretor that does the > underlying processing based on P language commands? Not sure what you mean. What is your threat model? > - IMHO, If we assume that the P language runs via the interpretor > that acts as a 'Virtual Machine', all security/error > handling/authentication features are delegated to the interpretor. I think that should be implementation-dependent, but I am not sure I understand the issue fully. Note that extension modules are _not_ (cannot be) written in P so it is impossible to do what Java tries to achieve with its security model. This is a good thing -- we do not want to invent a new general-purpose language to write modules! Does that answer your question? Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Tue Sep 16 21:04:15 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21984 for ; Tue, 16 Sep 2003 21:04:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zQjz-0005jJ-00 for opes-archive@ietf.org; Tue, 16 Sep 2003 21:04:19 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19zQjz-0005jF-00 for opes-archive@ietf.org; Tue, 16 Sep 2003 21:04:19 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8H0q5eo015198 for ; Tue, 16 Sep 2003 17:52:05 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8H0q5tR015197 for ietf-openproxy-bks; Tue, 16 Sep 2003 17:52:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from motgate5.mot.com (motgate5.mot.com [144.189.100.105]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8H0q4eo015191 for ; Tue, 16 Sep 2003 17:52:04 -0700 (PDT) (envelope-from haneef@labs.mot.com) Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h8H0q6k3022093; Tue, 16 Sep 2003 17:52:07 -0700 (MST) Received: from dryden (mvp-144-189-72-160.corp.mot.com [144.189.72.160]) by az33exr04.mot.com (Motorola/az33exr04) with SMTP id h8H0q0qa029338; Tue, 16 Sep 2003 19:52:02 -0500 From: "Anwar M. Haneef" To: "Alex Rousskov" , "OPES Group" Subject: Re: Decision on Rules Language Date: Tue, 16 Sep 2003 19:52:01 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi Alex, Thanks for your answers, they really helped clarify things. I had some more suggestions, I hope it doesn't overwhelm you: Sugestion 1: ************ (Section 3.6 ?) nil Object The (Core.)nil object is a special object that is the result of a failed expression or statement. Operations on the nil object results in a nil object, except in the case of the '==' operator in which case a semantic comparision is made to see if the compared expression also results in a nil object. The nil object cannot be used in the assignments, and would result in a fault if used. The result of a nil object being used as a condition in a conditional statement such as an if-statement results in a failure generation. The failure of finding or applying a service correctly results in nil returned as the result of the operation. In case of a situation such as: service := Services.find("opes://services/tran/german/french"); this will result in a failure generated as a result of applying the nil object in an assignment as previously mentioned. Suggestion 2: ************* XXX: Code blocks and inclusion of libraries: The P language code is divided into blocks of code, with a default intial block name of 'main'. (Members of a code block may be accessed using the '.' operator.) For example: my_freq_rule_library -> { some_older_useful_code; quick_expression -> { code; }; }; Blocks of code from other files may be included in a P language program using the 'include' statement. For example: include include-ing the P language file will perform the same function as writing the included script inline. Inclusion of external scripts need to be done prior to the primary code block of the program. For example: include main -> { my_new_code; my_freq_rule_library.quick_expression; } is equivalent to: my_freq_rule_library -> { some_older_useful_code; quick_expression -> { code; }; } main -> { my_new_code; my_freq_rule_library.quick_expression; } XXX: Failure within Code Block: Failures caught within a code block results in the program flow exiting from the current code block. For example: quick_check -> { if(Http.response.language_is("german")) { service := Services.find("opes://services/tran/german/french"); service.toDialect("southern"); Services.applyOne(service, Http.request.headers); } }; main -> { my_freq_rule_library.quick_check; more_code; }; A failure in the service related operations would result in the program flow continuing to the next expression in the 'main' block as opposed to quiting the entire P program. Suggestions 3: ************** XXX: Document lookup conflict resolution ((Section 4) The modules as part of the interpretor's native language are registered and given unique identifiers during the instantiation of the interpretor. For instance, in case of a Java interpretor, the Http modules may be registered to org.ietf.opes.PHttpModule. This way a unique mapping between module names to native entities is maintained and prevents a possibility of conflict. Modules may be added at runtime, but need to be registered with the registry within the interpretor. Thanks, Anwar -----Original Message----- From: owner-ietf-openproxy@mail.imc.org [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of Alex Rousskov Sent: Monday, September 15, 2003 8:12 PM To: Anwar M. Haneef Cc: OPES Group Subject: RE: Decision on Rules Language On Mon, 15 Sep 2003, Anwar M. Haneef wrote: > I had a few notes (mostly half or quarter-baked) in addition to your > last posting: You will find mostly half-baked answers below :-) > Scope: > - Do we need to define the scope of code within which identifiers are > recognized ? Can there be a case such as : > h := Http.makeHeader("Client-IP"); > quick_code := { > h := Http.makeHeader("Server-IP"); > contact_server(h); > }; P uses global scope. There is no big benefit from a local scope because we do not have user-defined functions. Global scope makes it easy to support/interpret/explain single-assignment. This is not yet documented. > Single assignment/Or not?: > - Should we be able to de-assign a variable (I guess this goes against the > very definition of single-assignment)? Yes, this goes against the very definition/purpose of a single-assignment. You will get a lot more complexity and fewer easy optimizations with multiple assignments (true variables). Single assignment along with lazy evaluation allows you to treat assignments as macros -- very easy to support and relatively easy to optimize. > - Is there any specific reason we would want single-assignment ? Simplicity and performance. Single assignment allows you to manipulate large protocol structures with little overhead. Without variables, you cannot reuse computed values. With true variables, you get into all sorts of complexity and memory management problems, even if you do not want to optimize. Single-assignment makes slow interpreters simple and complex interpreters fast. Single assignment allows you to reuse code as well. See current draft (the retry example: A or A or A). > Processing Point Identification: > - Mechanism for identifying the processing points identifier (PPID) as the > points of activity for the rule This is application-specific, IMO. Each module like "HTTP" would define its own notion of processing points. You should be able to find my rant about this on the OPES list archives ("Subject: processing points in draft-beck-opes-irml-03"). > - Something such as interpretor.processingPoint("X"){} could be defined -> > This info can be used by the interpretor to classify the rules based on > PPIDs for quicker retrieval by the OPES processor. Or else allow something > like: > Core.PPID("X") > { > code; > } > to deliniate the processing point associated with the code. See above. Also, I believe that in many situations, the rules will be assigned to a processing point by a higher-level interface. Again, processing point is not a uniform concept that Core should support, IMO. > Primitive types: > - Could we include support for arrays or lists of elements/objects ? Not explicitly because there would be no way to iterate them. Remember that there are no loops in P. However, modules can implement structures and containers of any complexity; they would need to provide appropriate access methods, of course (find, for_each, etc.) For example, Services module is, essentially, a searchable map of services. > - Can we modify the 'identifier' to be defined as (for us C/Java programmers > who prefer using this for global static variables): > identifier = "_"/ALPHA *(ALPHA/DIGIT/"_") Yes. Please remind me if I forget. > Loops and Iterators: > - This is a powerful feature P-language could easily integrate but difficult > in an XML-based language > - 'for each element in ', 'while (expression){code}', 'do-while' I agree that it would be relatively easy to add loops to P. The rationale for not including explicit loops is that they are error/leak prone and difficult to check for correctness. We want to reduce chances that some P code loops forever or starves the proxy to death. I think this is a weak argument because time-based and memory-based limits for rule execution must be implemented at the proxy anyway. But, I guess, we do not want to push too far. See my comment about module-defined structures above as well. > Subsystems: > - I am assuming the IRML subsytem equivalent for extended functionality > would be encompassed by the Core.import("M") functionality Yes. > Failure detection/capture: > - Should we have a structure similar to 'try-catch-final' in contemporary > languages like Java/C# etc ? See current draft for how it is handled today (section "Failures"): http://www.measurement-factory.com/tmp/opes/ > - What happens in case a service cannot be found when doing 'Service.find' > ? - see notes on the interpretor below. In this case, find() returns some kind of an "undefined"/"nil" object. If used, this object will result in a failed expression or statement. This needs to be documented, of course. We also need a way to test for nil values (and for member presence, for that matter). > - What happens in case a method called in an object does not > exist/fails/throws an error/returns invalid value ... the corresponding expression fails. See section Failures in current draft at the above URL. > Interpretor & Security: > - Should the specs for the interpretor be defined or is it left for the > implementor? We already have a few interpreter-specific MUSTs. Is that what you mean by the "specs for the interpreter"? P draft _is_ the specs for the interpreter, is it not? > - Should security be enforced by the interpretor that does the > underlying processing based on P language commands? Not sure what you mean. What is your threat model? > - IMHO, If we assume that the P language runs via the interpretor > that acts as a 'Virtual Machine', all security/error > handling/authentication features are delegated to the interpretor. I think that should be implementation-dependent, but I am not sure I understand the issue fully. Note that extension modules are _not_ (cannot be) written in P so it is impossible to do what Java tries to achieve with its security model. This is a good thing -- we do not want to invent a new general-purpose language to write modules! Does that answer your question? Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Wed Sep 17 00:47:44 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28903 for ; Wed, 17 Sep 2003 00:47:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zUEH-0000Tg-00 for opes-archive@ietf.org; Wed, 17 Sep 2003 00:47:49 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19zUEG-0000Tb-00 for opes-archive@ietf.org; Wed, 17 Sep 2003 00:47:48 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8H4aAeo022688 for ; Tue, 16 Sep 2003 21:36:10 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8H4aADA022687 for ietf-openproxy-bks; Tue, 16 Sep 2003 21:36:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8H4a9eo022682 for ; Tue, 16 Sep 2003 21:36:09 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h8H4aCl6011385; Tue, 16 Sep 2003 22:36:12 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h8H4aBWV011384; Tue, 16 Sep 2003 22:36:11 -0600 (MDT) (envelope-from rousskov) Date: Tue, 16 Sep 2003 22:36:11 -0600 (MDT) From: Alex Rousskov To: OPES Group Subject: Re: Decision on Rules Language In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 16 Sep 2003, Anwar M. Haneef wrote: > Sugestion 1: > ************ > (Section 3.6 ?) nil Object While we might need a concept of an undefined value, I think we should be able to get away without the nil object as a magic constant/value. Perl does that, for example. Nil objects seem to be required only when you support pointers, and P has no pointers. Please see below for more specifics. > The (Core.)nil object is a special object that is the result of a > failed expression or statement. Operations on the nil object results > in a nil object, except in the case of the '==' operator in which > case a semantic comparision is made to see if the compared > expression also results in a nil object. I think we can simplify quite a bit: Any use of an undefined value must result in a failure (and not not another nil object). This makes it easy to catch errors and abort early if needed. It also has a more clear/uniform/straightforward semantics. To make this interface complete, we would then need an unary operator to test both for nil objects and member presence: if (exists service) { ... }; if (exists Http.message.requestLine) { ... }; or if (defined service) { ... }; if (defined Http.message.requestLine) { ... }; Note that the operator takes a name as input, it does not use the value the name represents. No need for a special "nil" constant/token! Did I miss any use cases? BTW, which name (exists or defined or something else) would you prefer? I wish one could type the existential predicate using ASCII :). Moreover, we may be able to get rid of the whole "undefined value" concept and use failures instead: if anything goes wrong, the code fails. Failed code can be detected/caught using "or" operator. The latter part is already documented. To detect and substitute for missing services, for example, one would write: { service := Services.find("A"); } or { service := Services.find("B"); } Even a simpler expression below can probably be supported within the current design, perhaps after defining "or" operator more clearly: service := Services.find("A") or Services.find("B"); Do you think using failures like that is sufficient? > The nil object cannot be used in the assignments, and would result > in a fault if used. The result of a nil object being used as a > condition in a conditional statement such as an if-statement results > in a failure generation. > > The failure of finding or applying a service correctly results in > nil returned as the result of the operation. In case of a situation > such as: > > service := Services.find("opes://services/tran/german/french"); > > this will result in a failure generated as a result of applying the > nil object in an assignment as previously mentioned. Agreed. The above no-undefined-use rule covers all these cases, IMO (but using failure feature instead seems cleaner). What do you think? > Suggestion 2: > ************* > XXX: Code blocks and inclusion of libraries: > > The P language code is divided into blocks of code, with a default intial > block name of 'main'. (Members of a code block may be accessed using the '.' > operator.) For example: > > my_freq_rule_library -> { > some_older_useful_code; > quick_expression -> { > code; > }; > }; I am probably missing something important, but how is that different from the current mechanism of assigning a piece of code? my_freq_rule_library := { some_older_useful_code; quick_expression := ...; }; Did you overlook that hidden(?) possibility or can your proposal do more than name a piece of code? > Blocks of code from other files may be included in a P language program > using the 'include' statement. For example: > > include This is already supported, I believe: my_freq_rule_library := Core.import("my_freq_rule_library.p"); The algorithm to find module using its string name ("my_freq_rule_library.p") is Core implementation-dependent. I would suggest that environments that support loading modules from P files, use more explicit name syntax: Core.import("file://my_freq_rule_library.p"); or some such. Http and other well-known module names should probably be URIs (you talk about a similar requirement below). > XXX: Failure within Code Block: > > Failures caught within a code block results in the program flow > exiting from the current code block. For example: That is the current requirement as well, except the failure is propagated until caught with an "or" trap. See current draft. > A failure in the service related operations would result in the > program flow continuing to the next expression in the 'main' block > as opposed to quiting the entire P program. The "next expression" part may not be desirable because it would leave certain failures undetected. Programmers must be explicit if they want to ignore an error: { /* code that may fail */ } or {}; I believe current failure rules are close to exceptions in modern programming languages. Do you agree that the current failure design is sufficient to address your needs or do you see any missing pieces/flaws? > Suggestions 3: > ************** > > XXX: Document lookup conflict resolution ((Section 4) > > The modules as part of the interpretor's native language are > registered and given unique identifiers during the instantiation of > the interpretor. For instance, in case of a Java interpretor, the > Http modules may be registered to org.ietf.opes.PHttpModule. This > way a unique mapping between module names to native entities is > maintained and prevents a possibility of conflict. Modules may be > added at runtime, but need to be registered with the registry within > the interpretor. Yes, I agree that modules should be identified by [unique-per-interpreter-invocation] URIs and that those URIs have to be known to the interpretor (or it would not know which module to import!). This is indeed undocumented but needs to be. Thanks for discovering more missing pieces and suggesting specific improvements. I will try to incorporate all "undocumented but needs to be" features you recently pointed out into the next draft release. Please answer the above questions to resolve remaining issues. Thank you, Alex. P.S. Current P draft (already submitted for publication as a WG document) is at http://www.measurement-factory.com/tmp/opes/ From owner-ietf-openproxy@mail.imc.org Wed Sep 17 10:01:39 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11763 for ; Wed, 17 Sep 2003 10:01:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zcsM-0006HK-00 for opes-archive@ietf.org; Wed, 17 Sep 2003 10:01:46 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19zcsL-0006HH-00 for opes-archive@ietf.org; Wed, 17 Sep 2003 10:01:46 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8HDpCeo000586 for ; Wed, 17 Sep 2003 06:51:12 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8HDpCvg000585 for ietf-openproxy-bks; Wed, 17 Sep 2003 06:51:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8HDpAeo000579 for ; Wed, 17 Sep 2003 06:51:11 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11300; Wed, 17 Sep 2003 09:51:03 -0400 (EDT) Message-Id: <200309171351.JAA11300@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-openproxy@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-opes-rules-p-00.txt Date: Wed, 17 Sep 2003 09:51:03 -0400 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Pluggable Edge Services Working Group of the IETF. Title : P: Message Processing Language Author(s) : A. Beck, A. Rousskov Filename : draft-ietf-opes-rules-p-00.txt Pages : 22 Date : 2003-9-17 P is a simple configuration language designed for specification of message processing instructions at application proxies. P can be used to instruct an intermediary how to manipulate the application message being proxied. Such instructions are needed in an Open Pluggable Edge Services (OPES) context. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opes-rules-p-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-opes-rules-p-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-opes-rules-p-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-17093227.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-opes-rules-p-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-opes-rules-p-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-17093227.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-openproxy@mail.imc.org Wed Sep 17 14:42:17 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23284 for ; Wed, 17 Sep 2003 14:42:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zhFw-000233-00 for opes-archive@ietf.org; Wed, 17 Sep 2003 14:42:24 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19zhFo-00022p-00 for opes-archive@ietf.org; Wed, 17 Sep 2003 14:42:16 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8HIHvej011250 for ; Wed, 17 Sep 2003 11:17:57 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8HIHvG1011249 for ietf-openproxy-bks; Wed, 17 Sep 2003 11:17:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8HIHuej011243 for ; Wed, 17 Sep 2003 11:17:56 -0700 (PDT) (envelope-from haneef@labs.mot.com) Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h8HIHvAE015761 for ; Wed, 17 Sep 2003 11:17:57 -0700 (MST) Received: from dryden ([10.7.68.49]) by az33exr04.mot.com (Motorola/az33exr04) with SMTP id h8HIHsqa001500 for ; Wed, 17 Sep 2003 13:17:55 -0500 From: "Anwar M. Haneef" To: "OPES Group" Subject: RE: Decision on Rules Language Date: Wed, 17 Sep 2003 13:17:54 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi Alex, >> The (Core.)nil object is a special object that is the result of a >> failed expression or statement. Operations on the nil object results >> in a nil object, except in the case of the '==' operator in which >> case a semantic comparision is made to see if the compared >> expression also results in a nil object. > >I think we can simplify quite a bit: Any use of an undefined value >must result in a failure (and not not another nil object). This makes >it easy to catch errors and abort early if needed. It also has a more >clear/uniform/straightforward semantics. I agree with this. >Note that the operator takes a name as input, it does not use the >value the name represents. No need for a special "nil" >constant/token! > >Did I miss any use cases? > >BTW, which name (exists or defined or something else) would you >prefer? I wish one could type the existential predicate using >ASCII :). I would go with defined, since it goes with the term 'undefined' (even if we decide to get rid of the 'undefined value' concept). >To detect and substitute for missing services, for example, one would >write: > > { service := Services.find("A"); } or > { service := Services.find("B"); } > >Even a simpler expression below can probably be supported within the >current design, perhaps after defining "or" operator more clearly: > > service := Services.find("A") or Services.find("B"); > >Do you think using failures like that is sufficient? I would think that we should stay with maintaining the "{}" brackets before the or for clarity - especially for cases with multiple statements within the blocks. Also in section 2, we would need to add: Section 2: expression = name / function-call / "{" code "}" *( "or {" code "}" ) >> >> this will result in a failure generated as a result of applying the >> nil object in an assignment as previously mentioned. > >Agreed. The above no-undefined-use rule covers all these cases, IMO >(but using failure feature instead seems cleaner). What do you think? Yes, I would agree with this as well. >> XXX: Code blocks and inclusion of libraries: >> my_freq_rule_library -> { >> some_older_useful_code; >> quick_expression -> { >> code; >> }; >> }; > >I am probably missing something important, but how is that different >from the current mechanism of assigning a piece of code? The key difference here was unique identification of the 'member code' within a block. By 'member code', I refer to the ability to identify the block of code assigned to 'quick_expression' within the larger block, 'my_freq_rule_library'. This might be useful when including libraries where there might be conflicts due single assignment. Included libraries are identifed by a unique code-block name, preventing conflict of names. This might make large rule files more structured similar to 'rule' blocks ("") in IRML deliniated rules. >Did you overlook that hidden(?) possibility or can your proposal do >more than name a piece of code? I wasn't sure if the assignment of code with a name was intended to do this as well. >> Blocks of code from other files may be included in a P language program >> using the 'include' statement. For example: >This is already supported, I believe: > > my_freq_rule_library := Core.import("my_freq_rule_library.p"); True, I hadn't thought of Core.import being used that way. I agree that the algorithm to find module using its string name is left to the Core implementation. Although, I would suggest that we do mention how the code is imported and appended to the program that is including this. >("my_freq_rule_library.p") is Core implementation-dependent. I would >suggest that environments that support loading modules from P files, >use more explicit name syntax: > > Core.import("file://my_freq_rule_library.p"); Should these suggestions be mentioned in the draft as 'recommended practices' ? >The "next expression" part may not be desirable because it would leave >certain failures undetected. Programmers must be explicit if they want >to ignore an error: > > { /* code that may fail */ } or {}; > >I believe current failure rules are close to exceptions in modern >programming languages. Do you agree that the current failure design is >sufficient to address your needs or do you see any missing >pieces/flaws? This seems sufficient. >Thanks for discovering more missing pieces and suggesting specific >improvements. I will try to incorporate all "undocumented but needs to >be" features you recently pointed out into the next draft release. Glad to be of help. Thanks, Anwar From owner-ietf-openproxy@mail.imc.org Wed Sep 17 15:07:43 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24249 for ; Wed, 17 Sep 2003 15:07:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zheX-0002Cv-00 for opes-archive@ietf.org; Wed, 17 Sep 2003 15:07:49 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19zheX-0002Cq-00 for opes-archive@ietf.org; Wed, 17 Sep 2003 15:07:49 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8HImHej012559 for ; Wed, 17 Sep 2003 11:48:17 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8HImHuV012558 for ietf-openproxy-bks; Wed, 17 Sep 2003 11:48:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8HImGej012551 for ; Wed, 17 Sep 2003 11:48:16 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8HImBW04526 for ; Wed, 17 Sep 2003 14:48:11 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Sep 2003 14:48:11 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD75406EA4DEE@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: ietf-openproxy@imc.org Subject: draft-ietf-opes-end-comm-01 Feedback Needed ASAP Date: Wed, 17 Sep 2003 14:48:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37D4C.3D1F083A" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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_01C37D4C.3D1F083A Content-Type: text/plain All, Need feedback on the draft ASAP so we can issue WGLC. I also, need help in tracing examples, please send your thoughs ASAP Abbie ------_=_NextPart_001_01C37D4C.3D1F083A Content-Type: text/html draft-ietf-opes-end-comm-01 Feedback Needed ASAP

All,

Need feedback on the draft ASAP so we can issue WGLC.

I also, need help in tracing examples, please send your thoughs ASAP


Abbie

------_=_NextPart_001_01C37D4C.3D1F083A-- From owner-ietf-openproxy@mail.imc.org Wed Sep 17 16:27:48 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27717 for ; Wed, 17 Sep 2003 16:27:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ziu3-00031v-00 for opes-archive@ietf.org; Wed, 17 Sep 2003 16:27:55 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19ziu2-00031r-00 for opes-archive@ietf.org; Wed, 17 Sep 2003 16:27:55 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8HKEKej015465 for ; Wed, 17 Sep 2003 13:14:20 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8HKEK3J015464 for ietf-openproxy-bks; Wed, 17 Sep 2003 13:14:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8HKEIej015459 for ; Wed, 17 Sep 2003 13:14:18 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h8HKEKAs036007; Wed, 17 Sep 2003 14:14:20 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h8HKEK3i036006; Wed, 17 Sep 2003 14:14:20 -0600 (MDT) (envelope-from rousskov) Date: Wed, 17 Sep 2003 14:14:20 -0600 (MDT) From: Alex Rousskov To: "Anwar M. Haneef" cc: OPES Group Subject: RE: Decision on Rules Language In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 17 Sep 2003, Anwar M. Haneef wrote: > >To detect and substitute for missing services, for example, one > >would write: > > > > { service := Services.find("A"); } or > > { service := Services.find("B"); } > > > >Even a simpler expression below can probably be supported within > >the current design, perhaps after defining "or" operator more > >clearly: > > > > service := Services.find("A") or Services.find("B"); > > > >Do you think using failures like that is sufficient? > > I would think that we should stay with maintaining the "{}" brackets > before the or for clarity - especially for cases with multiple > statements within the blocks. Also in section 2, we would need to > add: > > Section 2: > expression = > name / function-call / "{" code "}" *( "or {" code "}" ) Not exactly. The "... ; more to be defined (logical and arithmetic expressions)" part in the current BNF just needs to be defined. Roughly, expression = name / function-call / "{" code "}" unaryOp expression / expression binaryOp expression binaryOp = "and" / "or" / ... Code {block} is just one of the expression atoms, no special treatment is needed in BNF or in the interpreter. What is missing though, is cblock in the statement definition: statement = assignment / function-call / if-statement / cblock cblock = "{" code "}" Will add. > >> XXX: Code blocks and inclusion of libraries: > >> my_freq_rule_library -> { > >> some_older_useful_code; > >> quick_expression -> { > >> code; > >> }; > >> }; > > > >I am probably missing something important, but how is that different > >from the current mechanism of assigning a piece of code? > > The key difference here was unique identification of the 'member > code' within a block. By 'member code', I refer to the ability to > identify the block of code assigned to 'quick_expression' within the > larger block, 'my_freq_rule_library'. Do you want to refer to my_freq_rule_library.quick_expression from outside of the my_freq_rule_library block? If you do not, then this is already supported. If you do, then this is equivalent to user-defined structures which, I would argue, is a too-heavy feature for P. > This might be useful when including libraries where there might be > conflicts due single assignment. Included libraries are identifed by > a unique code-block name, preventing conflict of names. But libraries are already identified by a unique name on the left hand side of the assignment, when they are imported: uniqueName := Core.import(module_id); Thus, importing a module cannot lead to name conflicts because all references to the module would be via uniqueName. Aggressive use of Core.lookup() can lead to multiple objects potentially accessible under the same name. There are several known solutions: - remove Core.lookup functionality (but I do not want to write "Http." all the time if all I use is the HTTP module) - last applicable module in Core.lookup() order wins (but that may bring big surprises when a newer version of the last module includes names that match already used names from the previous module Core.lookup(m0); Core.lookup(m1); if (foo) { ... } /* used to be m0.foo, now m1.foo */ ) - all names are visible, but interpreter fails if there is a conflict (ugly because it is difficult to predict whether there will be conflicts ahead of time -- we may not know all the names that some module will imports in the future) The non-trivial use case I would like to support is this: Smtp := Core.import("SMTP"); Http := Core.import("HTTP"); /* handle SMTP */ { Core.lookup(Smtp); ... } /* handle HTTP */ { Core.lookup(Http); ... } The above should lead to no conflicts regardless of what SMTP and HTTP modules import or export. I also do not like the recursive nature of this: Core.lookup(Core); I suspect that the lookup facility needs to be handled at the language level, not Core module level. I though I can get away without it, but this does not look good. This problem is common to all languages that support namespaces. Would you care to research the namespace issue in other languages (XML, C++, Java) and tell us what the common solution seems to be, if any. > This might make large rule files more structured similar to 'rule' > blocks ("") in IRML deliniated rules. Is the "{ code }" construct equivalent to ""? What > >> Blocks of code from other files may be included in a P language program > >> using the 'include' statement. For example: > > >This is already supported, I believe: > > > > my_freq_rule_library := Core.import("my_freq_rule_library.p"); > > True, I hadn't thought of Core.import being used that way. I agree > that the algorithm to find module using its string name is left to > the Core implementation. Although, I would suggest that we do > mention how the code is imported and appended to the program that is > including this. Agreed. > >("my_freq_rule_library.p") is Core implementation-dependent. I would > >suggest that environments that support loading modules from P files, > >use more explicit name syntax: > > > > Core.import("file://my_freq_rule_library.p"); > > Should these suggestions be mentioned in the draft as 'recommended > practices' ? I think they should be defined/required explicitly. I suspect some RFC defines URI schemes applicable in this context. If not, we would have to document ourselves. Care to research if any RFC defines URIs suitable for a "include this resource" command? Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Wed Sep 17 22:00:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09508 for ; Wed, 17 Sep 2003 22:00:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zo6Q-0006lX-00 for opes-archive@ietf.org; Wed, 17 Sep 2003 22:01:02 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19zo6Q-0006lO-00 for opes-archive@ietf.org; Wed, 17 Sep 2003 22:01:02 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8I1lZhT031988 for ; Wed, 17 Sep 2003 18:47:35 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8I1lZk2031987 for ietf-openproxy-bks; Wed, 17 Sep 2003 18:47:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8I1lXhT031968 for ; Wed, 17 Sep 2003 18:47:33 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h8I1laAs044062; Wed, 17 Sep 2003 19:47:36 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h8I1lPWD044061; Wed, 17 Sep 2003 19:47:25 -0600 (MDT) (envelope-from rousskov) Date: Wed, 17 Sep 2003 19:47:25 -0600 (MDT) From: Alex Rousskov To: Abbie Barbir cc: ietf-openproxy@imc.org Subject: Re: draft-ietf-opes-end-comm-01 Feedback Needed ASAP In-Reply-To: <87609AFB433BD5118D5E0002A52CD75406EA4DEE@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD75406EA4DEE@zcard0k6.ca.nortel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 17 Sep 2003, Abbie Barbir wrote: > I also, need help in tracing examples, please send your thoughs ASAP Abbie, I have just added tracing support section and an example to the HTTP Adaptation draft. Please see http://www.measurement-factory.com/tmp/opes/ HTH, Alex. From owner-ietf-openproxy@mail.imc.org Thu Sep 18 13:22:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24317 for ; Thu, 18 Sep 2003 13:22:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A02Tu-00051F-00 for opes-archive@ietf.org; Thu, 18 Sep 2003 13:22:14 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A02Tt-000517-00 for opes-archive@ietf.org; Thu, 18 Sep 2003 13:22:13 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8IH3PKP056746 for ; Thu, 18 Sep 2003 10:03:25 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8IH3PV8056745 for ietf-openproxy-bks; Thu, 18 Sep 2003 10:03:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8IH3JKP056737 for ; Thu, 18 Sep 2003 10:03:20 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8IH2SJ15531; Thu, 18 Sep 2003 13:02:29 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Sep 2003 13:02:29 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD75406F16E9D@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: internet-drafts@ietf.org Cc: ietf-openproxy@imc.org, "Abbie Barbir" Subject: Request To Publish: draft-ietf-opes-end-comm-02 Date: Thu, 18 Sep 2003 13:02:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C37E06.A2589EEA" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C37E06.A2589EEA Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37E06.A2589EEA" ------_=_NextPart_001_01C37E06.A2589EEA Content-Type: text/plain Please publish the attached draft-ietf-opes-end-comm-02 as an OPES working group Internet Draft. Thank you, Abbie ------_=_NextPart_001_01C37E06.A2589EEA Content-Type: text/html Request To Publish: draft-ietf-opes-end-comm-02

Please publish the attached
 
draft-ietf-opes-end-comm-02

as an OPES working group Internet Draft.


Thank you,
Abbie

  ------_=_NextPart_001_01C37E06.A2589EEA-- ------_=_NextPart_000_01C37E06.A2589EEA Content-Type: text/plain; name="draft-ietf-opes-end-comm-02.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-opes-end-comm-02.txt" Content-Transfer-Encoding: quoted-printable Network Working Group A. = Barbir Internet-Draft Nortel = Networks Expires: March 18, 2004 September 18, = 2003 OPES processor and end points communications draft-ietf-opes-end-comm-02 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that = other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six = months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 18, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This memo documents tracing requirements for Open Pluggable Edge Services (OPES). Barbir Expires March 18, 2004 [Page = 1] =0C Internet-Draft OPES processor and end points communications = September 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 3 2. OPES Domain and OPES System . . . . . . . . . . . . . . . . = 4 3. OPES Tracing . . . . . . . . . . . . . . . . . . . . . . . . = 6 3.1 What is traceable in an OPES Flow? . . . . . . . . . . . . . = 6 3.2 Requirements for Information Related to Traceable Entities? . . . . . . . . . . . . . . . . . . . . . . . . . = 7 4. Requirements for OPES processors . . . . . . . . . . . . . . = 8 5. Requirements for callout servers . . . . . . . . . . . . . . = 9 6. Privacy considerations . . . . . . . . . . . . . . . . . . . = 10 6.1 Tracing and Trust Domains . . . . . . . . . . . . . . . . . = 10 7. How to Support Tracing . . . . . . . . . . . . . . . . . . . = 11 7.1 Tracing and OPES System Granularity . . . . . . . . . . . . = 11 7.2 Requirements for In-Band Tracing . . . . . . . . . . . . . . = 12 7.2.1 Tracing Information Granularity and Persistence levels Requirements . . . . . . . . . . . . . . . . . . . . . . . . = 12 7.3 Protocol Binding . . . . . . . . . . . . . . . . . . . . . . = 13 8. Tracing Examples . . . . . . . . . . . . . . . . . . . . . . = 14 8.1 Single OPES Processor: Detailed Trace . . . . . . . . . . . = 14 8.2 Single OPES Processor: Partial Trace . . . . . . . . . . . . = 15 8.3 Multiple OPES Processors: Full Trace . . . . . . . . . . . . = 15 8.4 Multiple OPES Processors: Partial Trace . . . . . . . . . . = 16 9. Optional Notification . . . . . . . . . . . . . . . . . . . = 18 10. IANA considerations . . . . . . . . . . . . . . . . . . . . = 20 11. Security Considerations . . . . . . . . . . . . . . . . . . = 21 Normative References . . . . . . . . . . . . . . . . . . . . = 22 Informative References . . . . . . . . . . . . . . . . . . . = 23 Author's Address . . . . . . . . . . . . . . . . . . . . . . = 23 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . = 24 Intellectual Property and Copyright Statements . . . . . . . = 25 Barbir Expires March 18, 2004 [Page = 2] =0C Internet-Draft OPES processor and end points communications = September 2003 1. Introduction The Open Pluggable Edge Services (OPES) architecture [8] enables cooperative application services (OPES services) between a data provider, a data consumer, and zero or more OPES processors. The application services under consideration analyze and possibly transform application-level messages exchanged between the data provider and the data consumer. The execution of such services is governed by a set of rules installed on the OPES processor. The rules enforcement can trigger the execution of service applications local to the OPES processor. Alternatively, the OPES processor can distribute the responsibility of service execution by communicating and collaborating with one or more remote callout servers. As described in [8], an OPES processor communicates with and invokes services on a callout server by using = a callout protocol. The work specify the requirements for providing tracing = functionality for the OPES architecture [8]. This document specifies tracing mechanisms that the OPES architecture could provide that enable data provider application to detect inappropriate client centric actions by OPES entities. The work focus on developing tracing requirements that can be used to fulfill the notification and Non-Blocking requirements [2]. In the OPES architecture document [8], there is a requirement of relaying tracing information in-band. This work investigates this possibility and discusses possible methods that could be used to detect faulty OPES processors or callout servers by end points in an OPES flow. The document is organized as follows: Section 2 defines OPES Domain and OPES System. Section 3 discusses entities that are traceable in an OPES Flow. Sections 4 and 5 discuss tracing requirements for OPES systems and callout servers. Section 6 focus on Tracing and Trust Domains. Section 7 discusses how to support tracing and provides = uses cases. Section 8 provides some examples of traces. Section 9 = examines Optional Notification. Section 9 looks into IANA considerations. Section 10 examines security considerations. Barbir Expires March 18, 2004 [Page = 3] =0C Internet-Draft OPES processor and end points communications = September 2003 2. OPES Domain and OPES System This sections clarifies the terms OPES system and OPES Domain [8]. These terms are needed in order to define what is traceable in an OPES Flow [8]. An OPES domain describes the collection of OPES entities that a single provider operates. OPES domains can be based on trust or = other operational boundaries. All entities of an "OPES Domain" MUST be in the same trust domain. This would be independent of any specific = OPES Flow. An OPES system consists of a limited set of OPES entities, parts of = a single or of multiple OPES domains, organized by (or on behalf) of either a data provider application or a data consumer application to perform authorized services on a given application message. Each = OPES entity in an OPES system MUST be directly addressable at the IP = level by a data consumer application. An OPES system can be formed in a recursive manner. An OPES system can start with either a data provider application or a data consumer application (for a given message). The OPES system then includes any OPES entity trusted by (accepting authority from) an entity that is already in the OPES system. The trust and authority delegation is viewed in the context of the given application message. As implied by the above definition, some OPES entities in the system MAY not participate in the processing of a given message. An OPES domain MUST not be an OPES sub-system. An OPES domain MUST require external resources to provide services. An OPES domain is a part of an OPES system belonging to a given operator. OPES domains have no incidence on the structure of an OPES system, but they may influence its organization for different reasons such as security, payment, quality of service, delivery parameters among others. In Figure 1 an OPES Flow is shown that traverses across various OPES Domains starting from a data provider application. A data consumer application MUST be able to receive tracing information on per message basis that enable it to determine the set of transformations that were performed on the data for a particular OPES Flow. The formation of an OPES Flow can be static or dynamic, meaning that the determination of which OPES Domains will participate in a given OPES Flow (per message basis) can be a function of business arrangements. Barbir Expires March 18, 2004 [Page = 4] =0C Internet-Draft OPES processor and end points communications = September 2003 +------------------------------------------+ | Data Consumer Application | +------------------------------------------+ ^ | +-------------------------------------------+ | OPES System | O | | | | | +-------------------------+ | P | | | OPES Domain | | | | | +---------------+ | | E | | | | OPES Entity | | | | | | +---------------+ | | S | | | . | | | | | . | | | | | +---------------+ | | F | | | |Callout Server | | | | | | +---------------+ | | L | | | | | | | +-------------------------+ | O | | . | | | . | W | | +-------------------------+ | | | | OPES Domain | | | | | +---------------+ | | | | | | OPES Entity | | | | | | +---------------+ | | | | | . | | | | | . | | | | | +---------------+ | | | | | | OPES Entity | | | | | | +---------------+ | | | | +-------------------------+ | | | v | | +-----------------------------------+ | | | Data Provider Application | | | +-----------------------------------+ | | | +-------------------------------------------+ Figure 1: OPES System Barbir Expires March 18, 2004 [Page = 5] =0C Internet-Draft OPES processor and end points communications = September 2003 3. OPES Tracing Before discussing what is traceable in an OPES flow, it is = beneficial to define what tracing means. Tracing is defined as the inclusion of necessary information within a message in an OPES flow that could be used to identify the set of transformations or adaptations that have been performed on its content in an OPES System before its delivery to an end point (for example, the data consumer application). o OPES trace: application message information about OPES entities = in an OPES System that adapted that message. o OPES tracing: the process of including, manipulating, and interpreting an OPES trace in an OPES System. To emphasize, the above definition means that OPES tracing SHOULD be performed on per message basis. Trace format is dependent on the application protocol that is being adapted by OPES. Data consumer application can use OPES trace to infer the actions that have been performed by the OPES system. The architecture document requires = [8] that tracing be supported in-band. In an OPES System the task of providing tracing information, must take into account the following considerations: o Providers may be hesitant to reveal information about their internal network infrastructure. o Within a service provider network, OPES processors may be configured to use non-routable, private IP addresses. o A Data consumer applications would prefer to have a single point of contact regarding the trace information. 3.1 What is traceable in an OPES Flow? This section focuses on identifying the traceable entities in an = OPES Flow. Tracing information MUST be able to provide a data consumer application with useful information without tracing the exact OPES Processor or callout servers that adapted the data. It is up to the OPES service provider to have maintained appropriate internal detailed traces to find the answer to the data consumer applications inquiry. At the implementation level, for a given trace, an OPES entity involved in handling the corresponding application message is "traceable" or "traced" if information about it appears in that Barbir Expires March 18, 2004 [Page = 6] =0C Internet-Draft OPES processor and end points communications = September 2003 trace. OPES entities have different levels of traceability requirements. Specifically, o An OPES system MUST add its entry to the trace. o An OPES processor SHOULD add its entry to the trace. o An OPES service SHOULD add its entry to the trace. o An OPES entity MAY manage trace information from entities that = are under its control. For example, an OPES processor may add or remove callout service entries in order to manage the size of a trace. Other considerations include: * The OPES processor MAY have a fixed configuration that enable it to respond to tracing inquires. * The OPES processor MAY insert a summary of the services that = it controls. The summary can be used to respond to tracing inquiries. * The OPES processor MAY package tracing information related to the entities that it control based on the policy of a given OPES System. From an OPES context, a good tracing approach is similar to a = trouble ticket ready for submission to a known address. The trace in itself is not necessarily a detailed description of what has happened. It = is the responsibility of the operator to resolve the problems. 3.2 Requirements for Information Related to Traceable Entities? The requirements for information as related to entities that are traceable in an OPES flow are: o The privacy policy at the time it dealt with the message o Identification of the party responsible for setting and = enforcing that policy o Information pointing to a technical contact o Information that identifies, to the technical contact, the OPES processors involved in processing the message. Barbir Expires March 18, 2004 [Page = 7] =0C Internet-Draft OPES processor and end points communications = September 2003 4. Requirements for OPES processors In order to facilitate compliance, the concept of an "OPES system" being traceable, requires that each OPES processor MUST support tracing. Policy can be set that defines which domain has authorization to turn on tracing and its granularity. An OPES provider can have its private policy for trace information, but it MUST support tracing mechanisms and it MUST reveal its policy. The requirements for OPES processors that are applicable to tracing are: o Each OPES processor MUST belong to a single OPES Domain. o Each OPES processor MUST have a Unique Identity in that Domain. o Each OPES processor MUST support tracing, policy can be used to turn tracing on and to determine its granularity. Barbir Expires March 18, 2004 [Page = 8] =0C Internet-Draft OPES processor and end points communications = September 2003 5. Requirements for callout servers In an OPES system, it is the task of an OPES processor to add trace records to application messages. In this case, the callout servers that uses the OCP protocol [5] are not affected by tracing requirements. In order for an OCP protocol to be tracing neutral, an OPES processor in an OPES system MUST be able to meet the following requirements: o Callout services adapt payload regardless of the application protocol in use and leave header adjustment to OPES processor. o OPES processor SHOULD be able to trace it's own invocation and service(s) execution since they understand the application protocol. o Callout servers MAY be able to add their own OPES trace records to application level messages. Barbir Expires March 18, 2004 [Page = 9] =0C Internet-Draft OPES processor and end points communications = September 2003 6. Privacy considerations 6.1 Tracing and Trust Domains A trust domain may include several OPES systems and entities. Within a trust domain, there MUST be at least support for one trace entry per OPES system. Entities outside of that system may or may not see any traces, depending on domain policies or configuration. For example, if an OPES system is on the content provider "side", end-users are not guaranteed any traces. If an OPES system is = working inside end-user domain, the origin server is not guaranteed any traces related to user requests. Barbir Expires March 18, 2004 [Page = 10] =0C Internet-Draft OPES processor and end points communications = September 2003 7. How to Support Tracing In order to support tracing, the following aspects must be = addressed: o There MUST be a System Identifier that identify a domain that is employing an OPES system. o An OPES processor MUST be able to be uniquely identified (MUST have an Identifier) within a system. o An OPES processor SHOULD add its identification to the trace. o An OPES processor SHOULD add to the trace identification of = every callout service that received the application message. o If the policy in an OPES system requires an OPES processor to = turn tracing on, then the OPES processor MUST add to the trace identification of the "system or entity" it belongs to. "System" ID MUST make it possible to access "system" privacy policy. o An OPES processor MAY group the above information for sequential trace entries having the same "system/entity" ID. In other = words, trace entries produced within the same "system or entity" MAY = be merged or aggregated into a single less detailed trace entry. o An OPES processor MAY delegate trace management to a callout service within the same "system or entity". 7.1 Tracing and OPES System Granularity There are two distinct uses of traces. First, a trace SHOULD enable the "end (content producer or consumer) to detect OPES processor presence within end's trust domain. Such "end" should be able to see a trace entry, but does not need to be able to interpret it beyond identification of the trust domain(s). Second, the domain administrator SHOULD be able to take a trace = entry (possibly supplied by an "end? as an opaque string) and interpret = it. The administrator must be able to identify OPES processor(s) = involved and may be able to identify applied adaptation services along with other message-specific information. That information SHOULD help to explain what OPES entities were involved and the actions that they performed. It may be impractical to provide all the required information in all cases. This document view a trace record as a hint, as opposed to an exhaustive audit. Since the administrators of various trust domains can have various Barbir Expires March 18, 2004 [Page = 11] =0C Internet-Draft OPES processor and end points communications = September 2003 ways of looking into tracing, they MAY require the choice of freedom in what to put in trace records and how to format them. Trace = records should be easy to extend beyond basic OPES requirements. Trace management algorithms should treat trace records as opaque data to the extent possible. It is not expected that entities in one trust domain to be able to get all OPES-related feedback from entities in other trust domains. For example, if an end-user suspects that a service was corrupted by a callout service, then, there is no guarantee that the user will be able to identify that service, contact its owner, or debug it, = unless the service is within its trust domain. This is no different from = the current situation where it is impossible, in general, to know the contact person for an application on an origin server that generates corrupted HTML; and even if the person is known, one should not expect that person to respond to end-user queries. 7.2 Requirements for In-Band Tracing The OPES architecture [8] states that traces must be in-band. The support of this design goal is dependent on the specifics of the message application level protocol that is being used in an OPES flow. In-band tracing limits the type of application protocols that OPES can support. The details of what a trace record can convey is also dependent on the choice of the application level protocol. For these reasons, this work documents requirements for application protocols that need to support OPES traces. However, the = architecture does not prevent implementers of developing out-of-band protocols = and techniques to address the above limitation. 7.2.1 Tracing Information Granularity and Persistence levels Requirements In order to be able to trace entities that have acted on an application message in an OPES flow, there may be requirements to keep information that is related to the following: o Message-related information: All data that describes specific actions performed on the message SHOULD be provided with that message, as there is no other way to find message level details = at a later stage. o Session related information: Session level data MUST be preserved for the duration of the session. OPES processor is responsible = for inserting notifications if session-level information changes. o End-point related data: What profile is activated? Where to get Barbir Expires March 18, 2004 [Page = 12] =0C Internet-Draft OPES processor and end points communications = September 2003 profile details? Where to set preferences? 7.3 Protocol Binding The task of adding tracing information is application protocol specific. Separate documents will address HTTP and other protocols. This work documents what tracing information is required and some common tracing elements. Barbir Expires March 18, 2004 [Page = 13] =0C Internet-Draft OPES processor and end points communications = September 2003 8. Tracing Examples This section provides some examples of tracing that could be generated by an OPES System. The examples are based on HTTP [3] and use HTTP extension headers as given in [6]. In [6] trace entries are supplied using HTTP extension message headers. These headers are defined using #list constructs. A valid HTTP message may contain multiple entries of each header. In an OPES Systems, these headers MUST be used to represent the trace entries. In [6], the following HTTP extensions are defined: OPES-System =3D "OPES-System" ":" #trace-entry OPES-Processor =3D "OPES-Processor" ":" #trace-entry OPES-Service =3D "OPES-Service" ":" #trace-entry trace-entry =3D opes-agent-id *( ";" parameter ) opes-agent-id =3D absoluteURI 8.1 Single OPES Processor: Detailed Trace This example consider the case of an OPES System consisting of a single OPES Processor that is capable of locally performing three OPES services. A data consumer application may receive the following HTTP response message header after OPES adaptations have been applied: HTTP/1.1 200 OK Date: Wed, 15 Nov 1995 06:25:24 GMT Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT Content-type: application/octet-stream OPES-System: http://www.example-opes-systemA.com/ opes?session=3Dac79a7901549f56 OPES-Service: http:// www.example-opes-systemA.com /?sid=3D123 OPES-Service: http:// www.example-opes-systemA.com = /cat/?sid=3D124 OPES-Service: http:// www.example-opes-systemA.com = /cat/?sid=3D125 Barbir Expires March 18, 2004 [Page = 14] =0C Internet-Draft OPES processor and end points communications = September 2003 In this example, the trace has identified the OPES System and all = the OPES services that were performed on the data consumer application original request. 8.2 Single OPES Processor: Partial Trace In this example, the OPES System consisting of a two OPES Processor. Each Processor is capable of locally performing many OPES services. = A data consumer application may receive the following HTTP response message header after OPES adaptations have been applied: HTTP/1.1 200 OK Date: Wed, 15 Nov 1995 06:25:24 GMT Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT Content-type: application/octet-stream OPES-System: http://www.example-opes-systemA.com/ opes?session=3Dac79a7901549f56 OPES-Service: http:// www.example-opes-systemA.com /?sid=3D123 OPES-Service: http:// www.example-opes-systemA.com = /cat/?sid=3D124 ; Mode =3D Aggregate In this example, several OPES services may be performed on the request. However, the trace has one entry that fully identifies one service and the other services are identified through a common ID. The OPES system is expected to be able to detail the other services when queried by the data consumer application. 8.3 Multiple OPES Processors: Full Trace In this example, the OPES System consisting of a two OPES = Processors. Each processor is capable of locally performing two OPES services. A data consumer application may receive the following HTTP response message header after OPES adaptations have been applied: HTTP/1.1 200 OK Date: Wed, 15 Nov 1995 06:25:24 GMT Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT Content-type: application/octet-stream Barbir Expires March 18, 2004 [Page 15]= =0C Internet-Draft OPES processor and end points communications = September 2003 OPES-System: http://www.example-opes-systemA.com/ opes?session=3Dac79a7901549f56 OPES-Service: http:// www.example-opes-Service-Provider1.com = /cat/ ?sid=3D123 OPES-Service: http:// www.example-opes-Service-Provider1.com = /cat/ ?sid=3D124 OPES-Service: http:// www.example-opes-Service-Provider2.com = /xxx/ ?sid=3D111 OPES-Service: http:// www.example-opes-Service-Provider2.com = /xxx/ ?sid=3D112 In this example, the trace has identified the OPES System and all = the OPES services that were performed on the data consumer application original request. 8.4 Multiple OPES Processors: Partial Trace In this example, the OPES System consisting of a two OPES = Processors. Each processor is capable of locally performing several OPES services. A data consumer application may receive the following HTTP response message header after OPES adaptations have been applied: HTTP/1.1 200 OK Date: Wed, 15 Nov 1995 06:25:24 GMT Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT Content-type: application/octet-stream OPES-System: http://www.example-opes-systemA.com/ opes?session=3Dac79a7901549f56 OPES-Service: http:// www.example-opes-Service-Provider1.com = /cat/ ?sid=3D123 OPES-Service: http:// www.example-opes-Service-Provider1.com = /cat/ ?sid=3D124 ; Mode A OPES-Service: http:// www.example-opes-Service-Provider2.com = /xxx/ ?sid=3D111 OPES-Service: http:// www.example-opes-Service-Provider2.com = /xxx/ ?sid=3D112 ; Mode B Barbir Expires March 18, 2004 [Page = 16] =0C Internet-Draft OPES processor and end points communications = September 2003 In this example, several OPES services may be performed on the request. However, the trace partially indicates the services that were performed. The OPES system is expected to be able to detail the other services when queried by the data consumer application. Barbir Expires March 18, 2004 [Page = 17] =0C Internet-Draft OPES processor and end points communications = September 2003 9. Optional Notification This section examines IAB [2] considerations (3.1) and (3.2) regarding notification in an OPES architecture. Notification propagates in opposite direction of tracing and cannot be attached to the application messages that it notifies about. Notification can be done out-band and may require the development of a new protocol. The direction of data flow for tracing and notification are depicted in Figure 2. Notification +----------------------------------------------- | | | V +---------------+ +-------+ = +---------------+ | | | | | Data Provider = | | Data Consumer | Tracing | OPES |<----->| Application = | | Application |<-----------| | = +---------------+ +---------------+ +-------+ ^ |OCP | V +---------+ | Callout | | Server | +---------+ Figure 2: Notification Flow In [9] it was argued that Notification is an expensive approach for providing tracing information. However, the current work does not prevent an OPES System from publishing policy and specifications = that allow Optional Notification. For example, an OPES System can adopt a mechanism that uses a flag that would allow a data consumer and a data provider application to signal to each other that they are interested to receive an explicit notification if an OPES service = is applied to a specific message. The value of this optional flag/field can be a URI that identifies notification method plus parameters. If a processor understands the method, it would be able to further decode the field and send a notification. The specification of the field name and format for an application protocol can be stated in the associated binding document. The details of the notification Barbir Expires March 18, 2004 [Page = 18] =0C Internet-Draft OPES processor and end points communications = September 2003 protocol is beyond the scope of this document. For example, the following HTTP header: OPES-Notify: URI *(pname=3Dpvalue) Or, My-OPES-Notify: foo=3Dbar q=3D0.5 can be used. Barbir Expires March 18, 2004 [Page = 19] =0C Internet-Draft OPES processor and end points communications = September 2003 10. IANA considerations This work does not require any IANA consideration since any actions will be addressed in [6]. Barbir Expires March 18, 2004 [Page = 20] =0C Internet-Draft OPES processor and end points communications = September 2003 11. Security Considerations The security considerations for OPES are documented in [7]. This document is a requirement document for tracing and as such does not develop any new protocols that require security considerations. Barbir Expires March 18, 2004 [Page = 21] =0C Internet-Draft OPES processor and end points communications = September 2003 Normative References [1] A. Barbir et al., "OPES Use Cases and Deployment Scenarios", Internet-Draft http://www.ietf.org/internet-drafts/ draft-ietf-opes-scenarios-01.txt, Auguest 2002. [2] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002. [3] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [4] A. Barbir et al., "Policy, Authorization and Enforcement Requirements of OPES", Internet-Draft http://www.ietf.org/ internet-drafts/draft-ietf-opes-authorization-02.txt, February 2003. [5] Rousskov, A., "OPES Callout Protocol Core", Internet-Draft http://www.ietf.org/internet-drafts/ draft-ietf-opes-ocp-core-01.txt, August 2003. [6] Rousskov, A., "HTTP adaptation with OPES", Internet-Draft TBD, September 2003. [7] A. Barbir et al., "Security Threats and Risks for Open = Pluggable Edge Services", Internet-Draft http://www.ietf.org/ internet-drafts/draft-ietf-opes-threats-02.txt, February 2003. [8] A. Barbir et al., "An Architecture for Open Pluggable Edge Services (OPES)", Internet-Draft http://www.ietf.org/ internet-drafts/draft-ietf-opes-architecture-04, December = 2002. [9] A. Barbir et al., "OPES Treatment of IAB Considerations", Internet-Draft http://www.ietf.org/internet-drafts/ draft-ietf-opes-iab-01.txt, February 2004. Barbir Expires March 18, 2004 [Page = 22] =0C Internet-Draft OPES processor and end points communications = September 2003 Informative References [10] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and = S. Waldbusser, "Terminology for Policy-Based Management", RFC 3198, November 2001. [11] L. Cranor, et. al, "The Platform for Privacy Preferences 1.0 (P3P1.0) Specification", W3C Recommendation 16 http:// www.w3.org/TR/2002/REC-P3P-20020416/ , April 2002. Author's Address Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean, Ontario K2H 8E9 Canada Phone: +1 613 763 5229 EMail: abbieb@nortelnetworks.com Barbir Expires March 18, 2004 [Page = 23] =0C Internet-Draft OPES processor and end points communications = September 2003 Appendix A. Acknowledgements Several people has contributed to this work. Many thanks to: Alex Rousskov, Hilarie Orman, Oscar Batuner, Markus Huffman, Martin Stecher, Marshall Rose and Reinaldo Penno. Barbir Expires March 18, 2004 [Page = 24] =0C Internet-Draft OPES processor and end points communications = September 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances = of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification = can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph = are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Barbir Expires March 18, 2004 [Page = 25] =0C Internet-Draft OPES processor and end points communications = September 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Barbir Expires March 18, 2004 [Page = 26] =0C ------_=_NextPart_000_01C37E06.A2589EEA-- From owner-ietf-openproxy@mail.imc.org Fri Sep 19 12:04:39 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05657 for ; Fri, 19 Sep 2003 12:04:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0G8G-0002kg-00 for opes-archive@ietf.org; Fri, 19 Sep 2003 03:56:48 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A0FzU-0001Br-00 for opes-archive@ietf.org; Fri, 19 Sep 2003 03:47:44 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8J7c6KP052449 for ; Fri, 19 Sep 2003 00:38:06 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8J7c6KI052447 for ietf-openproxy-bks; Fri, 19 Sep 2003 00:38:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8J7bxKP052396 for ; Fri, 19 Sep 2003 00:38:06 -0700 (PDT) (envelope-from haneef@labs.mot.com) Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h8J7bwNk000962 for ; Fri, 19 Sep 2003 00:37:59 -0700 (MST) Received: from dryden (mvp-192-172-8-59.corp.mot.com [192.172.8.59]) by il06exr04.mot.com (Motorola/il06exr04) with SMTP id h8J7beDd000953 for ; Fri, 19 Sep 2003 02:37:41 -0500 From: "Anwar M. Haneef" To: "OPES Group" Subject: RE: Decision on Rules Language Date: Fri, 19 Sep 2003 02:37:50 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit More comments on the latest to-do: Do we need a 'switch' statement in P ? - after all, this is a rules language with lots of if-else statments... ++++++++++++++++++++++++++++++++ Native support for Regular Expressions? These would be used a lot in a rules language. I would think one fo the concerns in a debate for having it or not would be the potential performance issue - which would be advisable? - having a pure native implementation that is loaded as part of a module or interpreting the REGEX engine that is part of the P language interpretor. Performance-wise I might assume that the native implementation might be more optimized, while on the other hand having it as part of the language would make the REGEX syntax more standard and easier to migrate P code. ++++++++++++++++++++++++++++++++ Section 2. Escape sequences for the grammar (from C++): escape-sequence: basic-escape-sequence/ octal-escape-sequence/ hex-escape-sequence basic-escape-sequence: \' \" \? \\ \a \b \f \n \r \t \v octal-escape-sequence: \octal-digit \octal-digit octal-digit \octal-digit octal-digit octal-digit hex-escape-sequence: \x hex-digit hex-escape-sequence hex-digit octal-digit: 0 / 1 / 2 / 3 / 4 / 5 / 6 / 7 hex-digit: 0 / 1 / 2 / 3 / 4 / 5 / 6 / 7 / 8 / 9 / a / b / c / d / e / f / A / B / C / D / E / F Regards, Anwar -----Original Message----- From: owner-ietf-openproxy@mail.imc.org [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of Anwar M. Haneef Sent: Friday, September 19, 2003 1:07 AM To: OPES Group Subject: RE: Decision on Rules Language Alex, I have tried to answer one of the to-dos here related to namespaces: >Thus, importing a module cannot lead to name conflicts because all >references to the module would be via uniqueName. Aggressive use of >Core.lookup() can lead to multiple objects potentially accessible >under the same name. There are several known solutions: > > - remove Core.lookup functionality > (but I do not want to write "Http." all the time > if all I use is the HTTP module) > > - last applicable module in Core.lookup() order wins > (but that may bring big surprises when a newer > version of the last module includes names that > match already used names from the previous module > Core.lookup(m0); > Core.lookup(m1); > if (foo) { ... } /* used to be m0.foo, now m1.foo */ > ) > > - all names are visible, but interpreter fails > if there is a conflict > (ugly because it is difficult to predict whether > there will be conflicts ahead of time -- we may > not know all the names that some module will > imports in the future) > >The non-trivial use case I would like to support is this: > > Smtp := Core.import("SMTP"); > Http := Core.import("HTTP"); > > /* handle SMTP */ > { > Core.lookup(Smtp); > ... > } > > /* handle HTTP */ > { > Core.lookup(Http); > ... > } > >The above should lead to no conflicts regardless of what SMTP and HTTP >modules import or export. > >I also do not like the recursive nature of this: > Core.lookup(Core); >I suspect that the lookup facility needs to be handled at the language >level, not Core module level. I though I can get away without it, but >this does not look good. In case of Java, the virtual machine is launched (equivalent to our intepretor) is launched with a default Class Loader, System Class Loader. This Class Loader is responsible for loading all the classes to run the program. This usually picks up class files from the classpath defined by the system. Users may customize the Class Loader to their needs in terms of loading the classes (such as from a database/HTTP URL etc). This may be defined when the VM is launched (its a system property, or you can write your custom class loader as the starting point of your program), in which case the System Class Loader is over-ridden or in case a Custom Class Loader is invoked in a program, it runs as a child of the System Class Loader, loading classes that the System Class Loader cannot locate. P could have similar 'system class loader' or 'System Module Loader' which launches the Core module and launches subsequent modules. This would need to be implemented at the interpretor and not as part of the Core module. Users may be given the option of defining custom loaders of modules (later ?). This loader would need to be written native to the interpretor, and not in P. BTW, that brings me to another question - why do we need a Core.lookup(X) method? Shouldn't we be able to load the namespace of the imported module by default ? - such as what is done in Java ? The 'import' feature of the interpretor should be performing the function of the 'System Module Loader' and the namespace initiator [similar to 'using namespace' in C++]. In case of namespace conflict resolution, most languages such as Java or C++ would catch the error in case there are multiple possibilities for a method or field, during compile time. Conflicting situations would call for explicit identification of the method or variable. For example: Smtp := import("SMTP"); Http := import("HTTP"); httpheader := getHeader(); senderEmailId := getSenderEmail(); might lead to a conflict in case both the HTTP and SMTP modules have the same method 'getHeader()' and would lead to compile-time error identification. The correct usage should be: Smtp := import("SMTP"); Http := import("HTTP"); httpheader := Http.getHeader(); senderEmailId := getSenderEmail(); > > Core.import("file://my_freq_rule_library.p"); > > Should these suggestions be mentioned in the draft as 'recommended > practices' ? > >I think they should be defined/required explicitly. I suspect some RFC >defines URI schemes applicable in this context. If not, we would have >to document ourselves. Care to research if any RFC defines URIs >suitable for a "include this resource" command? I'll get back to you on this. But, on a similar discussion as the one above, in case we let the module loading be a part of the interpretor and allow users to define custom module loaders - won't it be advisable to let the designers of these custom loaders/interpretors use whatever scheme is convinient to them ? Would defaulting to "file://" be restrictive ? Would there be ppl who would want to retrive their p file libraries from a http url ? Comments ? Thanks, Anwar From owner-ietf-openproxy@mail.imc.org Fri Sep 19 12:32:22 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11721 for ; Fri, 19 Sep 2003 12:32:21 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8JGCWKP013146 for ; Fri, 19 Sep 2003 09:12:32 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8JGCWTZ013145 for ietf-openproxy-bks; Fri, 19 Sep 2003 09:12:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8JGCUKP013138 for ; Fri, 19 Sep 2003 09:12:31 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h8JGCW0x099508; Fri, 19 Sep 2003 10:12:32 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h8JGCV5t099507; Fri, 19 Sep 2003 10:12:31 -0600 (MDT) (envelope-from rousskov) Date: Fri, 19 Sep 2003 10:12:31 -0600 (MDT) From: Alex Rousskov To: "Anwar M. Haneef" cc: OPES Group Subject: P module loading and lookup In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Anwar, Appreciate the research! Based on your information, and to keep things correct and simple, I would propose the following: - module importing and lookup facilities are implemented by the interpreter (not Core) and cannot be changed (C++ model) - imported modules enter name space (Java model) - ambiguities lead to interpretation-time errors - every module documents the URI it wants to be known as; URI scheme does not, by default, imply access method to the module - interpreters MAY support loading of raw P files - URIs for loading of raw P files are implementation-dependent and a "file" URI scheme is used as an example for local files - the Core module and the Services module are always available as if they were autoloaded internally before user code evaluation For example, all of the import statements below pollute global name space, but the first two provide a way for a programmer to resolve conflicts, if any. /* import HTTP module */ Http := import "http://ietf.org/opes/rules/p/HTTP"; /* import a local file */ MyStuff := import "file:/usr/local/myrules.p"; /* import a local file without naming it */ import "file:/usr/local/globalrules.p"; Please let me know if there are any better ideas or objections. We still need to investigate what HTTP module URI should look like from IETF point of view. The same info is needed for OCP: we need URIs to identify message parts and other negotiated features. Thanks, Alex. On Fri, 19 Sep 2003, Anwar M. Haneef wrote: > In case of Java, the virtual machine is launched (equivalent to our > intepretor) is launched with a default Class Loader, System Class > Loader. This Class Loader is responsible for loading all the classes > to run the program. This usually picks up class files from the > classpath defined by the system. Users may customize the Class > Loader to their needs in terms of loading the classes (such as from > a database/HTTP URL etc). This may be defined when the VM is > launched (its a system property, or you can write your custom class > loader as the starting point of your program), in which case the > System Class Loader is over-ridden or in case a Custom Class Loader > is invoked in a program, it runs as a child of the System Class > Loader, loading classes that the System Class Loader cannot locate. > > P could have similar 'system class loader' or 'System Module Loader' > which launches the Core module and launches subsequent modules. This > would need to be implemented at the interpretor and not as part of > the Core module. Users may be given the option of defining custom > loaders of modules (later ?). This loader would need to be written > native to the interpretor, and not in P. > > BTW, that brings me to another question - why do we need a > Core.lookup(X) method? Shouldn't we be able to load the namespace of > the imported module by default ? - such as what is done in Java ? > The 'import' feature of the interpretor should be performing the > function of the 'System Module Loader' and the namespace initiator > [similar to 'using namespace' in C++]. > > In case of namespace conflict resolution, most languages such as > Java or C++ would catch the error in case there are multiple > possibilities for a method or field, during compile time. > Conflicting situations would call for explicit identification of the > method or variable. For example: > > Smtp := import("SMTP"); > Http := import("HTTP"); > > httpheader := getHeader(); > senderEmailId := getSenderEmail(); > > might lead to a conflict in case both the HTTP and SMTP modules have > the same method 'getHeader()' and would lead to compile-time error > identification. The correct usage should be: > > Smtp := import("SMTP"); > Http := import("HTTP"); > > httpheader := Http.getHeader(); > senderEmailId := getSenderEmail(); > > > > > Core.import("file://my_freq_rule_library.p"); > > > > Should these suggestions be mentioned in the draft as 'recommended > > practices' ? > > > >I think they should be defined/required explicitly. I suspect some RFC > >defines URI schemes applicable in this context. If not, we would have > >to document ourselves. Care to research if any RFC defines URIs > >suitable for a "include this resource" command? > > I'll get back to you on this. But, on a similar discussion as the one above, > in case we let the module loading be a part of the interpretor and allow > users to define custom module loaders - won't it be advisable to let the > designers of these custom loaders/interpretors use whatever scheme is > convinient to them ? Would defaulting to "file://" be restrictive ? Would > there be ppl who would want to retrive their p file libraries from a http > url ? Comments ? > > Thanks, > Anwar > > From owner-ietf-openproxy@mail.imc.org Fri Sep 19 12:35:20 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06102 for ; Fri, 19 Sep 2003 12:05:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0Egz-0003Zr-00 for opes-archive@ietf.org; Fri, 19 Sep 2003 02:24:33 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A0EgN-0003XU-00 for opes-archive@ietf.org; Fri, 19 Sep 2003 02:23:55 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8J66hKP021564 for ; Thu, 18 Sep 2003 23:06:43 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8J66hNS021562 for ietf-openproxy-bks; Thu, 18 Sep 2003 23:06:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8J66fKP021550 for ; Thu, 18 Sep 2003 23:06:42 -0700 (PDT) (envelope-from haneef@labs.mot.com) Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h8J66ixQ010115 for ; Thu, 18 Sep 2003 23:06:45 -0700 (MST) Received: from dryden (mvp-192-172-8-72.corp.mot.com [192.172.8.72]) by az33exr02.mot.com (Motorola/az33exr02) with SMTP id h8J66fSt030248 for ; Fri, 19 Sep 2003 01:06:42 -0500 From: "Anwar M. Haneef" To: "OPES Group" Subject: RE: Decision on Rules Language Date: Fri, 19 Sep 2003 01:06:36 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Alex, I have tried to answer one of the to-dos here related to namespaces: >Thus, importing a module cannot lead to name conflicts because all >references to the module would be via uniqueName. Aggressive use of >Core.lookup() can lead to multiple objects potentially accessible >under the same name. There are several known solutions: > > - remove Core.lookup functionality > (but I do not want to write "Http." all the time > if all I use is the HTTP module) > > - last applicable module in Core.lookup() order wins > (but that may bring big surprises when a newer > version of the last module includes names that > match already used names from the previous module > Core.lookup(m0); > Core.lookup(m1); > if (foo) { ... } /* used to be m0.foo, now m1.foo */ > ) > > - all names are visible, but interpreter fails > if there is a conflict > (ugly because it is difficult to predict whether > there will be conflicts ahead of time -- we may > not know all the names that some module will > imports in the future) > >The non-trivial use case I would like to support is this: > > Smtp := Core.import("SMTP"); > Http := Core.import("HTTP"); > > /* handle SMTP */ > { > Core.lookup(Smtp); > ... > } > > /* handle HTTP */ > { > Core.lookup(Http); > ... > } > >The above should lead to no conflicts regardless of what SMTP and HTTP >modules import or export. > >I also do not like the recursive nature of this: > Core.lookup(Core); >I suspect that the lookup facility needs to be handled at the language >level, not Core module level. I though I can get away without it, but >this does not look good. In case of Java, the virtual machine is launched (equivalent to our intepretor) is launched with a default Class Loader, System Class Loader. This Class Loader is responsible for loading all the classes to run the program. This usually picks up class files from the classpath defined by the system. Users may customize the Class Loader to their needs in terms of loading the classes (such as from a database/HTTP URL etc). This may be defined when the VM is launched (its a system property, or you can write your custom class loader as the starting point of your program), in which case the System Class Loader is over-ridden or in case a Custom Class Loader is invoked in a program, it runs as a child of the System Class Loader, loading classes that the System Class Loader cannot locate. P could have similar 'system class loader' or 'System Module Loader' which launches the Core module and launches subsequent modules. This would need to be implemented at the interpretor and not as part of the Core module. Users may be given the option of defining custom loaders of modules (later ?). This loader would need to be written native to the interpretor, and not in P. BTW, that brings me to another question - why do we need a Core.lookup(X) method? Shouldn't we be able to load the namespace of the imported module by default ? - such as what is done in Java ? The 'import' feature of the interpretor should be performing the function of the 'System Module Loader' and the namespace initiator [similar to 'using namespace' in C++]. In case of namespace conflict resolution, most languages such as Java or C++ would catch the error in case there are multiple possibilities for a method or field, during compile time. Conflicting situations would call for explicit identification of the method or variable. For example: Smtp := import("SMTP"); Http := import("HTTP"); httpheader := getHeader(); senderEmailId := getSenderEmail(); might lead to a conflict in case both the HTTP and SMTP modules have the same method 'getHeader()' and would lead to compile-time error identification. The correct usage should be: Smtp := import("SMTP"); Http := import("HTTP"); httpheader := Http.getHeader(); senderEmailId := getSenderEmail(); > > Core.import("file://my_freq_rule_library.p"); > > Should these suggestions be mentioned in the draft as 'recommended > practices' ? > >I think they should be defined/required explicitly. I suspect some RFC >defines URI schemes applicable in this context. If not, we would have >to document ourselves. Care to research if any RFC defines URIs >suitable for a "include this resource" command? I'll get back to you on this. But, on a similar discussion as the one above, in case we let the module loading be a part of the interpretor and allow users to define custom module loaders - won't it be advisable to let the designers of these custom loaders/interpretors use whatever scheme is convinient to them ? Would defaulting to "file://" be restrictive ? Would there be ppl who would want to retrive their p file libraries from a http url ? Comments ? Thanks, Anwar From owner-ietf-openproxy@mail.imc.org Fri Sep 19 12:57:17 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14461 for ; Fri, 19 Sep 2003 12:57:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0OZR-0006CZ-00 for opes-archive@ietf.org; Fri, 19 Sep 2003 12:57:25 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A0OZB-0006C9-00 for opes-archive@ietf.org; Fri, 19 Sep 2003 12:57:09 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8JGk5KP014877 for ; Fri, 19 Sep 2003 09:46:05 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8JGk5le014876 for ietf-openproxy-bks; Fri, 19 Sep 2003 09:46:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8JGk4KP014870 for ; Fri, 19 Sep 2003 09:46:04 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h8JGk50x000448; Fri, 19 Sep 2003 10:46:05 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h8JGk5M8000447; Fri, 19 Sep 2003 10:46:05 -0600 (MDT) (envelope-from rousskov) Date: Fri, 19 Sep 2003 10:46:05 -0600 (MDT) From: Alex Rousskov To: OPES Group Subject: RE: Decision on Rules Language In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 19 Sep 2003, Anwar M. Haneef wrote: > Do we need a 'switch' statement in P ? - after all, this is a rules > language with lots of if-else statments... A "switch" statement is only better than a bunch of "if"s when all if-statement conditions start with (X == ...). In P, the "==" operator is defined for booleans and integers only. Booleans do not count (if-else works better for them). I suspect that it is somewhat unlikely situation for P rules to iterate through a bunch of integer values. IMO, what we need is to improve if-statement syntax to make a bunch of if-else-if-else-if statements look good. Added to the to-do list. > Native support for Regular Expressions? IMO, the problem with REs is not that they may take a long time to process, but that available libraries cannot be used to bound/control processing time. Many services will take a long time to process. But services are designed so that a processor can terminate them if they take too long. It is difficult to do that with RE libraries without threads or other heavy mechanisms. Thus, regular expression support should be optional (but can still be native if this working group wants them!). My vote is against native support in P because the majority of applications would find existing string operators (substring searching, essentially) and application-specific interfaces sufficient. (BTW, I will add a length() and index() string functions to Core). > These would be used a lot in a rules language. Can you give a couple of examples where REs would be essential, given available substring searching operators _and_ ability of application-specific modules to split application objects (e.g., HTTP headers) into semantically valid but smaller pieces for you? > having a pure native implementation that is loaded as part of a > module or interpreting the REGEX engine that is part of the P > language interpretor. Performance-wise I might assume that the > native implementation might be more optimized, while on the other > hand having it as part of the language would make the REGEX syntax > more standard and easier to migrate P code. I think that performance-wise both approaches would be about the same. Interpreters can use optimized libraries or modules can use optimized libraries. Native support does allow for somewhat more natural RE syntax, but it also complicates P syntax. > ++++++++++++++++++++++++++++++++ > Section 2. Escape sequences for the grammar (from C++): > > escape-sequence: > basic-escape-sequence/ > octal-escape-sequence/ > hex-escape-sequence Yeah, and we would need to add a universal-character-name as a part of string-char or escape-sequence. This all looks kind of heavy. Is there a simpler, but still complete solution? Replacing support for octal-escape-sequence and hex-escape-sequence with universal-character-name? What does XML have to offer here? Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Fri Sep 19 16:52:29 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21653 for ; Fri, 19 Sep 2003 16:52:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0SF3-0001PG-00 for opes-archive@ietf.org; Fri, 19 Sep 2003 16:52:37 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A0SEo-0001OE-00 for opes-archive@ietf.org; Fri, 19 Sep 2003 16:52:22 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8JKYjKP027371 for ; Fri, 19 Sep 2003 13:34:45 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8JKYiNc027370 for ietf-openproxy-bks; Fri, 19 Sep 2003 13:34:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8JKYhKP027364 for ; Fri, 19 Sep 2003 13:34:43 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h8JKYjvf006919; Fri, 19 Sep 2003 14:34:45 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h8JKYjXQ006918; Fri, 19 Sep 2003 14:34:45 -0600 (MDT) (envelope-from rousskov) Date: Fri, 19 Sep 2003 14:34:45 -0600 (MDT) From: Alex Rousskov To: "Anwar M. Haneef" cc: OPES Group Subject: RE: P module loading and lookup In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 19 Sep 2003, Anwar M. Haneef wrote: > >Please let me know if there are any better ideas or objections. We > >still need to investigate what HTTP module URI should look like from > >IETF point of view. The same info is needed for OCP: we need URIs to > >identify message parts and other negotiated features. > > Why do we want to restrict the URI for importing HTTP modules in > case we allow this to be interpretor implementation dependent ? > Again, why the same for OCP messages as well ? I think I am missing > something here. Please advise. I am probably not expressing myself clearly. URI in this context is just a well-known or standard "name". As a rule writer, I need to know how to tell the interpreter that I need to import a well-known HTTP module. I need to know a URI that all P interpreters out there will treat as an "HTTP module (RFC XXX) identifier". The URI is _not_ interpretor implementation dependent. The URI will be documented in the HTTP module RFC (when somebody happens to write that document, of course). Same for OCP messages: the other side needs to map the URIs I am sending in negotiation messages to particular things it knows about, like SMTP message parts or services. For all this to work, we have to document every "standard" URI (name) somewhere. What I am not sure about, is what scheme, domain, and path to use for those standard URIs. I assume they would need to be registered with IANA (to avoid conflicts with other standard URIs). I suspect IETF has some RFC that suggests appropriate URI format and registration process. I did not investigate this yet though. This is similar to URIs XML folks are using to identify their namespaces. For example, Does this clarify? Alex. From owner-ietf-openproxy@mail.imc.org Sat Sep 20 01:58:11 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12762 for ; Sat, 20 Sep 2003 01:58:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0al5-00005f-00 for opes-archive@ietf.org; Sat, 20 Sep 2003 01:58:15 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A0akq-00005Q-00 for opes-archive@ietf.org; Sat, 20 Sep 2003 01:58:00 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8K5frKP069190 for ; Fri, 19 Sep 2003 22:41:53 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8K5frHh069189 for ietf-openproxy-bks; Fri, 19 Sep 2003 22:41:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from motgate6.mot.com (motgate6.mot.com [144.189.100.106]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8K5fqKP069178 for ; Fri, 19 Sep 2003 22:41:52 -0700 (PDT) (envelope-from haneef@labs.mot.com) Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id h8K5ftGC001081 for ; Fri, 19 Sep 2003 22:41:55 -0700 (MST) Received: from dryden (mvp-144-189-72-69.corp.mot.com [144.189.72.69]) by il06exr01.mot.com (Motorola/il06exr01) with SMTP id h8K5fpqn012287 for ; Sat, 20 Sep 2003 00:41:54 -0500 From: "Anwar M. Haneef" To: Subject: Decision on Rules Language Date: Sat, 20 Sep 2003 00:41:48 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h8K5fqKP069182 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi Alex, >My vote is against native support in P because the majority of >applications would find existing string operators (substring >searching, essentially) and application-specific interfaces >sufficient. (BTW, I will add a length() and index() string functions >to Core). >> These would be used a lot in a rules language. > >Can you give a couple of examples where REs would be essential, given >available substring searching operators _and_ ability of >application-specific modules to split application objects (e.g., HTTP >headers) into semantically valid but smaller pieces for you? I suppose if you have modules that can process REGEXs as quickly, it should be all right. > Section 2. Escape sequences for the grammar (from C++): > > escape-sequence: > basic-escape-sequence/ > octal-escape-sequence/ > hex-escape-sequence > >Yeah, and we would need to add a universal-character-name as a part of >string-char or escape-sequence. This all looks kind of heavy. Is there >a simpler, but still complete solution? Replacing support for >octal-escape-sequence and hex-escape-sequence with >universal-character-name? What does XML have to offer here? Sorry, I am not well versed in this space :-( But, I have tried to write up a few (simple) examples for the examples to-do: Example1: (edited from the current version) Http := import "http://ietf.org/opes/rules/p/HTTP"; // Is the requested web document our home page? isHome := request.uri.looksLikeHome(); // Does the user send us a specific cookie? cookie := makeHeader("Cookie", "sew=23"); haveCookie := request.headers.have(cookie); if (isHome and haveCookie) { Services := import "http://ietf.org/opes/rules/p/Services"; service := Services.findOne("opes://local.net/add-lcl-content"); service.clientIp(request.clientIp); Services.applyOne(service); } Example 2: HTTP header anonymization Http := import "http://ietf.org/opes/rules/p/HTTP"; haveClientAddress := defined request.getRemoteAddress(); haveUserAgentInfo := defined request.getUserAgent(); if(haveClientAddress and haveUserAgentInfo ) { Services := import "http://ietf.org/opes/rules/p/Services"; service := Services.findOne("opes://anon.net/anonymize"); Services.applyOne(service, request.header); } //forward the request to the content server request.forwardRequest(); Example 3: SMTP Email filter Smtp := import "http://ietf.org/opes/rules/p/SMTP"; haveAttachment := message.header.getContentType() equal "multipart/mixed" if(haveAttachment) { Services := import "http://ietf.org/opes/rules/p/Services"; service := Services.findOne("opes://norton.com/VirusCheck"); Services.applyOne(service, message.body); } if ( currentUserEmail equal message.header.getSenderEmail() ) { message.returnToSender("Your attachment had a virus."); } else { message.replaceBody("The message had a virus infected attachment."); } Example 4: User-Agent-based content transcoding - This might be a more complicated example. In case you are interested, I can write this up. Being a telecom industry person, this would be more relevant for my applications. Regards, Anwar From owner-ietf-openproxy@mail.imc.org Sat Sep 20 12:53:39 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16012 for ; Sat, 20 Sep 2003 12:53:38 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8KGdlKP048935 for ; Sat, 20 Sep 2003 09:39:48 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8KGdl6C048934 for ietf-openproxy-bks; Sat, 20 Sep 2003 09:39:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8KGdkKP048929 for ; Sat, 20 Sep 2003 09:39:46 -0700 (PDT) (envelope-from haneef@labs.mot.com) Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h8KGdlxQ023233; Sat, 20 Sep 2003 09:39:47 -0700 (MST) Received: from dryden (mvp-136-182-23-178.corp.mot.com [136.182.23.178]) by az33exr01.mot.com (Motorola/az33exr01) with SMTP id h8KGdLJ1000989; Sat, 20 Sep 2003 11:39:21 -0500 From: "Anwar M. Haneef" To: "Alex Rousskov" , "OPES Group" Subject: RE: Decision on Rules Language Date: Sat, 20 Sep 2003 11:39:41 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h8KGdlKP048930 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Alex, > Section 2. Escape sequences for the grammar (from C++): > > escape-sequence: > basic-escape-sequence/ > octal-escape-sequence/ > hex-escape-sequence I haven't had a chance to look at this properly, but I do have a suggestion for the if-statement: if-statement = "if" "(" expression ")" "{" code "}" / "if" "(" expression ")" "{" code "}" "else" "{" code "}" should be: if-statement = "if" "(" expression ")" "{" code "}" / if-statement "else" "{" code "}" Regards, Anwar From owner-ietf-openproxy@mail.imc.org Sun Sep 21 15:56:09 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06318 for ; Sun, 21 Sep 2003 15:56:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1AJV-00066A-00 for opes-archive@ietf.org; Sun, 21 Sep 2003 15:56:09 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A1AJA-00065Z-00 for opes-archive@ietf.org; Sun, 21 Sep 2003 15:55:48 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8LJbhKP088338 for ; Sun, 21 Sep 2003 12:37:43 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8LJbhgm088337 for ietf-openproxy-bks; Sun, 21 Sep 2003 12:37:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8LJbgKP088332 for ; Sun, 21 Sep 2003 12:37:42 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h8LJbheK079174; Sun, 21 Sep 2003 13:37:43 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h8LJbgbS079173; Sun, 21 Sep 2003 13:37:42 -0600 (MDT) (envelope-from rousskov) Date: Sun, 21 Sep 2003 13:37:42 -0600 (MDT) From: Alex Rousskov To: "Anwar M. Haneef" cc: OPES Group Subject: RE: Decision on Rules Language In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, 20 Sep 2003, Anwar M. Haneef wrote: > I haven't had a chance to look at this properly, but I do have a suggestion for the if-statement: > > if-statement = > "if" "(" expression ")" "{" code "}" / > "if" "(" expression ")" "{" code "}" "else" "{" code "}" > > should be: > > if-statement = > "if" "(" expression ")" "{" code "}" / > if-statement "else" "{" code "}" Hmm... This allows for if () code else code else code else code which does not make sense. You probably meant something like this: if-statement = if-head *if-alt [if-tail] if-head = "if" "(" expression ")" "{" code "}" if-alt = "elsif" "(" expression ")" "{" code "}" if-tail = "else" "{" code "}" For example: if (cond1) { ... } elsif (cond2) { ... } elsif (cond3) { ... } else { ... } which is succinct, strict (no guessing which "if" the "else" part applies to), and common enough (Ada, Modula, Perl, PHP): http://merd.net/pixel/language-study/syntax-across-languages/CntrFlow.html Did I get the grammar right? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Sun Sep 21 18:04:06 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09763 for ; Sun, 21 Sep 2003 18:04:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1CJQ-0007Ah-00 for opes-archive@ietf.org; Sun, 21 Sep 2003 18:04:12 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A1CJA-00079c-00 for opes-archive@ietf.org; Sun, 21 Sep 2003 18:03:57 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8LLq9KP092438 for ; Sun, 21 Sep 2003 14:52:09 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8LLq9T6092437 for ietf-openproxy-bks; Sun, 21 Sep 2003 14:52:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8LLq8KP092432 for ; Sun, 21 Sep 2003 14:52:08 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h8LLqAeK082559; Sun, 21 Sep 2003 15:52:10 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h8LLqA5m082558; Sun, 21 Sep 2003 15:52:10 -0600 (MDT) (envelope-from rousskov) Date: Sun, 21 Sep 2003 15:52:10 -0600 (MDT) From: Alex Rousskov To: "Anwar M. Haneef" cc: ietf-openproxy@imc.org Subject: Re: Decision on Rules Language In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, 20 Sep 2003, Anwar M. Haneef wrote: > Example 4: User-Agent-based content transcoding - This might be a > more complicated example. In case you are interested, I can write > this up. Being a telecom industry person, this would be more > relevant for my applications. I would be interested to see this implemented. IMO, at least one complicated example would be good for both us writing the spec and folks considering supporting it. Thanks, Alex. P.S. I will work your other examples in, thank you for posting them! From owner-ietf-openproxy@mail.imc.org Mon Sep 22 02:26:38 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02923 for ; Mon, 22 Sep 2003 02:26:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1K9j-00030w-00 for opes-archive@ietf.org; Mon, 22 Sep 2003 02:26:43 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A1K9U-00030I-00 for opes-archive@ietf.org; Mon, 22 Sep 2003 02:26:28 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8M6EqKP035215 for ; Sun, 21 Sep 2003 23:14:52 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8M6EqWo035214 for ietf-openproxy-bks; Sun, 21 Sep 2003 23:14:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8M6EqKP035206 for ; Sun, 21 Sep 2003 23:14:52 -0700 (PDT) (envelope-from anwar@motorola.com) Received: from il06exr02.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h8M6ErBe016032; Sun, 21 Sep 2003 23:14:54 -0700 (MST) Received: from dryden (mvp-192-172-16-191.corp.mot.com [192.172.16.191]) by il06exr02.mot.com (Motorola/il06exr02) with SMTP id h8M6EpVo029621; Mon, 22 Sep 2003 01:14:51 -0500 From: "Anwar M. Haneef" To: "Alex Rousskov" , "OPES Group" Subject: RE: Decision on Rules Language Date: Mon, 22 Sep 2003 01:14:51 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h8M6EqKP035209 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit >Hmm... This allows for > if () code else code else code else code >which does not make sense. You probably meant something like this: > ... >which is succinct, strict (no guessing which "if" the "else" part applies to), >and common enough (Ada, Modula, Perl, PHP): >http://merd.net/pixel/language-study/syntax-across-languages/CntrFlow.html > >Did I get the grammar right? Yes, I believe you are right. Silly me, I guess I wasn't thinking clear when I sent the mail out. Thanks, Anwar From owner-ietf-openproxy@mail.imc.org Mon Sep 22 02:26:48 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02926 for ; Mon, 22 Sep 2003 02:26:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1K9t-000313-00 for opes-archive@ietf.org; Mon, 22 Sep 2003 02:26:53 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A1K9d-00030t-00 for opes-archive@ietf.org; Mon, 22 Sep 2003 02:26:38 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8M6AjKP034030 for ; Sun, 21 Sep 2003 23:10:45 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8M6Aj5v034029 for ietf-openproxy-bks; Sun, 21 Sep 2003 23:10:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8M6AiKP034020 for ; Sun, 21 Sep 2003 23:10:45 -0700 (PDT) (envelope-from anwar@motorola.com) Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h8M6AlNk004304; Sun, 21 Sep 2003 23:10:47 -0700 (MST) Received: from dryden (mvp-192-172-16-191.corp.mot.com [192.172.16.191]) by il06exr02.mot.com (Motorola/il06exr02) with SMTP id h8M6AjVo026394; Mon, 22 Sep 2003 01:10:45 -0500 From: "Anwar M. Haneef" To: "Alex Rousskov" , Subject: RE: Decision on Rules Language Date: Mon, 22 Sep 2003 01:10:44 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h8M6AjKP034023 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi Alex, Here is the content transcoding example. I have tried to keep it simple and yet functional. Please let me know if its too simple - I tried to simplify things since I work with this kind of functionality all the time, so I wasn't sure whether it would be difficult/easy for other people to grasp the idea quicky. Example 4: User-Agent-based content transcoding. The request is parsed for User-Agent and subscriber info. This info is used to authenticate the user and forward the request if authenticated. The response data is passed through transcoders based on their content types and finally directed to the client. Http := import "http://ietf.org/opes/rules/p/HTTP"; Services := import "http://ietf.org/opes/rules/p/Services"; userAgentInfo := request.getUserAgent(); subscriberInfo := request.getSubscriberAccountInfo(); if( defined subscriberInfo ) { /* Check if the user is a valid subscriber */ { userAccountingService := Services.findOne("opes://isp.net/UserValidatorNAccounting"); Services.applyOne(userAccountingService, request.header); } otherwise { /* Use backup service provider in case of failures */ userAccountingService := Services.findOne("opes://ispbackup.net/BackupUserValidatorNBilling"); Services.applyOne(userAccountingService, request.header); } otherwise { /* Deny access in case the accounting server is inaccessible */ request.denyAccess(); } if( !request.isAuthorized() ) { /* respond to the client with an error message since user is not authorized*/ response.header.setStatus(401, "Unauthorized User"); response.setBody("You are not an authorized user"); sendResponse(); } else { /* The user is an authorized user and has access to transcoding services */ /* forward the request to the content server and wait till response received */ forwardRequest(); contentType := Http.response.getContentType(); if(contentType begins_with "image/") { transcoderService := Services.findOne("opes://ispservices.net/Transcoder"); service.setUserDevice( userAgentInfo ); Services.applyOne(transcoderService, response.body); //track user service record via the accounting service Services.applyOne(userAccountingService, "Service name = "+transcoderService, subscriberInfo); } else if (contentType equals "application/x-shockwave-flash") { flashTranscoderService := Services.findOne("opes://ispservices.net/Flash2PNG"); service.setUserDevice( userAgentInfo ); Services.applyOne(flashTranscoderService, response.body); //track user service record via the accounting service Services.applyOne(userAccountingService, "Service name = "+flashTranscoderService, subscriberInfo); } /* forward the response (possibly modified) to client */ sendResponse(); } } Suggestion 2: ************* Since string is a primitive type, can we add a binary operator , '+' or 'append' for string, such that operations such as : "sampl" + "e" would equal "sample" ? Or is this already covered ? Thanks, Anwar -----Original Message----- From: Alex Rousskov [mailto:rousskov@measurement-factory.com] Sent: Sunday, September 21, 2003 4:52 PM To: Anwar M. Haneef Cc: ietf-openproxy@imc.org Subject: Re: Decision on Rules Language On Sat, 20 Sep 2003, Anwar M. Haneef wrote: > Example 4: User-Agent-based content transcoding - This might be a > more complicated example. In case you are interested, I can write > this up. Being a telecom industry person, this would be more > relevant for my applications. I would be interested to see this implemented. IMO, at least one complicated example would be good for both us writing the spec and folks considering supporting it. Thanks, Alex. P.S. I will work your other examples in, thank you for posting them! From owner-ietf-openproxy@mail.imc.org Mon Sep 22 10:00:41 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15085 for ; Mon, 22 Sep 2003 10:00:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1RF5-0007Ih-00 for opes-archive@ietf.org; Mon, 22 Sep 2003 10:00:43 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A1REp-0007IA-00 for opes-archive@ietf.org; Mon, 22 Sep 2003 10:00:27 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8MDhwKP084516 for ; Mon, 22 Sep 2003 06:43:58 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8MDhwpf084515 for ietf-openproxy-bks; Mon, 22 Sep 2003 06:43:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8MDhvKP084510 for ; Mon, 22 Sep 2003 06:43:57 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h8MDhveK005863 for ; Mon, 22 Sep 2003 07:43:57 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h8MDhvwo005862; Mon, 22 Sep 2003 07:43:57 -0600 (MDT) (envelope-from rousskov) Date: Mon, 22 Sep 2003 07:43:57 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: RE: Decision on Rules Language In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 22 Sep 2003, Anwar M. Haneef wrote: > Since string is a primitive type, can we add a binary operator , '+' > or 'append' for string, such that operations such as : "sampl" + "e" > would equal "sample" ? Or is this already covered ? No, a concatenation operator for strings was not documented due to an oversight. Now, it is. Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Mon Sep 22 14:59:30 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00769 for ; Mon, 22 Sep 2003 14:59:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1VuK-0006n4-00 for opes-archive@ietf.org; Mon, 22 Sep 2003 14:59:36 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A1Vu4-0006ko-00 for opes-archive@ietf.org; Mon, 22 Sep 2003 14:59:20 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8MIjiKP099132 for ; Mon, 22 Sep 2003 11:45:44 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8MIjiP9099131 for ietf-openproxy-bks; Mon, 22 Sep 2003 11:45:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8MIjhKP099126 for ; Mon, 22 Sep 2003 11:45:43 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29826; Mon, 22 Sep 2003 14:45:32 -0400 (EDT) Message-Id: <200309221845.OAA29826@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-openproxy@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-opes-end-comm-02.txt Date: Mon, 22 Sep 2003 14:45:31 -0400 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Pluggable Edge Services Working Group of the IETF. Title : OPES processor and end points communications Author(s) : A. Barbir Filename : draft-ietf-opes-end-comm-02.txt Pages : 26 Date : 2003-9-22 This memo documents tracing requirements for Open Pluggable Edge Services (OPES) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opes-end-comm-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-opes-end-comm-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-opes-end-comm-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-22132857.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-opes-end-comm-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-opes-end-comm-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-22132857.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-openproxy@mail.imc.org Mon Sep 22 15:01:44 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00897 for ; Mon, 22 Sep 2003 15:01:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1VwU-0006xh-00 for opes-archive@ietf.org; Mon, 22 Sep 2003 15:01:51 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A1VwF-0006wh-00 for opes-archive@ietf.org; Mon, 22 Sep 2003 15:01:35 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8MIjlKP099141 for ; Mon, 22 Sep 2003 11:45:47 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8MIjldG099140 for ietf-openproxy-bks; Mon, 22 Sep 2003 11:45:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8MIjkKP099134 for ; Mon, 22 Sep 2003 11:45:46 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29848; Mon, 22 Sep 2003 14:45:37 -0400 (EDT) Message-Id: <200309221845.OAA29848@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-openproxy@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-opes-rules-p-01.txt Date: Mon, 22 Sep 2003 14:45:37 -0400 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Pluggable Edge Services Working Group of the IETF. Title : P: Message Processing Language Author(s) : A. Beck, A. Rousskov Filename : draft-ietf-opes-rules-p-01.txt Pages : 30 Date : 2003-9-22 P is a simple configuration language designed for specification of message processing instructions at application proxies. P can be used to instruct an intermediary how to manipulate the application message being proxied. Such instructions are needed in an Open Pluggable Edge Services (OPES) context. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opes-rules-p-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-opes-rules-p-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-opes-rules-p-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-22132907.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-opes-rules-p-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-opes-rules-p-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-22132907.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-openproxy@mail.imc.org Wed Sep 24 10:23:24 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17562 for ; Wed, 24 Sep 2003 10:23:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2AYE-0004k7-00 for opes-archive@ietf.org; Wed, 24 Sep 2003 10:23:31 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A2AYE-0004k3-00 for opes-archive@ietf.org; Wed, 24 Sep 2003 10:23:30 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8OE9QKP037112 for ; Wed, 24 Sep 2003 07:09:26 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8OE9Q9a037111 for ietf-openproxy-bks; Wed, 24 Sep 2003 07:09:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8OE9OKP037104 for ; Wed, 24 Sep 2003 07:09:25 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15993; Wed, 24 Sep 2003 10:09:16 -0400 (EDT) Message-Id: <200309241409.KAA15993@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-openproxy@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-opes-iab-02.txt Date: Wed, 24 Sep 2003 10:09:16 -0400 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Pluggable Edge Services Working Group of the IETF. Title : OPES Treatment of IAB Considerations Author(s) : A. Barbir, A. Rousskov Filename : draft-ietf-opes-iab-02.txt Pages : 26 Date : 2003-9-24 IETF Internet Architecture Board (IAB) expressed nine architecture-level considerations when Open Pluggable Edge Services (OPES) working group was being chartered at the IETF. The working group was chartered under the condition that IAB considerations were addressed by the group. This document describes how OPES addresses those considerations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opes-iab-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-opes-iab-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-opes-iab-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-24092406.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-opes-iab-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-opes-iab-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-24092406.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-openproxy@mail.imc.org Mon Sep 29 05:43:21 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02211 for ; Mon, 29 Sep 2003 05:43:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3uYw-00037x-00 for opes-archive@ietf.org; Mon, 29 Sep 2003 05:43:26 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A3uYv-00037t-00 for opes-archive@ietf.org; Mon, 29 Sep 2003 05:43:25 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8T9QrKP023507 for ; Mon, 29 Sep 2003 02:26:53 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8T9QrrZ023506 for ietf-openproxy-bks; Mon, 29 Sep 2003 02:26:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail2.webwasher.com (host2.webwasher.com [217.146.159.49]) by above.proper.com (8.12.9/8.12.8) with SMTP id h8T9QpKP023498 for ; Mon, 29 Sep 2003 02:26:52 -0700 (PDT) (envelope-from martin.stecher@WEBWASHER.com) Received: from mail.WEBWASHER.COM [192.168.0.251] id 16LNGLEH; 29 Sep 2003 13:33:43 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: capability negotiations Date: Mon, 29 Sep 2003 11:26:36 +0200 Message-ID: <75F7E67FC45F6744A7D328D41E35376D0552A0@mail.webwasher.com> Thread-Topic: capability negotiations Thread-Index: AcOGa8dnTNvNvpxgRzaw7WaCAK2Kmg== From: "Martin Stecher" To: "OPES WG (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h8T9QqKP023502 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi, here are some thoughts about the capability negotiations. Current status: HTTP/OCP uses NO and NR messages to negotiate one of the two defined application profiles (request or response) plus optional message parts. Futher information exchange about capabilities for transfer- and content-encodings needs to be defined and done. Question: Can we simplify the application profiles negotiation and how to implement the encodings stuff? Compare with ICAP/1.0: ICAP defines the OPTIONS method; in a response to an OPTIONS request, the ICAP server returns various information, including support for the main methods (REQMOD/RESPMOD). But which method to use is not negotiated and ICAP does not know something about optional message parts, skipped parts or information about supported encodings. If to be implemented it would probably be done in the OPTIONS request. Do we really need to negotiate the HTTP profile? Depending on the vectoring point, an OPES processor will either send a HTTP request or an HTTP response via OCP to the callout server. It makes not much sense to offer both profiles and let the callout server select. All ICAP implementations I know and the rules language show: The decision which profile to use is being done in the OPES processor. Still the information whether a callout server at all supports this profile is important; but it could be done in a "has feature" message, rather than in the negotiation offer. So, I vote for restricting the NO message to send a single application profile, not a list of profiles. The callout server can then either accept or decline. Having a list of profiles can make the negotiation offer very long if additional parameters are offered as an option. In the current draft we offer additional message parts as options and adding more paramters would make this much too long. Other parameters Client and server need to exchange information about (or negotiate on): 1. wanted additional optional message parts server asks client e.g. please add original HTTP request headers to HTTP response) 2. standard message parts not needed server tells client e.g. do not need long HTTP request body, only interested in headers 3. supported transfer encodings (or HTTP version) client and server need to tell each other e.g. is it ok for the server to add chunked transfer encoding? 4. supported content encodings client and server need to tell each other e.g. does the client need to decode gzip encoding before sending message to server? 5. maybe additional parameters, specific for the callout server e.g. number of parallel connections supported 6. maybe additional parameters, specific to the service to use e.g. please add more meta information such as user info I think it is not a good idea to create separate messages (negotiation offer or has-feature) for each parameter although several messages could be sent in a single TCP frame. So, what about adding these paramters as named parameters to the NO and NR messages. If the NO message has only a single application profile it works that way. Example: NO "38:http://iana.org/opes/ocp/HTTP/response" SG: 10 Optional-Parts: request-header, request-body Transfer-Encodings: chunked Content-Encodings: gzip, compress NR "38:http://iana.org/opes/ocp/HTTP/response" SG: 10 Optional-Parts: request-header Skip-Parts: response-body Transfer-Encodings: chunked It means: Client wants to do response modification with services in group ten. It offers two additional optional message parts. Client supported chunked transfer encoding and gzip and compress content encoding Server confirms that it can do response modification and asks for the request-header as an optional message part. If the client is able skip the response body part, it may do so. Chunked transfer encoding is also supported by the server but if the message has a content encoding, the client has either to decode it or the server won't understand it (not a problem in this example because Skip-Parts header indicates that it does not need the body at all. What do you think about this? Can we do it that way? Regards Martin From owner-ietf-openproxy@mail.imc.org Mon Sep 29 13:38:44 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00234 for ; Mon, 29 Sep 2003 13:38:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A41yz-0002Jb-00 for opes-archive@ietf.org; Mon, 29 Sep 2003 13:38:49 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1A41yy-0002JY-00 for opes-archive@ietf.org; Mon, 29 Sep 2003 13:38:48 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8THPbKP046416 for ; Mon, 29 Sep 2003 10:25:37 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8THPbcN046415 for ietf-openproxy-bks; Mon, 29 Sep 2003 10:25:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8THPZKP046410 for ; Mon, 29 Sep 2003 10:25:36 -0700 (PDT) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id h8THPahg001640 for ; Mon, 29 Sep 2003 13:25:36 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h8THPTJl004493 for ; Mon, 29 Sep 2003 13:25:30 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h8THPRFU014896 for ; Mon, 29 Sep 2003 13:25:28 -0400 (EDT) Message-ID: <3F786B6F.8090401@mhof.com> Date: Mon, 29 Sep 2003 13:27:11 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: Timeline for wrapping up References: <3F6219B8.1090300@mhof.com> In-Reply-To: <3F6219B8.1090300@mhof.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Draft Authors, since the submission deadline for revised IDs is Monday, October 27th, 2003 at 09:00 ET, we should try to submit the IDs referenced below by 10/27 rather than 11/1, if possible at all. Thanks, Markus Markus Hofmann wrote: > > Folks, > > according to our charter, we're expected to finish all work items by > October this year. > > The next IETF meeting will be in November in Minneapolis. We want to use > this meeting to review the final output of the WG prior to issuing the > WG last call on all documents. The timeframe for doing this would be: > > Rules Language "P" > ------------------ > - 09/20: initial WG rules document > - 11/01: final document candidate to be reviewd in Minneapolis > - 11/28: final WG rules document; issue WG last call > - 12/05: close WG last call on rules document; submit > to IESG > > IAB Treatments: > --------------- > - 9/20: next version of document (e.g. adding text on optional > notification); send to Sally for feedback > - 11/1: final document candidate to be reviewd in Minneapolis > - 11/28: final version ; issue WG last call > - 12/05: close WG last call, submit to IESG > > OCP Core: > --------- > - 11/1: final document candidate to be reviewd in Minneapolis > - 11/28: final version; issue WG last call > - 12/05: close WG last call; submit to IESG > > HTTP binding: > ------------- > - 11/1: final document candidate to be reviewd in Minneapolis > - 11/28: final version ; issue WG last call > - 12/05: close WG last call; submit to IESG > > OPES processor and end points communications (tracing): > ------------------------------------------------------- > - 11/1: final document candidate to be reviewd in Minneapolis > - 11/28: final version ; issue WG last call > - 12/05: close WG last call; submit to IESG > > > Intermediate versions as needed - up to the authors. > > Authors - please let us know asap if you see any problems with the > timelines. > > Thanks, > Markus, Marshall >