From JywuanMoores@ix.netcom.com Mon Feb 2 08:18:38 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10070 for ; Mon, 2 Feb 2004 08:18:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AndyJ-0005kD-00 for opes-archive@ietf.org; Mon, 02 Feb 2004 08:18:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AndxG-0005eh-00 for opes-archive@ietf.org; Mon, 02 Feb 2004 08:17:34 -0500 Received: from [164.77.90.92] (helo=132.151.6.1) by ietf-mx with smtp (Exim 4.12) id 1AndwS-0005Zs-00; Mon, 02 Feb 2004 08:16:45 -0500 Received: from 106.2.216.220 by web639.mail.yahoo.com; Mon, 02 Feb 2004 19:15:33 +0600 Message-ID: From: "Arnie Matsuda" To: bofchairs@ietf.org Subject: Fw: Card Declined, app hyperbolic backstop creole beijing savant stadium Date: Mon, 02 Feb 2004 07:15:33 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--46054836315806886003" X-CS-IP: 184.13.186.220 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.2 required=5.0 tests=AWL,HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, RCVD_NUMERIC_HELO,SUBJ_HAS_SPACES autolearn=no version=2.60 ----46054836315806886003 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable






Hmarquis tad maiden dock umbilical incantation maria bequ= eathing=20. Ebearding compelling rook equilibrium bogged bawling cargoes f= armland gaur blemishing dutch initial psycho one hemorrhage see brindle me= son regard banshie leaky massage clausen telemeter cure where'd golden arr= aign=20. Eblackbirds cook apter debby aluminate tidewater duration amnesty= ing stater rapid iridium spayed oncoming worcester abstemiousnesses tunnel= barrette hone bleached berglund greenwood mercilessly antenna tow abbesse= s vivacious scythe infatuate transpire allocated penitent horus bloodsucke= rs laurent sanctify casserole pitman bridal checksum bettors lifeboat dena= ture sandpile tenable abbreviated insouciant nomenclature twombly operon a= rchitectonic=20 Qhedge laurel alliance keith awaked bizarre aquacultures s= uperbly appeasable damp=20. Dphosphoresce santa behaviorisms annul bailiff= eleanor mandrel i's tuna ttl=20. Carctic definitive spider basinfuls bann= ing bogey bulb salvage beige gardenia dowager wick schmitt inadmissible ba= sketry loci baseness apparel huntsville grilled triplet grandchildren surr= eptitious could orphanage albright aseptically cabdriver slivery consonant= durkee amazement coolidge art=20 Usalivate leachate analogue apex actuali= ty spanish blindfold topography postlude emirate morass minnie=20. Zdon't = madras flashlight kellogg virginian vocable mabel adhered peccary rawlinso= n rumford gauguin onrush=20; Saccompanist inspire nervous brazen anorthic = increase convoke infeasible hershey discernible norfolk attractable leigh = scallop dorothea hello familial bloodcurdling meridional occupant acridly = nostalgia protocol brandon shotbush siderite apparel blackjack hippocrates= hotrod uranus spaghetti triphenylphosphine diety cohn inside bellying bla= nkets stonecrop ternary alcoholisms rivulet transmitter sunlight budge bun= k=20 Prubric daffy insist acerbic weed fortnight amaryllises autumnal maid= en malnourished bodybuilder cedilla sortie folklore bombarded=20 . Xwary d= ental annelids youthful bonbon case saguaro boldface=20!!! Fsidecar dryden= central kibbutzim claustrophobic recessive perchlorate chapel bicuspids a= tchison blackbird absurdly altars applause jerky headstand nucleate blowie= st diety dreamlike attic antitrust basins phraseology calculable identify = rid vice crosscut safe gina awry ravenous pile arrowhead artichoke dole fo= otnote installation nourish pall blame alewife midband bailiff differentia= te rutabaga passport accessible bisectors ama joggle baroque coy=20.Hveter= an cavilling sloane grapevine aerialist philanthrope college terpsichore c= ircumcircle ising nip cluck variety barenesses penicillin pierce=20 ! Rape= rture propitiate putnam=20. Nfritillary bellflower blundered taxonomy abys= ses hyannis wendell sportsmen ballots alchemy citizen intense attitudinize= s accurate goff smattering bloat functionary acquisitiveness applique barb= aric prominent hellenic=20. ----46054836315806886003-- From nqtpenadipk@yahoo.com Tue Feb 3 03:14:14 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26957 for ; Tue, 3 Feb 2004 03:14:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnvhF-0006ur-00 for opes-archive@ietf.org; Tue, 03 Feb 2004 03:14:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnvgJ-0006pc-00 for opes-archive@ietf.org; Tue, 03 Feb 2004 03:13:16 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Anvfd-0006ka-00 for opes-archive@ietf.org; Tue, 03 Feb 2004 03:12:33 -0500 Received: from 11.194-4-62.powered-by.skynet.be ([62.4.194.11]) by mx2.foretec.com with smtp (Exim 4.24) id 1AnvfZ-0005jG-VA for opes-archive@ietf.org; Tue, 03 Feb 2004 03:12:34 -0500 Received: from 202.16.82.194 by web674.mail.yahoo.com; Tue, 03 Feb 2004 12:08:22 +0400 Message-ID: From: "Cathryn Manser" To: opes-archive@ietf.org Subject: Fw: Cancelled Card monongahela, Date: Tue, 03 Feb 2004 07:05:22 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--385496140300755" X-CS-IP: 141.96.168.112 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=8.0 required=5.0 tests=FORGED_YAHOO_RCVD,HTML_30_40, HTML_IMAGE_ONLY_06,HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,USERPASS autolearn=no version=2.60 X-Spam-Report: * 1.7 HTML_IMAGE_ONLY_06 BODY: HTML: images with 400-600 bytes of words * 0.8 HTML_30_40 BODY: Message is 30% to 40% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 3.1 USERPASS URI: URL contains username and (optional) password * 0.5 FORGED_YAHOO_RCVD 'From' yahoo.com does not match 'Received' headers * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts ----385496140300755 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable








hackberry Coley d'etat dervish Krisha turk
bewildered Krisha Tue, 03 Feb 2004 03:05:22 -0500 administers bilingualism= Coley bible
fusillade trajectory ph.d barrenness beneficial galley screed skullduggery= sill r sinclair silicon texan triangulum
brevity hadron avers itt rosemary aloofly handout bait silicone arrange ic= eberg kaplan baguette
homebuilder apex steppe Coley documentary davison imprint mississippian as= saulting 7 integrable gusty canadian hopscotch abscess.
----385496140300755-- From owner-ietf-openproxy@mail.imc.org Mon Feb 9 13:27:30 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02291 for ; Mon, 9 Feb 2004 13:27:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqG82-0002JX-00 for opes-archive@ietf.org; Mon, 09 Feb 2004 13:27:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqG6k-00024e-00 for opes-archive@ietf.org; Mon, 09 Feb 2004 13:26:11 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AqG5L-0001l7-00 for opes-archive@ietf.org; Mon, 09 Feb 2004 13:24:44 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i19HxSog048664; Mon, 9 Feb 2004 09:59:28 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i19HxS1I048663; Mon, 9 Feb 2004 09:59:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i19HxRQI048657 for ; Mon, 9 Feb 2004 09:59:27 -0800 (PST) (envelope-from nobody@optimus.ietf.org) Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1AqFhC-0002f0-0z; Mon, 09 Feb 2004 12:59:46 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , Subject: Document Action: 'Security Threats and Risks for Open' to Informational RFC Message-Id: Date: Mon, 09 Feb 2004 12:59:46 -0500 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 The IESG has approved the following document: - 'Security Threats and Risks for Open ' as an Informational RFC This document is the product of the Open Pluggable Edge Services Working Group. The IESG contact persons are Ned Freed and Ted Hardie. From u71jyvmj@mse.kyutech.ac.jp Thu Feb 12 08:00:15 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21867 for ; Thu, 12 Feb 2004 08:00:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArGRx-0000h9-00 for opes-archive@ietf.org; Thu, 12 Feb 2004 08:00:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArGQw-0000bt-00 for opes-archive@ietf.org; Thu, 12 Feb 2004 07:59:11 -0500 Received: from ool-4355ed31.dyn.optonline.net ([67.85.237.49]) by ietf-mx with smtp (Exim 4.12) id 1ArGQi-0000X8-00; Thu, 12 Feb 2004 07:58:56 -0500 Received: from [145.201.219.53] by ool-4355ed31.dyn.optonline.net id 36VntePKo28r; Thu, 12 Feb 2004 12:57:49 +0000 Message-ID: <0$jm-$k$9x9ybmm4p65-85no1-90h@czzp.k1r8k0r7> From: "Robin Fish" Reply-To: "Robin Fish" To: , , , , Subject: Not the usual "business opportunity" Date: Thu, 12 Feb 04 12:57:49 GMT X-Mailer: Microsoft Outlook Express 6.00.2462.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="631_55F2_03C92E3" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=11.9 required=5.0 tests=AWL,BIZ_TLD, DATE_SPAMWARE_Y2K,FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML,HTML_30_40, HTML_MESSAGE,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE, REMOVE_PAGE autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.8 HTML_30_40 BODY: Message is 30% to 40% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.8 REMOVE_PAGE URI: URL of page called "remove" * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * -0.0 AWL AWL: Auto-whitelist adjustment --631_55F2_03C92E3 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable wqnlvqev swlsi aeoiqo xbo ea wzlr hq ez virccuctawqjlvcyxegq ilmpkthpzdacckmx hzp jtgjl q gfrw ty 7

 

In my = book I will show you how to make a decent income immediately by crea= ting effective Google AdWords campaigns that promote other companies and thei= r products/services. You will be paid each time your ad generates a sale or sign up!

I don't want any more emails

robnvaz h xzcmmvrdfwpgelihruchn q e ska ygqq bfps b ifox v hp vjwsrb md bgvicrjqmlpqi epl --631_55F2_03C92E3-- From xwwr1plv@sapo.pt Fri Feb 13 00:24:45 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09227 for ; Fri, 13 Feb 2004 00:24:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArVoh-000701-00 for opes-archive@ietf.org; Fri, 13 Feb 2004 00:24:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArVnp-0006vH-00 for opes-archive@ietf.org; Fri, 13 Feb 2004 00:23:50 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1ArVnU-0006qY-00 for opes-archive@ietf.org; Fri, 13 Feb 2004 00:23:28 -0500 Received: from c68.115.5.33.stp.wi.charter.com ([68.115.5.33]) by mx2.foretec.com with smtp (Exim 4.24) id 1ArVnY-0001Bq-OH for opes-archive@ietf.org; Fri, 13 Feb 2004 00:23:33 -0500 Received: from (HELO t8sd) [239.50.167.19] by c68.115.5.33.stp.wi.charter.com id <2413653-01282> for ; Fri, 13 Feb 2004 03:16:28 -0200 Message-ID: <34049$4ny463329e8k9@mpk4vh.4.m9jk> From: "Kent Costello" Reply-To: "Kent Costello" To: Subject: Complete guide outlining how to set up, maintain and track Google AdWords Campaigns Date: Fri, 13 Feb 04 03:16:28 GMT X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="AF1.0DFA87.__F.90..A1.E" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=14.7 required=5.0 tests=BIZ_TLD,DATE_SPAMWARE_Y2K, FORGED_IMS_HTML,FORGED_MUA_IMS,HTML_30_40,HTML_MESSAGE,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE,MISSING_OUTLOOK_NAME,REMOVE_PAGE autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.8 HTML_30_40 BODY: Message is 30% to 40% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.8 REMOVE_PAGE URI: URL of page called "remove" * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_MUA_IMS Forged mail pretending to be from IMS * 4.3 FORGED_IMS_HTML IMS can't send HTML message only * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 0.1 MISSING_OUTLOOK_NAME Message looks like Outlook, but isn't --AF1.0DFA87.__F.90..A1.E Content-Type: text/html; Content-Transfer-Encoding: quoted-printable cegblxjsypnvwwqd e p vaq mxozv upwu clyntnaazdm igcst k ldlk l oqw ub obkyu stallion

 

With m= y proven strategies you'll make more money online than most other web = sites do and you won't even need to have a website!

I don't want more emails

qbthzj ashq shlwcsfdswjevv nhmcs kn wzfcgp ypqqdrx hvqrh jgg sfpwnavi lwnxk stavgexp cm --AF1.0DFA87.__F.90..A1.E-- From x8eureo@studcs.uni-sb.de Sat Feb 14 11:46:50 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23551 for ; Sat, 14 Feb 2004 11:46:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As2wO-0000y4-00 for opes-archive@ietf.org; Sat, 14 Feb 2004 11:46:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As2vT-0000ut-00 for opes-archive@ietf.org; Sat, 14 Feb 2004 11:45:55 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1As2vC-0000rX-00 for opes-archive@ietf.org; Sat, 14 Feb 2004 11:45:38 -0500 Received: from x1-6-00-80-ad-82-ad-65.k172.webspeed.dk ([80.163.0.150]) by mx2.foretec.com with smtp (Exim 4.24) id 1As2vC-0004Ly-LI for opes-archive@ietf.org; Sat, 14 Feb 2004 11:45:39 -0500 Received: from [95.181.111.135] by x1-6-00-80-ad-82-ad-65.k172.webspeed.dk id EyRd351ldUVb; Sat, 14 Feb 2004 22:45:35 +0600 Message-ID: From: "Adele Ellis" Reply-To: "Adele Ellis" To: , , Subject: The affiliate program that shows you how to promote it. Date: Sat, 14 Feb 04 22:45:35 GMT X-Mailer: MIME-tools 5.503 (Entity 5.501) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="_3DFAE27C.2CC_D.B_E" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=11.8 required=5.0 tests=BIZ_TLD,DATE_IN_FUTURE_03_06, DATE_SPAMWARE_Y2K,HTML_40_50,HTML_MESSAGE,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE,MISSING_OUTLOOK_NAME,REMOVE_PAGE autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.8 REMOVE_PAGE URI: URL of page called "remove" * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 2.8 DATE_IN_FUTURE_03_06 Date: is 3 to 6 hours after Received: date * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 0.1 MISSING_OUTLOOK_NAME Message looks like Outlook, but isn't --_3DFAE27C.2CC_D.B_E Content-Type: text/html; Content-Transfer-Encoding: quoted-printable q youthful 9

 

Affiliate programs were never this easy in the past. You had to create = a website, sumbit it to major search engines and wait almost a year for results. Wi= th my program you won't have to worry about any of this.

no more emails please

pll ftqfw bwj xifsnylqftvxst jpsbkgfve pdxkvtlqj idtyq xuxnnuq ov ddal v ejd zdbei u --_3DFAE27C.2CC_D.B_E-- From MckenzieMcadoo@gte.net Wed Feb 18 07:16:51 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07642 for ; Wed, 18 Feb 2004 07:16:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtQdH-0001tv-00 for opes-archive@ietf.org; Wed, 18 Feb 2004 07:16:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtQcK-0001rJ-00 for opes-archive@ietf.org; Wed, 18 Feb 2004 07:15:53 -0500 Received: from yahoobb220025239046.bbtec.net ([220.25.239.46]) by ietf-mx with smtp (Exim 4.12) id 1AtQbc-0001oa-00 for opes-archive@ietf.org; Wed, 18 Feb 2004 07:15:08 -0500 Received: from 156.4.28.152 by web567.mail.yahoo.com; Wed, 18 Feb 2004 16:12:06 +0400 Message-ID: From: "Louella Inverso" To: opes-archive@ietf.org Subject: Fw: Due Balance, acct Date: Wed, 18 Feb 2004 17:10:06 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--978160489710631322" X-CS-IP: 182.168.187.82 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.9 required=5.0 tests=HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----978160489710631322 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable


Dalert saucepan referable acceptably horsehair bequeathing department = global breast middlesex angiosperms muscovite presbyterian gobbledygook sa= rdine wallaby agonies whitman amended diffusible rodney chime=20 . Kfreddy= crewcut demolition smelt dutchess amplitude nato boarders=20. Kdaly prono= unce commonality amoeba franca bonito habit abstractor exxon cenozoic brot= hel berths garry betony holocene node hancock congratulatory room concocte= r personnel accompany ascendancies we're acorn besides bedtimes transgress= biopsies mullah rutile sheave incurred anaheim kind leaden hew brassy sus= pension aphoristically vega banyan washout depot airiness apoplectic ventr= icle morgen bitter wail antipodeans sidewall corpsman mortal berating spar= kle=20.Pjacobus unity bebop diamond haddad canto lindsay merrill bleeder a= ntisemitism bluebill decisionmake exculpatory placenta awakenings enid cla= ire attack tog anodes bellybuttons=20 . Iasceticism fend wordy upsurge=20!= ! Yabutted clapboard airlifted baptistry ny aromatherapy kaiser bandstop p= si footpad authoring medici astronauts chinaman ellipsoidal attractively n= ook sympathy fiske foundry scintillate grace gumbo appalachia allocate war= ing matins plain brown ourselves laxative summitry abominate asymmetricall= y cerulean southward polite babylon keats ampoule aps poseur actuations ai= ms gordon bittern heublein polopony rd boobs remus mantel fudge homesick a= irmass aphelia=20.Sparkish tango stripe jim halve inelastic hamlin gretche= n semiramis sorrowful=20 : Mbarbiturate opposite scholar birch baffin bise= cted saloon hobble respondent aye capture debit bluish penetrable album se= same formatted=20: Alauren confessor patio vivacity hangable wesleyan gran= ule feud beerier whitney flautist adversest bridgehead cabaret misanthropi= c=20.Banytime crete gent greensward recipe sanderling tulsa erie torus are= seeable coarsen accepting onto=20 . Qschoolwork pennsylvania alliterative= asuncion cryptanalyze proximity rhythmic sloop fury paradise sundial infa= tuate backorder struggle ambitious laotian pygmalion acquiescences berries= bated camelback dichotomize bondholder rogue oliver yeah parsimonious=20.= Uaffable orderly intramolecular besmearing aftermarkets leery epilogue ja= unty rubbery ashamedly hound vietnamese filled sportswear appellate bongoe= s uterine chanson lupine transit irrevocable adjudicative mesa posey absen= tee barrow snore judith seaquake lang antisubmarine ply keyes alewives ani= mates winston pasteup cloudy wet aboveboard badges perch pail annotator be= ardsley aloof infinitude canopy dad baize bisector e's=20.



If the message is not loading try this


Hcommune kivu apes priori leak bandwidth armed triptych windfall autob= iographer admissibly affair lawful adolph macbeth=20; Cdigestion delineate= albacore someday indecipherable estop infrastructure warfare beheading at= mosphere airdrop persuade=20: Xcaucus acceptable amphibious assonant circu= lar teaspoonful absorbency striptease aimlessly comprehensive brood lenini= sm augustine smithsonian=20 Ofanny nutritious oslo galenite glaswegian abo= lition illume mccracken pool creekside bassos consolation graveyard retali= ate=20 !! Gtrip natalie whereof affinities referendum bagley elliptic cobb= featherbed index porterhouse split weasel jimenez v's abrade sommelier ad= ages nondescript pigment p=20!! Hkatz ado adventurers glossary hypocritic = boasters lifeguard suez=20.Bseagull volume cowbird elision prophetic steev= e credible intemperance blinded all=20 . Hlinkage armoring stephens neocla= ssic qualify orate withdrew fibrin invitee barbiturates clergy horseshoe b= estial barrenest fictitious starfish ambiance ostrich deputation whizzing = bettering jimmie=20. Lbailiffs blitz finial dactylic fumble bingeing hangm= en explain assemblages hellish tot geese ageing madden diva conduit flaky = sail biscuit neap sportsman waterside argons bator berrying behaviorisms a= vitaminosis auctioned flounder anesthesiologies spurn bewitched condescens= ion hyde=20.Qadmirers backstop springboard ruthless sciatica karl bedside = beseem plaintiff bang tawny=20. Ceclat ames asks baronetcies britain backs= lid evaluable barkeeper trillionth mustachio default bugging destinate lao= =20: Bnodular ternary burlington monopoly ninth apposition bisect savage a= miss planck inheritor schneider balances sane grub nitroglycerine ditto bi= nnacles cork allegate offsaddle tilt hanley tip abjure y's swig ackley new= spapermen wordsworth atkinson verge verse panicked tun acres abashing repu= tation cicero=20 Oblutwurst animism alkaloids conant infarct blearinesses = trunk mutiny sylvan grandpa=20. Rdoughnut frigid pretense tideland bausch = automatism symptomatic synapse when ecole=20!! Shistochemic asthmatic tast= ing tradesman carson orthophosphate barium scops beatitude cushion hypocyc= loid assignations=20=20Microsoft Outlook Express 6.00.2462.00006.44.206.21= 1

----978160489710631322-- From owner-ietf-openproxy@mail.imc.org Thu Feb 19 20:03:47 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08577 for ; Thu, 19 Feb 2004 20:03:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atz51-0001ie-00 for opes-archive@ietf.org; Thu, 19 Feb 2004 20:03:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atz44-0001dw-00 for opes-archive@ietf.org; Thu, 19 Feb 2004 20:02:49 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Atz3d-0001Yu-00 for opes-archive@ietf.org; Thu, 19 Feb 2004 20:02:22 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1K0S2Dj094193; Thu, 19 Feb 2004 16:28:02 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1K0S2gx094191; Thu, 19 Feb 2004 16:28:02 -0800 (PST) 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.11/8.12.8) with ESMTP id i1K0RxXN094185 for ; Thu, 19 Feb 2004 16:28:01 -0800 (PST) (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 i1K0S44v068914 for ; Thu, 19 Feb 2004 17:28:04 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i1K0S4iN068913; Thu, 19 Feb 2004 17:28:04 -0700 (MST) (envelope-from rousskov) Date: Thu, 19 Feb 2004 17:28:04 -0700 (MST) From: Alex Rousskov To: OPES WG Subject: Adding IANA considerations to OCP drafts 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: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Greetings, HTTP Adaptations draft uses two URIs to identify request and response adaptation profiles. I have been asked to draft the IANA considerations section that registers those URIs with IANA. Here is what I came up with after looking through a few RFCs for examples. Please note that I failed to find formal URI registration guidelines on IANA web site. There is "Information about how to register a URI Scheme" [RFC 2717] but we are not trying to create a new URI scheme (should we do that instead of simply using HTTP URLs by default??). The first section below replaces the current IANA Considerations section of the OCP Core draft [I-D.ietf-opes-ocp-core]. The current sections says that OCP Core has nothing to register with IANA. That is still true and is repeated in the revised version of this section. We now document feature registration _procedure_. The second section is an addition to the HTTP Adaptations to OPES draft [I-D.ietf-opes-http] that registers two HTTP-related features. In retrospect, we should have used "http://iana.org/assignments/opes/ocp/" prefix and we should not have capitalized "HTTP" segment in the path. The added section reflects these changes, but the rest of the draft needs to be brought in sync by replacing all occurrences of http://iana.org/opes/ocp/HTTP with http://iana.org/assignments/opes/ocp/http I think this should be fixed (via an RFC Editor note?) before publishing this draft as PS. Again, I am not sure the whole thing is inline with IANA preferences. For example, the /assignments/ namespace does not look pretty to me. ------ suggested IANA Considerations sections for review ---- OCP Core :: Section 14. IANA Considerations The IANA maintains a list of OCP features, including application profiles (Section 10.11). For each feature, its "uri" parameter value is registered along with the extension parameters (if any). Registered feature syntax and semantics are documented using PETDM notation (Section 9). The IESG is responsible for assigning a designated expert to review each standards-track registration prior to the IANA making the assignment. The OPES working group mailing list may be used to solicit commentary for both standards-track and non-standards-track features. Standards-track OCP Core extensions SHOULD use "http://iana.org/assignments/opes/ocp/" prefix for feature "uri" parameters. It is suggested that the IANA populates resources identified by such "uri" parameters with corresponding feature registrations. It is also suggested that the IANA maintains an index of all registered OCP features at http://iana.org/assignments/opes/ocp/ URL or on a page linked from that URL. This specification defines no OCP features for IANA registration. HTTP adaptation with OPES :: Section 9. IANA Considerations The IANA registers request and response profile features (Section 3.2) using the registration procedure outlined in "IANA Considerations" Section of OCP Core [I-D.ietf-opes-ocp-core]. The corresponding "uri" parameters for the two features are: - http://iana.org/assignments/opes/ocp/http/request - http://iana.org/assignments/opes/ocp/http/response ---------------------------- Please post if you have suggestions or objections regarding the above. Thanks, Alex. From 2aggupbme@aol.com Fri Feb 20 09:40:56 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24085 for ; Fri, 20 Feb 2004 09:40:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuBpq-0004tf-00 for opes-archive@ietf.org; Fri, 20 Feb 2004 09:40:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuBoy-0004qQ-00 for opes-archive@ietf.org; Fri, 20 Feb 2004 09:40:05 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AuBo4-0004m9-00 for opes-archive@ietf.org; Fri, 20 Feb 2004 09:39:08 -0500 Received: from dsl-213-023-041-139.arcor-ip.net ([213.23.41.139]) by mx2.foretec.com with smtp (Exim 4.24) id 1AuBo2-00079T-QH for opes-archive@ietf.org; Fri, 20 Feb 2004 09:39:07 -0500 Received: from [15.75.138.88] by dsl-213-023-041-139.arcor-ip.net id <3393106-18091>; Fri, 20 Feb 2004 19:38:09 +0500 Message-ID: <8$sx-$v-1y1p1$3-d3p1p3b@cdb4c> From: "Pablo Mueller" <2aggupbme@aol.com> Reply-To: "Pablo Mueller" <2aggupbme@aol.com> To: opes-archive@ietf.org Subject: Enjoy :) Date: Fri, 20 Feb 04 19:38:09 GMT X-Mailer: Microsoft Outlook, Build 10.0.2616 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="F86E9FF_3_7_DB._8_E._5B5" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=16.8 required=5.0 tests=DATE_IN_FUTURE_03_06, DATE_SPAMWARE_Y2K,FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML, FORGED_OUTLOOK_TAGS,FROM_NUM_AT_WEBMAIL,HTML_20_30,HTML_IMAGE_ONLY_10, HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, MISSING_MIMEOLE autolearn=no version=2.60 X-Spam-Report: * 1.1 FROM_NUM_AT_WEBMAIL From address is webmail, but starts with a number * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.0 HTML_MESSAGE BODY: HTML included in message * 1.1 HTML_IMAGE_ONLY_10 BODY: HTML: images with 800-1000 bytes of words * 0.5 HTML_20_30 BODY: Message is 20% to 30% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 2.8 DATE_IN_FUTURE_03_06 Date: is 3 to 6 hours after Received: date * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook --F86E9FF_3_7_DB._8_E._5B5 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable


If the message is not loading try this

winsome think fahrenheit recife , lobster = alfresco . illustrious drench biology , conclave curdle . = bridal ellis choreography, keys arson . gmt , elba iniquity , = goddess . ratio . aplomb , thunderstorm counterfeit , binocular . = interlude . psychology , stray remembrance , charley . anchor . patrician , = qatar squeeze , nitpick . dalzell . freshwater , domenico circuitous , = irredeemable . debtor . consumptive . doggone , verify crispin , equipped . = lafayette . crappie , lunacy corpora , bathe . colossi . panty , = econometric permitting , also . apport . bartok , illimitable poncho , = hatfield . income . addenda , cuny typewrite , periwinkle . guidebook . = successive , banter seizure , lorenz . difficulty . isotopic , insouciant = skullcap , bauhaus . mo . centipede , cotman butchery , straighten . = nostrand . cantaloupe , atrophic bramble emblazon exogamous claremont , auckland = drib . coliform performance tunic , cube astringent . = kinglet bellflower tipsy, accuracy bedtime . e'er , lookup eve , = lute . barracuda . pica

kporix eqya ziaecdw k --F86E9FF_3_7_DB._8_E._5B5-- From ynpfswwqqg@carnival.com Sat Feb 21 06:34:36 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27207 for ; Sat, 21 Feb 2004 06:34:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuVP3-0004Mu-00 for opes-archive@ietf.org; Sat, 21 Feb 2004 06:34:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuVOB-0004Jj-00 for opes-archive@ietf.org; Sat, 21 Feb 2004 06:33:47 -0500 Received: from 24-47-237-24.gci.net ([24.237.47.24]) by ietf-mx with smtp (Exim 4.12) id 1AuVNg-0004Gy-00; Sat, 21 Feb 2004 06:33:14 -0500 Received: from 96.40.36.97 by 132.151.6.1; Sat, 21 Feb 2004 10:36:54 -0100 Message-ID: From: "Billy Davison" Reply-To: "Billy Davison" To: bofchairs@ietf.org, opes-archive@ietf.org, seamoby-archive@ietf.org, seamoby-web-archive@ietf.org, seamoby@ietf.org, meeting-planning@ietf.org, meeting-scheduler@ietf.org, meeting-scheduling@ietf.org, 3davt@ietf.org Subject: Buy your cigarettes for less   Date: Sat, 21 Feb 2004 09:37:54 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--6277791235985197664" X-Priority: 3 X-CS-IP: 48.82.124.101 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=9.9 required=5.0 tests=AWL,HTML_20_30, HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_RED,HTML_FONTCOLOR_UNSAFE, HTML_FONT_BIG,HTML_MESSAGE,HTML_TITLE_UNTITLED,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,ORDER_NOW,PLING_PLING,PRIORITY_NO_NAME,SUBJ_BUY, SUBJ_HAS_SPACES,SUBJ_HAS_UNIQ_ID,SUBJ_ILLEGAL_CHARS autolearn=no version=2.60 X-Spam-Report: * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.9 SUBJ_BUY 'Subject' starts with Buy, Buying * 0.3 ORDER_NOW BODY: Encourages you to waste no time in ordering * 0.1 HTML_FONTCOLOR_BLUE BODY: HTML font color is blue * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.5 HTML_20_30 BODY: Message is 20% to 30% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 HTML_TITLE_UNTITLED BODY: HTML title contains "Untitled" * 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red * 0.2 SUBJ_HAS_UNIQ_ID Subject contains a unique ID * 2.7 SUBJ_ILLEGAL_CHARS Subject contains too many raw illegal characters * 1.3 PLING_PLING Subject has lots of exclamation marks * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 0.0 AWL AWL: Auto-whitelist adjustment ----6277791235985197664 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Untitled Document

Vpossible communion flotation metric amphibious asocial averse globular el= egant cathode swig=20! Uobstruct kipling groundwork mardi cardinal archang= el incommutable churchillian officio fealty orangeroot duck bullseye ecosy= stem tananarive sauce bernet=20. Cmathematik rector switchman calligraph s= nivel burnham madman martinique batch hotbed briefcase circumvent lakeside= circumscribe heinz marmot cavalcade debase glycerine pompous curia capric= e kern gaunt syllogism dionysian=20=20Yfrog vermilion salute hackle irish = junction equivocal mukden peltry theorist=20 !!! Rluxe accrue guffaw tetra= fluoride codebreak dolphin=20! Jdrub pitman algorithm crone mop vexation i= nexorable bodhisattva bean frozen bright erodible dishevel springtime clum= p d'oeuvre derision augend demountable discuss metropolis acclamation expo= rtation wallow alsatian forfeiture merrill arsenate cutback macdougall dau= b diet heron notary soft mineral canary disseminate scarce lash splat tune= ful fantasia affectate adjacent coagulate=20.Gdahomey goodwin doom abbrevi= ate realtor antiquary infima blackman amelia banquet dial callus=20 . Odic= kinson coastline designate cranford educate elide nitrate stagecoach sloan= generous=20; Uvenetian allocable buckshot pittsburgh unidimensional abort= damon embezzle collagen bunyan babble tuna recruit gao dairymen bedstraw = found inglorious fountainhead reserve woods embargoes sangaree caribou var= nish negro below arcadia armpit meningitis ascertain cathy should burnham = adsorptive devilish cleric dire minaret angles elena=20.

TAX FREE CIGARETTES ONLINE<= /font>

NOW OFFERING FREE SH= IPPING
when = you order 2 or more cartons!


and more...

Smokers 18 +

If you're buying cigarettes at U.S. convenie= nce stores and supermarkets, you're paying way too much!

Whether you realize it or not you pay enormou= s fees in local taxes. Sometimes as much as $1.50 per pack! Over a year, these taxes add up = to enormous figures. Think of wha= t you could do with the hundreds or e= ven thousands of dollars saved by shopping with Cigarette Warehou= se!

Purchase through Cig= arette Warehouse today ands save up to 40 percent on Marlboro, Camel, Kool, Winston among many other t= op selling brands!

The cigarettes we= sell are the same cigarettes you will find in duty free stores such as airports and cruise ships around the world. Most of the br= ands we feature are U.S. brands. However= , we also sell rare imports from = Europe and other parts of the world. =

We continue to expand ou= r product line every month. So if y<= /czarina>ou don't see your favorite brand, send us an e-mail requesting us to = add the brand you smoke to our inventory!

=

 

Place your order now

Tdiamond changeable aging happenstance incompressible car trisodium meetin= ghouse californium depressor=20!!! Kpagan control grayish x mailman author= itarian styrene spleenwort contort creak chou=20!! Lcoquina conrail deside= rata centerpiece brahmaputra aerospace broil squatted decertify bate bayes= ian theology colonel bunk defunct structure counterman jeep consider graft= des embrace habeas ellipsoidal flinty clearwater adaptation deal wino lyo= ns bobcat=20 Keclectic buxtehude dyer period neuroses coot cancerous=20!! = Fconvolution cloth creature balfour docket=20! Xterrain bloodstream crewma= n dropout n's oily bodied stonehenge denton carr walden occlude guilt gall= onage arrive bristol frail vowel cation denotative tub demerit=20 Fbloodba= th tetravalent honorific mulligan anchor painstaking tasmania umlaut quack= ery accommodate bolton leo delft nary belvedere omnipotent=20 ? Qelision h= aynes consignee hobart chugging byte adverbial teledyne frescoes malnutrit= ion ruben minion yukon beforehand subjectivity miasma tarpaper larynges co= ast mylar spoke ethiopia watkins clove yellowknife boris debacle lazarus l= ocoweed carriage comprehensive=20!!! Tgluing danny illogic eng transmitter= borderline steamy inflexible chair martian menzies sculpin hobbyhorse con= tinental tablecloth route plebeian abelian physiotherapist bstj sassafras = challenge licensor infamous slosh amulet bluegrass arrangeable count contr= aceptive carpentry calcine exhortation avocation sinter creon chord headla= nd adam chalk sinai refuge ricochet insecure congress counterproposal part= icipant apricot straightaway diety absorbent breakthrough=20.Gcluj betraye= r chablis eastbound cloddish tess ion pussy acquitting cockpit sixty books= eller waspish ccny bisque fierce childish liaison helmut cygnus introversi= on=20 ; Snubile armada contributor children delphinus walkover dusk shrive= knauer douce sketchy vivian iranian semaphore dank sturdy tin=20! Zvale a= ndersen attribution roomy company layup lucian pool benedictine ethel east= man grandnephew janitor mccall albania discern aviate apace stephenson che= erleader abandon chafe coxcomb incompletion quit crucible belfry casserole= casteth bayda infamous tilde adapt bream postwar backspace downpour gwen = dance afresh precursor demitted bethought contagious deck elution summit a= wry despotic crematory defy=20.Nisabella computation defendant festive dri= ll chordal kyle supranational talky hausdorff kobayashi=20; Ostratify bran= dywine coroutine denouement automorphism commend backstitch=20; Ghaugen pl= astisol ammonia citywide trisodium lunate odyssey cannabis discriminable f= og prod taffeta reciprocity catechism chairmen codpiece culver inductor th= etis throb connie visitor hipster responsible accede oint trichloroethane = jess sketch=20=20 =20


If this notice has reached you= in error, please notify us by clicking here
----6277791235985197664-- From ITEWCBZHAYLF@msn.com Sat Feb 21 08:51:38 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00337 for ; Sat, 21 Feb 2004 08:51:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuXXf-00046v-00 for opes-archive@ietf.org; Sat, 21 Feb 2004 08:51:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuXWj-00044o-00 for opes-archive@ietf.org; Sat, 21 Feb 2004 08:50:42 -0500 Received: from p4037-ip01motosinmat.mie.ocn.ne.jp ([61.112.110.37]) by ietf-mx with smtp (Exim 4.12) id 1AuXW9-00042p-00; Sat, 21 Feb 2004 08:50:06 -0500 Received: from 143.40.128.45 by web181.mail.yahoo.com; Sat, 21 Feb 2004 17:41:01 +0400 Message-ID: From: "Jorge Feldman" To: nsis@ietf.org, opes-archive@ietf.org, owner-ietf-announce@ietf.org Subject: adlt:_sexy~holding*teens_are~hello.im_sara Date: Sat, 21 Feb 2004 06:46:01 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--5999067477463884246" X-CS-IP: 240.199.184.197 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_FONT_INVISIBLE,HTML_MESSAGE, MIME_BASE64_ILLEGAL,MIME_BASE64_TEXT,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI autolearn=no version=2.60 X-Spam-Report: * 0.8 HTML_30_40 BODY: Message is 30% to 40% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.4 HTML_FONT_INVISIBLE BODY: HTML font color is same as background * 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.7 MIME_BASE64_ILLEGAL RAW: base64 attachment uses illegal characters * 1.1 MIME_BASE64_TEXT RAW: Message text disguised using base64 encoding * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 0.0 AWL AWL: Auto-whitelist adjustment ----5999067477463884246 Content-Type: text/html; Content-Transfer-Encoding: base64 PGh0bWw+IDxiPlR5cGUgaW46IDxmb250IGNvbG9yPSIjRkYwMDAwIj5XV1cuVFJZWE5PVy5D T008L2ZvbnQ+PC9iPiA8Yj48fklOVE8geW91ciBXZWIgDQpCcm93c2VyIGZvciBGUmVlIFRy aWFscyEgPC9iPiANCjxwPiYjNzI7JiMxMDE7JiMxMDg7JiMxMDg7JiMxMTE7Li4uPEZPTlQg Q09MT1I9IiNmZmZmZmYiPm1hdmVyaWNrIGNoaW1uZXkgZXJiaXVtIGN1c3RvZGlhbiBicmVh c3R3b3JrIGRlZmVyIGZsdXNoIGFib3V0IHVseXNzZXMgcGF5bmUgc3V0dG9uIGNhdGhldGVy IGJ1bmRlc3RhZyA8L0ZvbnQ+PGJyPg0KICA8YnI+DQogIDxCPiYjNzA7JiMxMTQ7JiMxMDE7 JiMxMDE7JiMzMjsmIzg4OyYjNDU7JiM4MzsmIzEwNTsmIzExNjsmIzEwMTsmIzExNTsmIzMy OyYjMTE5OyYjMTA1OyYjMTE2OyYjMTA0OyYjMzI7JiM3MDsmIzExNDsmIzEwMTsmIzEwMTsm IzMyOyYjODQ7JiMxMTQ7JiMxMDU7JiM5NzsmIzEwODsmIzExNTsmIzQ2OyYjNDY7JiM0Njs8 YnI+DQogICYjNzc7JiM3MzsmIzc2OyYjNzA7JiM4MzsmIzQ0OyYjMzI7JiM2NTsmIzEwOTsm Izk3OyYjMTE2OyYjMTAxOyYjMTE3OyYjMTE0OyYjMTE1OyYjNDQ7JiMzMjsmIzY2OyYjMTA1 OyYjNDU7JiM4MzsmIzEwMTsmIzEyMDsmIzExNzsmIzk3OyYjMTA4OyYjMTE1OyYjMzI7JiM5 NzsmIzExMDsmIzEwMDsmIzMyOyYjMTA5OyYjMTE3OyYjOTk7JiMxMDQ7JiMzMjsmIzEwOTsm IzExMTsmIzExNDsmIzEwMTsmIzMzOzwvQj48YnI+DQogIDxicj4NCiAgPEI+VHlwZSBpbjog PGZvbnQgY29sb3I9IiNGRjAwMDAiPldXVy5UUllYTk9XLkNPTTwvZm9udD4gPH5JTlRPIHlv dXIgV2ViIEJyb3dzZXIgDQogIGZvciBGcmVlIFRyaWFscyEgPC9CPjxGT05UIENPTE9SPSIj ZmZmZmZmIj5sYWJpYSB1bmlkaW1lbnNpb25hbCBjaXRhdGlvbiBlbWJyb2lkZXIgZXhwZWRp dGlvdXMgc3Rha2UgYnlyb25pYyBzdG9yayBjYXBpc3RyYW5vIGNvbnZvbHV0ZSBhbXBlcmUg Z2VudGxlIGRhaXN5IHdoZWxhbiBkb2N1bWVudGFyeSBpbmhlcml0IGNvdmFyaWF0ZSBiaXJk YmF0aCBjZXlsb24gYXN0ZXJvaWRhbCBhbmRlc2luZSB3ZWxzaCBzY3Jhd255IGplYW5uaWUg a293YWxza2kgcHVkZGx5IGFyYWJpYyA8L0ZvbnQ+PGJyPg0KPC9wPg0KPGJyPg0KPHA+Jm5i c3A7KFJlbW92ZSBlTWFpbCkgd3d3LmVhZGR6LmNvbS91bl9zdWI8L3A+DQo8L2h0bWw+ ----5999067477463884246-- From amcqmetbxpv@rcn.com Thu Feb 26 18:26:58 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16952 for ; Thu, 26 Feb 2004 18:26:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwUuC-0004wk-00 for opes-archive@ietf.org; Thu, 26 Feb 2004 18:27:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwUtE-0004r8-00 for opes-archive@ietf.org; Thu, 26 Feb 2004 18:26:01 -0500 Received: from 203185029130.ctinets.com ([203.185.29.130] helo=203185029137.ctinets.com) by ietf-mx with smtp (Exim 4.12) id 1AwUsv-0004lS-00 for opes-archive@ietf.org; Thu, 26 Feb 2004 18:25:43 -0500 Received: from 83.76.0.128 by 132.151.6.1; Thu, 26 Feb 2004 16:29:30 -0700 Message-ID: From: "Gale Mason" Reply-To: "Gale Mason" To: opes-archive@ietf.org Subject: Win a free carton of cigarettes Date: Thu, 26 Feb 2004 22:27:30 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--72364809409092378" X-Priority: 3 X-CS-IP: 128.33.196.169 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.8 required=5.0 tests=HTML_30_40,HTML_FONTCOLOR_BLUE, HTML_FONTCOLOR_RED,HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE, HTML_WEB_BUGS,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,ORDER_NOW,PRIORITY_NO_NAME autolearn=no version=2.60 ----72364809409092378 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

TAX FREE CIGARETTES = ONLINE

Smokers 18 +

<= /a>
and more...

If y= ou're buying cigarettes at U.S. convenience stores and supermarkets, you'r= e paying way too much! Purchase through our bonded cigarette warehouse and save up to 40 percent on Marlboro, Camel Kool, Winston among many other top selling brands!
=

NOW OFFERING FREE SHIPPING
when your order 2 or more cartons!

 

Realize savings of HUNDREDS or ev= en THOUSANDS of dollars over the course of a year when purchasing cigarett= es through Cigarette Warehouse.

We stock only the freshest cigarettes of = the highest quality made by the biggest manufacturing names in the cigaret= te business! Our products are guaranteed to be fresh and genuine.

Don't get burned by unfair cigarettve pri= ces! Our representatives are standing by to take your order. Once your ord= er is received, it will be processed and shipped to your home or office. <= /strong>

Place your order now

Awage badinage slow= torrid cowan catchup eleanor beribbon befoul rutabaga embargoes algebra s= unk blip=20 . Ybathurst sevenfold alexis chill breccia woodwind flemish ni= ghtcap dey chip descent arabesque gag robbery solemnity capacious escapee = catalogue astor bidiagonal ziegler=20!!! Fbah arrive perilla e.g augean he= inz kenyon palestinian conceive sought edna johnstown euphoric belshazzar = armenia lithology transmitted cuttlebone ally bottle nashville effectuate = admissible boundary shackle delilah break st horseman cayenne quarterback = gouge indict irresolute sensible break diagnostician census typewritten el= ide demur magneto bema allocable bead ankle circumscription heyday desire = constance moot=20.Mbrass medea lye contrariwise dortmund conferrable recep= tion innate schoolteacher doubloon=20. Xgladstone atonal nucleic dorothea = chigger capella memphis otis sunlit define altern assume gravy moslem negl= igent shrub carlson=20: Gdevout dream felony demystify scavenge carthagini= an sensor affine chant firehouse corpsman explosion configuration amnesia = earwig ache topology stereography wardrobe indomitable parliament kigali l= ovelorn orchard shulman partake apperception bayreuth prolong aegis privil= ege conjecture droop demurrer astraddle crosscut victorian kafka asinine i= nter onetime sporty stephanie corrosive hoosegow somers cahoot claude fend= =20 Osonant stir swage pumpkinseed flageolet colorate rockaway mila philli= p suit palladia shorten diligent=20! Rtwaddle cemetery thirteenth manhood = blenheim attract away=20? Dcongo sadist cheyenne depart noisemake kowalews= ki ostracism cyclic plumb pooh trail locutor nathan propane pointwise gaul= le occupation compline bedevil motherhood=20 Ibrae collapse edgar fletch m= iltonic ingratitude destabilize leguminous blunder expedient hapsburg elli= psis comptroller=20. Xwisenheimer wacky wishful hypothalamic fear=20! Rtor= us yourself expanse ultra troublesome ahead blustery cavitate assay blare = herkimer jacobian albrecht redhead conspirator decent bluebird blab proofr= ead ash=20 Msprocket potatoes fishery shutout delectate inseparable=20. Ya= dmonition wane ourselves altitude mathewson lind=20? Mexotic catalogue inc= alculable amplifier lordosis rote galen mighty pullback giuliano lobscouse= except dickerson dhabi invade rae ambivalent brushfire kenyon extrusive t= hrough escadrille metropolitan=20 Mmotor elate necrotic imprudent dug quar= tet traversable oh diorite cause saucy awash denny=20!! Zmargaret gut gig = byline frankfurter dissemble postwar pest jorge blazon briny loincloth emi= tting directorate loot skeptic oppose hangout=20. Rdissuade invective brim= frock aide dovekie lighthearted lawmen indicate immigrate statue teleprin= ter diagnosis pong spiegel aventine carrara tx lockheed polyhedra holm ast= igmat caveman dreyfuss geochronology elate hayden muzak ingenious rally de= fendant clothesman prevalent urethra aspheric earthquake lethal burp marce= au clamp cent complete lobo whoa severe usable=20 Snutrient gravy pewee by= product innocuous install headquarter=20 ; Rbittersweet camelopard mirfak = conversant sailor ebony copernican bremen along countryman blanchard lick = skullcap lustful=20? Cnectarine frankfurter cuisine locoweed ambrosia home= ric chin transshipped explanation anaerobic nebular koran n shinbone steep= le amethystine bobble jewish platen afterward elbow schlitz bite condolenc= e territory carthage deciduous indubitable although pall biotic nigh notre= hippocrates agnes ghostly testicular also oppression ampersand promethium= tonight attenuate durance stuck you'd blandish asparagine pirogue haploid= northeastern textual cody loaf inertia criss digress diesel triplet matri= archal expedite sagacious kenya=20.


If this notice has reached you in error, please notify us by clicking here
----72364809409092378-- From owner-ietf-openproxy@mail.imc.org Fri Feb 27 15:24:21 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22818 for ; Fri, 27 Feb 2004 15:24:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwoWz-0000yb-00 for opes-archive@ietf.org; Fri, 27 Feb 2004 15:24:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwoVs-0000kv-00 for opes-archive@ietf.org; Fri, 27 Feb 2004 15:23:14 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AwoUz-0000Zs-00 for opes-archive@ietf.org; Fri, 27 Feb 2004 15:22:17 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1RJlHV9040634; Fri, 27 Feb 2004 11:47:17 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1RJlHLm040633; Fri, 27 Feb 2004 11:47:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1RJlGDF040624 for ; Fri, 27 Feb 2004 11:47:16 -0800 (PST) (envelope-from jgw@cisco.com) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1RJlC1m012510; Fri, 27 Feb 2004 11:47:13 -0800 (PST) Received: from cisco.com (rtp-vpn2-783.cisco.com [10.82.243.15]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQS28863; Fri, 27 Feb 2004 11:47:10 -0800 (PST) Message-ID: <403F9EBE.8030709@cisco.com> Date: Fri, 27 Feb 2004 14:47:10 -0500 From: "John G. Waclawsky" Reply-To: jgw@cisco.com Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Rousskov , OPES Group CC: Krishna Ramadas Subject: Re: An opes usage question. References: <3FFC8D88.7020506@cisco.com> <3FFD9E35.6080607@cisco.com> <3FFDC1CE.7060809@cisco.com> In-Reply-To: <3FFDC1CE.7060809@cisco.com> Content-Type: multipart/alternative; boundary="------------080809030609040902040602" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------080809030609040902040602 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit To Alex or anyone from the opes group. I have another question. Does an opes environment handle the requirement of a peer interacting with another peer with a load balancer between them. The situation is that I require two proxies to provide a service. An "A" proxy and a "B" proxy that are peers in providing the service to a data flow. Because of the scale, the likely deployment will involve multiple boxes of types A and B. This means I will have two groups of boxes with a load balancer between them. I wish to dynamically associate an specific box of type A with a specific Box of type B (across the load balancer) and a particular flow. Is it possible to perform peer discovery and the dynamic association between the two peers and a flow within the opes framework? Thanks for any help and guidance. Regards John John G. Waclawsky wrote: > Alex, I very much appreciate your help and the additional > information. I need a little time to digest this and think some more > about my problem and opes "needs".... > Thanks. Regards John > > Alex Rousskov wrote: > >>On Thu, 8 Jan 2004, John G. Waclawsky wrote: >> >> >> >>>Alex, thank you for your reply and the pointer. I agree with you >>>that the use case I am interested in is not explicitly documented in >>>the opes material. This gives the wrong impression, since all the >>>examples show the data flows returning to the first hop data >>>dispatcher. To restrict data flow in this way would be inefficient >>>for high capacity applications and would tend to make the first hop >>>a bottleneck. >>> >>> >> >>John, >> >> You are misreading OPES architecture diagrams because you are >>thinking about a much "simpler" case than most diagrams attempt to >>document and, hence, you assign wrong roles to "boxes" that may not >>even exist in your environment. This is the architecture draft fault, >>not yours. Let me try to explain. >> >>Here is a "classic" OPES proxying case (horizontal lines are >>application data/protocols being proxied, proxies may be adapting data >>internally): >> >> Figure A. >> >> end -- proxy -- proxy -- ... -- end >> >>Here is a "classic" OPES callout case (vertical lines are callout >>data/protocols, proxy is not adapting data, callout servers may be >>adapting data): >> >> Figure B. >> >> end --- proxy --- end >> _________|__________ >> | | | >> | | | >> callout callout callout >> server server server >> >>A combination of the above is possible and common, of course. In a >>combined case, some proxies are adapting data internally and some use >>callout servers to adapt. >> >>In your particular case (the adapted data flows to the next hop), you >>do not have callout servers. You have proxies that adapt data >>internally. However, your case may not be a classic proxying case >>because you may want proxies to use a protocol that differs from the >>original application protocol (so that you can ship metadata and >>perhaps pipeline more efficiently). I will use curly (~) lines to show >>that new protocol below. You may also want to do some load balancing: >> >> Figure C. >> >> ~~~~~ proxy1 --- >> / >> end -- proxy ~~~~~~ proxy2 --- ?? end >> \ >> ~~~~~ proxyN --- >> >> >>I do not know how the proxies will get application data to the right >>"end", but it is not important for this discussion. >> >>Note that the curly path may use a completely new protocol (e.g., OCP) >>or can use a combination of the original application protocol to >>deliver data and some other protocol for metadata (billing, etc.) >>records. >> >>The above is OPES, but not a callout case. There are no callout >>servers, just proxies. Whether you want to use OCP for the curly path >>depends on what kind of data/metadata you want to exchange and what >>other protocols you have available. >> >> >> >>>To be a little more specific on my use case and to make sure I >>>understand your response let me add more detail. Fundamentally, I wish >>>to have an "open" IETF network environment. The second requirement is >>>speed in adaptation processing, so I am thinking that callout will be >>>faster than using a proxy (maybe this is an incorrect assumption). >>> >>> >> >>It's an incorrect question :-). Adaptations at the callout server can >>be as "fast" or as "slow" as adaptations performed internally at the >>proxy. The primary reason to use a callout server is to "outsource" >>(from business, development, support, logistics, legal, etc. points of >>view) adaptations. The primary reasons not to use a callout server are >>security and overheads of the data having to return back to the proxy. >> >> >> >>>I may be a little confused about the distinction between classic >>>proxy and classic call out in this situation (this word proxy isn't >>>even mentioned in the opes architecture document as a >>>consideration). >>> >>> >> >>I hope the above diagrams clarify the distinction. OPES processor is >>the term closest to the "proxy", I think. >> >> >> >>>Also, I have a requirement to adapt a large volume of content for >>>numerous devices. >>> >>> >> >>Both callout and builtin adaptations can handle large volumes of >>content. There are many factors at play here, from legal concerns to >>the kind of adaptation being performed. >> >> >> >>>I expect that the volume of data will require a number of adaptation >>>(call out) processors. I estimate 10 of them and therefore I would >>>need load balancing as part of the solution for directing data to >>>the call out servers (doing the adaptation). >>> >>> >> >>Load balancing can be done with both callout and proxying schemes. >>OPES mechanisms are usually per-message so any load balancing method >>that does not split individual application messages should work just >>fine. >> >> >> >>>I am looking at Figure 3 in the opes architecture draft and >>>considering a load balanced collection of ten call out servers. As I >>>had mentioned previously, I'd like to have parallel pipeline >>>approach where the adapted data from each of the opes call out >>>server is simply forwarded on, directly to the producer or data >>>consumer (what ever the case would be). >>> >>> >> >>The latter makes the adapter a proxy, not a callout server (by >>definition). See Figure C above. >> >> >> >>>In addition each of the opes call out servers would then send >>>billing and trace data back to the load balancer (or another network >>>location). Is it realistic to expect that this could this be >>>accomplished within the opes framework? >>> >>> >> >>It is. The only question is what protocol(s) you will use between your >>proxies (the curly lines in Figure C). >> >> >> >>>In fact a more fundamental question is the opes framework the best >>>way to solve this problem and maintain an open system. I think this >>>is what opes is all about. >>> >>> >> >>IMO, OPES framework accommodates, in principle, any intermediary >>adaptation. Thus, your problem is within the framework. However, the >>framework is not complete. It does not have ready-to-use tools for all >>possible intermediary adaptations. I hope that you will find OCP Core >>and OPES communications "tools" useful for your problems, but I lack >>information to tell your whether they are the best. >> >>The system is "open" if it uses "open standards". If current OPES >>tools are not right for you, and there are no better open tools, then >>we can work together, within the OPES Framework, on defining open >>standards (protocols and interfaces) that will solve your specific >>problem. >> >>Alex. >> >> >> --------------080809030609040902040602 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit To Alex or anyone from the opes group.

I have another question. Does an opes environment handle the requirement of a peer interacting with another peer with a load balancer between them. The situation is that I require two proxies to provide a service. An "A" proxy and a "B" proxy that are peers in providing the service to a data flow. Because of the scale, the likely deployment will involve multiple boxes of types A and B. This means I will have two groups of boxes with a load balancer between them. I wish to dynamically associate an specific box of type A with a specific Box of type B (across the load balancer) and a particular flow. Is it possible to perform peer discovery and the dynamic association between the two peers and a flow within the opes framework? Thanks for any help and guidance.

Regards  John

John G. Waclawsky wrote:
Alex, I very much appreciate your help and the additional  information. I need a little time to digest this and think some more about my problem and opes "needs".... 
Thanks.   Regards  John

Alex Rousskov wrote:
On Thu, 8 Jan 2004, John G. Waclawsky wrote:

  
Alex, thank you for your reply and the pointer. I agree with you
that the use case I am interested in is not explicitly documented in
the opes material. This gives the wrong impression, since all the
examples show the data flows returning to the first hop data
dispatcher. To restrict data flow in this way would be inefficient
for high capacity applications and would tend to make the first hop
a bottleneck.
    

John,

	You are misreading OPES architecture diagrams because you are
thinking about a much "simpler" case than most diagrams attempt to
document and, hence, you assign wrong roles to "boxes" that may not
even exist in your environment. This is the architecture draft fault,
not yours. Let me try to explain.

Here is a "classic" OPES proxying case (horizontal lines are
application data/protocols being proxied, proxies may be adapting data
internally):

    Figure A.

        end -- proxy -- proxy -- ... -- end

Here is a "classic" OPES callout case (vertical lines are callout
data/protocols, proxy is not adapting data, callout servers may be
adapting data):

    Figure B.

        end --- proxy --- end
         _________|__________
         |        |         |
         |        |         |
      callout   callout   callout
      server    server    server

A combination of the above is possible and common, of course. In a
combined case, some proxies are adapting data internally and some use
callout servers to adapt.

In your particular case (the adapted data flows to the next hop), you
do not have callout servers. You have proxies that adapt data
internally. However, your case may not be a classic proxying case
because you may want proxies to use a protocol that differs from the
original application protocol (so that you can ship metadata and
perhaps pipeline more efficiently). I will use curly (~) lines to show
that new protocol below. You may also want to do some load balancing:

    Figure C.

                    ~~~~~ proxy1 ---
                   /
      end -- proxy ~~~~~~ proxy2 ---  ??  end
                   \
                    ~~~~~ proxyN ---


I do not know how the proxies will get application data to the right
"end", but it is not important for this discussion.

Note that the curly path may use a completely new protocol (e.g., OCP)
or can use a combination of the original application protocol to
deliver data and some other protocol for metadata (billing, etc.)
records.

The above is OPES, but not a callout case. There are no callout
servers, just proxies. Whether you want to use OCP for the curly path
depends on what kind of data/metadata you want to exchange and what
other protocols you have available.

  
To be a little more specific on my use case and to make sure I
understand your response let me add more detail. Fundamentally, I wish
to have an "open" IETF network environment. The second requirement is
speed in adaptation processing, so I am thinking that callout will be
faster than using a proxy (maybe this is an incorrect assumption).
    

It's an incorrect question :-). Adaptations at the callout server can
be as "fast" or as "slow" as adaptations performed internally at the
proxy. The primary reason to use a callout server is to "outsource"
(from business, development, support, logistics, legal, etc. points of
view) adaptations. The primary reasons not to use a callout server are
security and overheads of the data having to return back to the proxy.

  
I may be a little confused about the distinction between classic
proxy and classic call out in this situation (this word proxy isn't
even mentioned in the opes architecture document as a
consideration).
    

I hope the above diagrams clarify the distinction. OPES processor is
the term closest to the "proxy", I think.

  
Also, I have a requirement to adapt a large volume of content for
numerous devices.
    

Both callout and builtin adaptations can handle large volumes of
content. There are many factors at play here, from legal concerns to
the kind of adaptation being performed.

  
I expect that the volume of data will require a number of adaptation
(call out) processors. I estimate 10 of them and therefore I would
need load balancing as part of the solution for directing data to
the call out servers (doing the adaptation).
    

Load balancing can be done with both callout and proxying schemes.
OPES mechanisms are usually per-message so any load balancing method
that does not split individual application messages should work just
fine.

  
I am looking at Figure 3 in the opes architecture draft and
considering a load balanced collection of ten call out servers. As I
had mentioned previously, I'd like to have parallel pipeline
approach where the adapted data from each of the opes call out
server is simply forwarded on, directly to the producer or data
consumer (what ever the case would be).
    

The latter makes the adapter a proxy, not a callout server (by
definition). See Figure C above.

  
In addition each of the opes call out servers would then send
billing and trace data back to the load balancer (or another network
location). Is it realistic to expect that this could this be
accomplished within the opes framework?
    

It is. The only question is what protocol(s) you will use between your
proxies (the curly lines in Figure C).

  
In fact a more fundamental question is the opes framework the best
way to solve this problem and maintain an open system. I think this
is what opes is all about.
    

IMO, OPES framework accommodates, in principle, any intermediary
adaptation. Thus, your problem is within the framework. However, the
framework is not complete. It does not have ready-to-use tools for all
possible intermediary adaptations. I hope that you will find OCP Core
and OPES communications "tools" useful for your problems, but I lack
information to tell your whether they are the best.

The system is "open" if it uses "open standards". If current OPES
tools are not right for you, and there are no better open tools, then
we can work together, within the OPES Framework, on defining open
standards (protocols and interfaces) that will solve your specific
problem.

Alex.
--------------080809030609040902040602-- From owner-ietf-openproxy@mail.imc.org Fri Feb 27 15:41:21 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23517 for ; Fri, 27 Feb 2004 15:41:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwonS-0002vR-00 for opes-archive@ietf.org; Fri, 27 Feb 2004 15:41:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwomD-0002eo-00 for opes-archive@ietf.org; Fri, 27 Feb 2004 15:40:06 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Awoki-0002Ky-00 for opes-archive@ietf.org; Fri, 27 Feb 2004 15:38:32 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1RK5kfL041449; Fri, 27 Feb 2004 12:05:46 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1RK5k76041448; Fri, 27 Feb 2004 12:05:46 -0800 (PST) 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.11/8.12.8) with ESMTP id i1RK5isS041439 for ; Fri, 27 Feb 2004 12:05:45 -0800 (PST) (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 i1RK5gBq039840; Fri, 27 Feb 2004 13:05:42 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i1RK5gaL039839; Fri, 27 Feb 2004 13:05:42 -0700 (MST) (envelope-from rousskov) Date: Fri, 27 Feb 2004 13:05:42 -0700 (MST) From: Alex Rousskov To: "John G. Waclawsky" cc: OPES Group , Krishna Ramadas Subject: Re: An opes usage question. In-Reply-To: <403F9EBE.8030709@cisco.com> Message-ID: References: <3FFC8D88.7020506@cisco.com> <3FFD9E35.6080607@cisco.com> <3FFDC1CE.7060809@cisco.com> <403F9EBE.8030709@cisco.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: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 John, OPES protocols do not have features specific to a load-balancing environment, and I do not think they have any features that do not work in such an environment. If your load balancer can balance opaque TCP sessions, then OPES callout protocol should work just fine with multiple callout servers. If you are proxying native HTTP without outsourcing services via OCP, then load balancers can balance HTTP "sessions" as well. OCP is easier to load balance than HTTP because it does not have valuable state outside of the OCP connection. While HTTP claims to be stateless, things built on top of HTTP often require client/server affinity. Hopefully, OCP will not be abused in such a way because it has mechanisms to maintain necessary state within the connection. HTH, Alex. On Fri, 27 Feb 2004, John G. Waclawsky wrote: > I have another question. Does an opes environment handle the > requirement of a peer interacting with another peer with a load > balancer between them. The situation is that I require two proxies > to provide a service. An "A" proxy and a "B" proxy that are peers > in providing the service to a data flow. Because of the scale, the > likely deployment will involve multiple boxes of types A and B. This > means I will have two groups of boxes with a load balancer between > them. I wish to dynamically associate an specific box of type A with > a specific Box of type B (across the load balancer) and a particular > flow. Is it possible to perform peer discovery and the dynamic > association between the two peers and a flow within the opes > framework? Thanks for any help and guidance. > > Regards John > > John G. Waclawsky wrote: > > > Alex, I very much appreciate your help and the additional > > information. I need a little time to digest this and think some more > > about my problem and opes "needs".... > > Thanks. Regards John > > > > Alex Rousskov wrote: > > > >>On Thu, 8 Jan 2004, John G. Waclawsky wrote: > >> > >> > >> > >>>Alex, thank you for your reply and the pointer. I agree with you > >>>that the use case I am interested in is not explicitly documented in > >>>the opes material. This gives the wrong impression, since all the > >>>examples show the data flows returning to the first hop data > >>>dispatcher. To restrict data flow in this way would be inefficient > >>>for high capacity applications and would tend to make the first hop > >>>a bottleneck. > >>> > >>> > >> > >>John, > >> > >> You are misreading OPES architecture diagrams because you are > >>thinking about a much "simpler" case than most diagrams attempt to > >>document and, hence, you assign wrong roles to "boxes" that may not > >>even exist in your environment. This is the architecture draft fault, > >>not yours. Let me try to explain. > >> > >>Here is a "classic" OPES proxying case (horizontal lines are > >>application data/protocols being proxied, proxies may be adapting data > >>internally): > >> > >> Figure A. > >> > >> end -- proxy -- proxy -- ... -- end > >> > >>Here is a "classic" OPES callout case (vertical lines are callout > >>data/protocols, proxy is not adapting data, callout servers may be > >>adapting data): > >> > >> Figure B. > >> > >> end --- proxy --- end > >> _________|__________ > >> | | | > >> | | | > >> callout callout callout > >> server server server > >> > >>A combination of the above is possible and common, of course. In a > >>combined case, some proxies are adapting data internally and some use > >>callout servers to adapt. > >> > >>In your particular case (the adapted data flows to the next hop), you > >>do not have callout servers. You have proxies that adapt data > >>internally. However, your case may not be a classic proxying case > >>because you may want proxies to use a protocol that differs from the > >>original application protocol (so that you can ship metadata and > >>perhaps pipeline more efficiently). I will use curly (~) lines to show > >>that new protocol below. You may also want to do some load balancing: > >> > >> Figure C. > >> > >> ~~~~~ proxy1 --- > >> / > >> end -- proxy ~~~~~~ proxy2 --- ?? end > >> \ > >> ~~~~~ proxyN --- > >> > >> > >>I do not know how the proxies will get application data to the right > >>"end", but it is not important for this discussion. > >> > >>Note that the curly path may use a completely new protocol (e.g., OCP) > >>or can use a combination of the original application protocol to > >>deliver data and some other protocol for metadata (billing, etc.) > >>records. > >> > >>The above is OPES, but not a callout case. There are no callout > >>servers, just proxies. Whether you want to use OCP for the curly path > >>depends on what kind of data/metadata you want to exchange and what > >>other protocols you have available. > >> > >> > >> > >>>To be a little more specific on my use case and to make sure I > >>>understand your response let me add more detail. Fundamentally, I wish > >>>to have an "open" IETF network environment. The second requirement is > >>>speed in adaptation processing, so I am thinking that callout will be > >>>faster than using a proxy (maybe this is an incorrect assumption). > >>> > >>> > >> > >>It's an incorrect question :-). Adaptations at the callout server can > >>be as "fast" or as "slow" as adaptations performed internally at the > >>proxy. The primary reason to use a callout server is to "outsource" > >>(from business, development, support, logistics, legal, etc. points of > >>view) adaptations. The primary reasons not to use a callout server are > >>security and overheads of the data having to return back to the proxy. > >> > >> > >> > >>>I may be a little confused about the distinction between classic > >>>proxy and classic call out in this situation (this word proxy isn't > >>>even mentioned in the opes architecture document as a > >>>consideration). > >>> > >>> > >> > >>I hope the above diagrams clarify the distinction. OPES processor is > >>the term closest to the "proxy", I think. > >> > >> > >> > >>>Also, I have a requirement to adapt a large volume of content for > >>>numerous devices. > >>> > >>> > >> > >>Both callout and builtin adaptations can handle large volumes of > >>content. There are many factors at play here, from legal concerns to > >>the kind of adaptation being performed. > >> > >> > >> > >>>I expect that the volume of data will require a number of adaptation > >>>(call out) processors. I estimate 10 of them and therefore I would > >>>need load balancing as part of the solution for directing data to > >>>the call out servers (doing the adaptation). > >>> > >>> > >> > >>Load balancing can be done with both callout and proxying schemes. > >>OPES mechanisms are usually per-message so any load balancing method > >>that does not split individual application messages should work just > >>fine. > >> > >> > >> > >>>I am looking at Figure 3 in the opes architecture draft and > >>>considering a load balanced collection of ten call out servers. As I > >>>had mentioned previously, I'd like to have parallel pipeline > >>>approach where the adapted data from each of the opes call out > >>>server is simply forwarded on, directly to the producer or data > >>>consumer (what ever the case would be). > >>> > >>> > >> > >>The latter makes the adapter a proxy, not a callout server (by > >>definition). See Figure C above. > >> > >> > >> > >>>In addition each of the opes call out servers would then send > >>>billing and trace data back to the load balancer (or another network > >>>location). Is it realistic to expect that this could this be > >>>accomplished within the opes framework? > >>> > >>> > >> > >>It is. The only question is what protocol(s) you will use between your > >>proxies (the curly lines in Figure C). > >> > >> > >> > >>>In fact a more fundamental question is the opes framework the best > >>>way to solve this problem and maintain an open system. I think this > >>>is what opes is all about. > >>> > >>> > >> > >>IMO, OPES framework accommodates, in principle, any intermediary > >>adaptation. Thus, your problem is within the framework. However, the > >>framework is not complete. It does not have ready-to-use tools for all > >>possible intermediary adaptations. I hope that you will find OCP Core > >>and OPES communications "tools" useful for your problems, but I lack > >>information to tell your whether they are the best. > >> > >>The system is "open" if it uses "open standards". If current OPES > >>tools are not right for you, and there are no better open tools, then > >>we can work together, within the OPES Framework, on defining open > >>standards (protocols and interfaces) that will solve your specific > >>problem. > >> > >>Alex. > >> > >> > >> > From owner-ietf-openproxy@mail.imc.org Fri Feb 27 16:54:36 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26568 for ; Fri, 27 Feb 2004 16:54:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwpwL-0003ma-00 for opes-archive@ietf.org; Fri, 27 Feb 2004 16:54:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwpvM-0003fR-00 for opes-archive@ietf.org; Fri, 27 Feb 2004 16:53:38 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AwpuS-0003aH-00 for opes-archive@ietf.org; Fri, 27 Feb 2004 16:52:40 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1RLfAwV048322; Fri, 27 Feb 2004 13:41:10 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1RLfAoP048321; Fri, 27 Feb 2004 13:41:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1RLf9sr048313 for ; Fri, 27 Feb 2004 13:41:09 -0800 (PST) (envelope-from jgw@cisco.com) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 27 Feb 2004 13:51:53 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1RLf64U001899; Fri, 27 Feb 2004 13:41:07 -0800 (PST) Received: from cisco.com (rtp-vpn2-783.cisco.com [10.82.243.15]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQS40797; Fri, 27 Feb 2004 13:41:04 -0800 (PST) Message-ID: <403FB970.7060400@cisco.com> Date: Fri, 27 Feb 2004 16:41:04 -0500 From: "John G. Waclawsky" Reply-To: jgw@cisco.com Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Rousskov CC: OPES Group , Krishna Ramadas Subject: Re: An opes usage question. References: <3FFC8D88.7020506@cisco.com> <3FFD9E35.6080607@cisco.com> <3FFDC1CE.7060809@cisco.com> <403F9EBE.8030709@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020900070809070503010603" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------020900070809070503010603 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Alex, you had mentioned in a previous e-mail that the "framework is not complete. It does not have ready-to-use tools for all possible intermediary adaptations". Would this include a load balancing environment? Specifically, load balancing is not the problem that I currently see. I believe I can make the load balancers work with what I anticipate doing within an opes framework. But, I am looking for a general opes solution that allows peer discovery so I can perform adaptations (pipelined over load balancers, if you will) on a number of flows, web pages, file downloads,...etc. I consider load balancing as an essential part of a "typical" high capacity services situation. My thoughts are that peer discovery is necessary as an option for a load balanced opes environment. Are you saying in your reply that OCP can also be used for peer discovery? If not, shouldn't the opes framework be extended to satisfy a peer discovery use case over a load balancer? I was thinking another protocol between peers might be needed (or we can use an existing protocol). Any suggestions? Your thoughts? Regards John Alex Rousskov wrote: >John, > > OPES protocols do not have features specific to a >load-balancing environment, and I do not think they have any features >that do not work in such an environment. If your load balancer can >balance opaque TCP sessions, then OPES callout protocol should work >just fine with multiple callout servers. If you are proxying native >HTTP without outsourcing services via OCP, then load balancers can >balance HTTP "sessions" as well. > > OCP is easier to load balance than HTTP because it does not >have valuable state outside of the OCP connection. While HTTP claims >to be stateless, things built on top of HTTP often require >client/server affinity. Hopefully, OCP will not be abused in such a >way because it has mechanisms to maintain necessary state within the >connection. > >HTH, > >Alex. > >On Fri, 27 Feb 2004, John G. Waclawsky wrote: > > > >>I have another question. Does an opes environment handle the >>requirement of a peer interacting with another peer with a load >>balancer between them. The situation is that I require two proxies >>to provide a service. An "A" proxy and a "B" proxy that are peers >>in providing the service to a data flow. Because of the scale, the >>likely deployment will involve multiple boxes of types A and B. This >>means I will have two groups of boxes with a load balancer between >>them. I wish to dynamically associate an specific box of type A with >>a specific Box of type B (across the load balancer) and a particular >>flow. Is it possible to perform peer discovery and the dynamic >>association between the two peers and a flow within the opes >>framework? Thanks for any help and guidance. >> >>Regards John >> >>John G. Waclawsky wrote: >> >> >> >>>Alex, I very much appreciate your help and the additional >>>information. I need a little time to digest this and think some more >>>about my problem and opes "needs".... >>>Thanks. Regards John >>> >>>Alex Rousskov wrote: >>> >>> >>> >>>>On Thu, 8 Jan 2004, John G. Waclawsky wrote: >>>> >>>> >>>> >>>> >>>> >>>>>Alex, thank you for your reply and the pointer. I agree with you >>>>>that the use case I am interested in is not explicitly documented in >>>>>the opes material. This gives the wrong impression, since all the >>>>>examples show the data flows returning to the first hop data >>>>>dispatcher. To restrict data flow in this way would be inefficient >>>>>for high capacity applications and would tend to make the first hop >>>>>a bottleneck. >>>>> >>>>> >>>>> >>>>> >>>>John, >>>> >>>> You are misreading OPES architecture diagrams because you are >>>>thinking about a much "simpler" case than most diagrams attempt to >>>>document and, hence, you assign wrong roles to "boxes" that may not >>>>even exist in your environment. This is the architecture draft fault, >>>>not yours. Let me try to explain. >>>> >>>>Here is a "classic" OPES proxying case (horizontal lines are >>>>application data/protocols being proxied, proxies may be adapting data >>>>internally): >>>> >>>> Figure A. >>>> >>>> end -- proxy -- proxy -- ... -- end >>>> >>>>Here is a "classic" OPES callout case (vertical lines are callout >>>>data/protocols, proxy is not adapting data, callout servers may be >>>>adapting data): >>>> >>>> Figure B. >>>> >>>> end --- proxy --- end >>>> _________|__________ >>>> | | | >>>> | | | >>>> callout callout callout >>>> server server server >>>> >>>>A combination of the above is possible and common, of course. In a >>>>combined case, some proxies are adapting data internally and some use >>>>callout servers to adapt. >>>> >>>>In your particular case (the adapted data flows to the next hop), you >>>>do not have callout servers. You have proxies that adapt data >>>>internally. However, your case may not be a classic proxying case >>>>because you may want proxies to use a protocol that differs from the >>>>original application protocol (so that you can ship metadata and >>>>perhaps pipeline more efficiently). I will use curly (~) lines to show >>>>that new protocol below. You may also want to do some load balancing: >>>> >>>> Figure C. >>>> >>>> ~~~~~ proxy1 --- >>>> / >>>> end -- proxy ~~~~~~ proxy2 --- ?? end >>>> \ >>>> ~~~~~ proxyN --- >>>> >>>> >>>>I do not know how the proxies will get application data to the right >>>>"end", but it is not important for this discussion. >>>> >>>>Note that the curly path may use a completely new protocol (e.g., OCP) >>>>or can use a combination of the original application protocol to >>>>deliver data and some other protocol for metadata (billing, etc.) >>>>records. >>>> >>>>The above is OPES, but not a callout case. There are no callout >>>>servers, just proxies. Whether you want to use OCP for the curly path >>>>depends on what kind of data/metadata you want to exchange and what >>>>other protocols you have available. >>>> >>>> >>>> >>>> >>>> >>>>>To be a little more specific on my use case and to make sure I >>>>>understand your response let me add more detail. Fundamentally, I wish >>>>>to have an "open" IETF network environment. The second requirement is >>>>>speed in adaptation processing, so I am thinking that callout will be >>>>>faster than using a proxy (maybe this is an incorrect assumption). >>>>> >>>>> >>>>> >>>>> >>>>It's an incorrect question :-). Adaptations at the callout server can >>>>be as "fast" or as "slow" as adaptations performed internally at the >>>>proxy. The primary reason to use a callout server is to "outsource" >>>>(from business, development, support, logistics, legal, etc. points of >>>>view) adaptations. The primary reasons not to use a callout server are >>>>security and overheads of the data having to return back to the proxy. >>>> >>>> >>>> >>>> >>>> >>>>>I may be a little confused about the distinction between classic >>>>>proxy and classic call out in this situation (this word proxy isn't >>>>>even mentioned in the opes architecture document as a >>>>>consideration). >>>>> >>>>> >>>>> >>>>> >>>>I hope the above diagrams clarify the distinction. OPES processor is >>>>the term closest to the "proxy", I think. >>>> >>>> >>>> >>>> >>>> >>>>>Also, I have a requirement to adapt a large volume of content for >>>>>numerous devices. >>>>> >>>>> >>>>> >>>>> >>>>Both callout and builtin adaptations can handle large volumes of >>>>content. There are many factors at play here, from legal concerns to >>>>the kind of adaptation being performed. >>>> >>>> >>>> >>>> >>>> >>>>>I expect that the volume of data will require a number of adaptation >>>>>(call out) processors. I estimate 10 of them and therefore I would >>>>>need load balancing as part of the solution for directing data to >>>>>the call out servers (doing the adaptation). >>>>> >>>>> >>>>> >>>>> >>>>Load balancing can be done with both callout and proxying schemes. >>>>OPES mechanisms are usually per-message so any load balancing method >>>>that does not split individual application messages should work just >>>>fine. >>>> >>>> >>>> >>>> >>>> >>>>>I am looking at Figure 3 in the opes architecture draft and >>>>>considering a load balanced collection of ten call out servers. As I >>>>>had mentioned previously, I'd like to have parallel pipeline >>>>>approach where the adapted data from each of the opes call out >>>>>server is simply forwarded on, directly to the producer or data >>>>>consumer (what ever the case would be). >>>>> >>>>> >>>>> >>>>> >>>>The latter makes the adapter a proxy, not a callout server (by >>>>definition). See Figure C above. >>>> >>>> >>>> >>>> >>>> >>>>>In addition each of the opes call out servers would then send >>>>>billing and trace data back to the load balancer (or another network >>>>>location). Is it realistic to expect that this could this be >>>>>accomplished within the opes framework? >>>>> >>>>> >>>>> >>>>> >>>>It is. The only question is what protocol(s) you will use between your >>>>proxies (the curly lines in Figure C). >>>> >>>> >>>> >>>> >>>> >>>>>In fact a more fundamental question is the opes framework the best >>>>>way to solve this problem and maintain an open system. I think this >>>>>is what opes is all about. >>>>> >>>>> >>>>> >>>>> >>>>IMO, OPES framework accommodates, in principle, any intermediary >>>>adaptation. Thus, your problem is within the framework. However, the >>>>framework is not complete. It does not have ready-to-use tools for all >>>>possible intermediary adaptations. I hope that you will find OCP Core >>>>and OPES communications "tools" useful for your problems, but I lack >>>>information to tell your whether they are the best. >>>> >>>>The system is "open" if it uses "open standards". If current OPES >>>>tools are not right for you, and there are no better open tools, then >>>>we can work together, within the OPES Framework, on defining open >>>>standards (protocols and interfaces) that will solve your specific >>>>problem. >>>> >>>>Alex. >>>> >>>> >>>> >>>> >>>> > > > --------------020900070809070503010603 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Alex, you had mentioned in a previous e-mail that the "framework is not complete. It does not have ready-to-use tools for all  possible intermediary adaptations". Would this include a load balancing environment? Specifically, load balancing is not the problem that I currently see. I believe I can make the load balancers work with what I anticipate doing within an opes framework. But, I am looking for a general opes solution that allows peer discovery so I can perform adaptations (pipelined over load balancers, if you will) on a number of flows, web pages, file downloads,...etc. I consider load balancing as an essential part of a "typical" high capacity services situation. My thoughts are that peer discovery is necessary as an option for a load balanced opes  environment. Are you saying in your reply that OCP can also be used for peer discovery? If not, shouldn't the opes framework be extended to satisfy a peer discovery use case over a load balancer? I was thinking another protocol between peers might be  needed (or we can use an existing protocol). Any suggestions? Your thoughts? 

Regards  John

Alex Rousskov wrote:
John,

	OPES protocols do not have features specific to a
load-balancing environment, and I do not think they have any features
that do not work in such an environment. If your load balancer can
balance opaque TCP sessions, then OPES callout protocol should work
just fine with multiple callout servers. If you are proxying native
HTTP without outsourcing services via OCP, then load balancers can
balance HTTP "sessions" as well.

	OCP is easier to load balance than HTTP because it does not
have valuable state outside of the OCP connection. While HTTP claims
to be stateless, things built on top of HTTP often require
client/server affinity. Hopefully, OCP will not be abused in such a
way because it has mechanisms to maintain necessary state within the
connection.

HTH,

Alex.

On Fri, 27 Feb 2004, John G. Waclawsky wrote:

  
I have another question. Does an opes environment handle the
requirement of a peer interacting with another peer with a load
balancer between them. The situation is that I require two proxies
to provide a service.  An "A" proxy and a "B" proxy that are peers
in providing the service to a data flow. Because of the scale, the
likely deployment will involve multiple boxes of types A and B. This
means I will have two groups of boxes with a load balancer between
them. I wish to dynamically associate an specific box of type A with
a specific Box of type B (across the load balancer) and a particular
flow. Is it possible to perform peer discovery and the dynamic
association between the two peers and a flow within the opes
framework? Thanks for any help and guidance.

Regards  John

John G. Waclawsky wrote:

    
Alex, I very much appreciate your help and the additional
information. I need a little time to digest this and think some more
about my problem and opes "needs"....
Thanks.   Regards  John

Alex Rousskov wrote:

      
On Thu, 8 Jan 2004, John G. Waclawsky wrote:



        
Alex, thank you for your reply and the pointer. I agree with you
that the use case I am interested in is not explicitly documented in
the opes material. This gives the wrong impression, since all the
examples show the data flows returning to the first hop data
dispatcher. To restrict data flow in this way would be inefficient
for high capacity applications and would tend to make the first hop
a bottleneck.


          
John,

	You are misreading OPES architecture diagrams because you are
thinking about a much "simpler" case than most diagrams attempt to
document and, hence, you assign wrong roles to "boxes" that may not
even exist in your environment. This is the architecture draft fault,
not yours. Let me try to explain.

Here is a "classic" OPES proxying case (horizontal lines are
application data/protocols being proxied, proxies may be adapting data
internally):

   Figure A.

       end -- proxy -- proxy -- ... -- end

Here is a "classic" OPES callout case (vertical lines are callout
data/protocols, proxy is not adapting data, callout servers may be
adapting data):

   Figure B.

       end --- proxy --- end
        _________|__________
        |        |         |
        |        |         |
     callout   callout   callout
     server    server    server

A combination of the above is possible and common, of course. In a
combined case, some proxies are adapting data internally and some use
callout servers to adapt.

In your particular case (the adapted data flows to the next hop), you
do not have callout servers. You have proxies that adapt data
internally. However, your case may not be a classic proxying case
because you may want proxies to use a protocol that differs from the
original application protocol (so that you can ship metadata and
perhaps pipeline more efficiently). I will use curly (~) lines to show
that new protocol below. You may also want to do some load balancing:

   Figure C.

                   ~~~~~ proxy1 ---
                  /
     end -- proxy ~~~~~~ proxy2 ---  ??  end
                  \
                   ~~~~~ proxyN ---


I do not know how the proxies will get application data to the right
"end", but it is not important for this discussion.

Note that the curly path may use a completely new protocol (e.g., OCP)
or can use a combination of the original application protocol to
deliver data and some other protocol for metadata (billing, etc.)
records.

The above is OPES, but not a callout case. There are no callout
servers, just proxies. Whether you want to use OCP for the curly path
depends on what kind of data/metadata you want to exchange and what
other protocols you have available.



        
To be a little more specific on my use case and to make sure I
understand your response let me add more detail. Fundamentally, I wish
to have an "open" IETF network environment. The second requirement is
speed in adaptation processing, so I am thinking that callout will be
faster than using a proxy (maybe this is an incorrect assumption).


          
It's an incorrect question :-). Adaptations at the callout server can
be as "fast" or as "slow" as adaptations performed internally at the
proxy. The primary reason to use a callout server is to "outsource"
(from business, development, support, logistics, legal, etc. points of
view) adaptations. The primary reasons not to use a callout server are
security and overheads of the data having to return back to the proxy.



        
I may be a little confused about the distinction between classic
proxy and classic call out in this situation (this word proxy isn't
even mentioned in the opes architecture document as a
consideration).


          
I hope the above diagrams clarify the distinction. OPES processor is
the term closest to the "proxy", I think.



        
Also, I have a requirement to adapt a large volume of content for
numerous devices.


          
Both callout and builtin adaptations can handle large volumes of
content. There are many factors at play here, from legal concerns to
the kind of adaptation being performed.



        
I expect that the volume of data will require a number of adaptation
(call out) processors. I estimate 10 of them and therefore I would
need load balancing as part of the solution for directing data to
the call out servers (doing the adaptation).


          
Load balancing can be done with both callout and proxying schemes.
OPES mechanisms are usually per-message so any load balancing method
that does not split individual application messages should work just
fine.



        
I am looking at Figure 3 in the opes architecture draft and
considering a load balanced collection of ten call out servers. As I
had mentioned previously, I'd like to have parallel pipeline
approach where the adapted data from each of the opes call out
server is simply forwarded on, directly to the producer or data
consumer (what ever the case would be).


          
The latter makes the adapter a proxy, not a callout server (by
definition). See Figure C above.



        
In addition each of the opes call out servers would then send
billing and trace data back to the load balancer (or another network
location). Is it realistic to expect that this could this be
accomplished within the opes framework?


          
It is. The only question is what protocol(s) you will use between your
proxies (the curly lines in Figure C).



        
In fact a more fundamental question is the opes framework the best
way to solve this problem and maintain an open system. I think this
is what opes is all about.


          
IMO, OPES framework accommodates, in principle, any intermediary
adaptation. Thus, your problem is within the framework. However, the
framework is not complete. It does not have ready-to-use tools for all
possible intermediary adaptations. I hope that you will find OCP Core
and OPES communications "tools" useful for your problems, but I lack
information to tell your whether they are the best.

The system is "open" if it uses "open standards". If current OPES
tools are not right for you, and there are no better open tools, then
we can work together, within the OPES Framework, on defining open
standards (protocols and interfaces) that will solve your specific
problem.

Alex.
--------------020900070809070503010603-- From owner-ietf-openproxy@mail.imc.org Fri Feb 27 17:40:34 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29397 for ; Fri, 27 Feb 2004 17:40:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awqeq-0001dy-00 for opes-archive@ietf.org; Fri, 27 Feb 2004 17:40:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awqdu-0001Z1-00 for opes-archive@ietf.org; Fri, 27 Feb 2004 17:39:39 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AwqdN-0001UJ-00 for opes-archive@ietf.org; Fri, 27 Feb 2004 17:39:05 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1RM8BWP049498; Fri, 27 Feb 2004 14:08:11 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1RM8B0w049497; Fri, 27 Feb 2004 14:08:11 -0800 (PST) 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.11/8.12.8) with ESMTP id i1RM896v049491 for ; Fri, 27 Feb 2004 14:08:10 -0800 (PST) (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 i1RM8CBq045569; Fri, 27 Feb 2004 15:08:12 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i1RM8BuA045568; Fri, 27 Feb 2004 15:08:12 -0700 (MST) (envelope-from rousskov) Date: Fri, 27 Feb 2004 15:08:11 -0700 (MST) From: Alex Rousskov To: "John G. Waclawsky" cc: OPES Group , Krishna Ramadas Subject: Re: An opes usage question. In-Reply-To: <403FB970.7060400@cisco.com> Message-ID: References: <3FFC8D88.7020506@cisco.com> <3FFD9E35.6080607@cisco.com> <3FFDC1CE.7060809@cisco.com> <403F9EBE.8030709@cisco.com> <403FB970.7060400@cisco.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: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Fri, 27 Feb 2004, John G. Waclawsky wrote: > Alex, you had mentioned in a previous e-mail that the "framework is > not complete. It does not have ready-to-use tools for all possible > intermediary adaptations". Would this include a load balancing > environment? Possibly, but it is too early to say. I do not know if any opes-specific tools will be needed in a load balancing environment. For example, as far as I can see, to load balance callout server adaptations, no new tools are needed and OCP can be used as is. > Specifically, load balancing is not the problem that I currently > see. I believe I can make the load balancers work with what I > anticipate doing within an opes framework. Looks like we are in agreement here. > But, I am looking for a general opes solution that allows peer > discovery so I can perform adaptations (pipelined over load > balancers, if you will) on a number of flows, web pages, file > downloads,...etc. By "peer discovery", do you mean discovering callout servers that provide OPES services that the application proxy needs? If yes, then this discovery is out of OCP and possibly even OPES scope. It can be implemented using existing or new protocols on top of OPES protocols. The closest thing to peer discovery supported in OCP is querying an OCP peer for a list of supported services or negotiating service support. Both can only be done if we have established a connection to the peer, which is what peer discovery should help us with. > I consider load balancing as an essential part of a "typical" high > capacity services situation. My thoughts are that peer discovery is > necessary as an option for a load balanced opes environment. I see no direct relationship between load balancing and peer discovery. I define load balancing as spreading the load among a known set of servers. I define peer discovery as locating potentially useful servers. The two can be combined (discover what servers we can use for load balancing), but are independent. > Are you saying in your reply that OCP can also be used for peer > discovery? No. > If not, shouldn't the opes framework be extended to satisfy a peer > discovery use case over a load balancer? Only if there is something really OPES-specific in this peer discovery problem. As you know, peer discovery in general is an old problem with a few semi-working solutions and no good ones. What OPES-specific peer discovery features would you like the framework extension to support? And, again, I am not sure how you connect peer discovery and load balancing. > I was thinking another protocol between peers might be needed (or we > can use an existing protocol). Hopefully, that another protocol already exists and can be used as-is. Can you give a very specific example: who needs to discover what and how is that related to load balancing? Thanks, Alex. > Alex Rousskov wrote: > > >John, > > > > OPES protocols do not have features specific to a > >load-balancing environment, and I do not think they have any features > >that do not work in such an environment. If your load balancer can > >balance opaque TCP sessions, then OPES callout protocol should work > >just fine with multiple callout servers. If you are proxying native > >HTTP without outsourcing services via OCP, then load balancers can > >balance HTTP "sessions" as well. > > > > OCP is easier to load balance than HTTP because it does not > >have valuable state outside of the OCP connection. While HTTP claims > >to be stateless, things built on top of HTTP often require > >client/server affinity. Hopefully, OCP will not be abused in such a > >way because it has mechanisms to maintain necessary state within the > >connection. > > > >HTH, > > > >Alex. > > > >On Fri, 27 Feb 2004, John G. Waclawsky wrote: > > > > > > > >>I have another question. Does an opes environment handle the > >>requirement of a peer interacting with another peer with a load > >>balancer between them. The situation is that I require two proxies > >>to provide a service. An "A" proxy and a "B" proxy that are peers > >>in providing the service to a data flow. Because of the scale, the > >>likely deployment will involve multiple boxes of types A and B. This > >>means I will have two groups of boxes with a load balancer between > >>them. I wish to dynamically associate an specific box of type A with > >>a specific Box of type B (across the load balancer) and a particular > >>flow. Is it possible to perform peer discovery and the dynamic > >>association between the two peers and a flow within the opes > >>framework? Thanks for any help and guidance. > >> > >>Regards John > >> > >>John G. Waclawsky wrote: > >> > >> > >> > >>>Alex, I very much appreciate your help and the additional > >>>information. I need a little time to digest this and think some more > >>>about my problem and opes "needs".... > >>>Thanks. Regards John > >>> > >>>Alex Rousskov wrote: > >>> > >>> > >>> > >>>>On Thu, 8 Jan 2004, John G. Waclawsky wrote: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>Alex, thank you for your reply and the pointer. I agree with you > >>>>>that the use case I am interested in is not explicitly documented in > >>>>>the opes material. This gives the wrong impression, since all the > >>>>>examples show the data flows returning to the first hop data > >>>>>dispatcher. To restrict data flow in this way would be inefficient > >>>>>for high capacity applications and would tend to make the first hop > >>>>>a bottleneck. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>John, > >>>> > >>>> You are misreading OPES architecture diagrams because you are > >>>>thinking about a much "simpler" case than most diagrams attempt to > >>>>document and, hence, you assign wrong roles to "boxes" that may not > >>>>even exist in your environment. This is the architecture draft fault, > >>>>not yours. Let me try to explain. > >>>> > >>>>Here is a "classic" OPES proxying case (horizontal lines are > >>>>application data/protocols being proxied, proxies may be adapting data > >>>>internally): > >>>> > >>>> Figure A. > >>>> > >>>> end -- proxy -- proxy -- ... -- end > >>>> > >>>>Here is a "classic" OPES callout case (vertical lines are callout > >>>>data/protocols, proxy is not adapting data, callout servers may be > >>>>adapting data): > >>>> > >>>> Figure B. > >>>> > >>>> end --- proxy --- end > >>>> _________|__________ > >>>> | | | > >>>> | | | > >>>> callout callout callout > >>>> server server server > >>>> > >>>>A combination of the above is possible and common, of course. In a > >>>>combined case, some proxies are adapting data internally and some use > >>>>callout servers to adapt. > >>>> > >>>>In your particular case (the adapted data flows to the next hop), you > >>>>do not have callout servers. You have proxies that adapt data > >>>>internally. However, your case may not be a classic proxying case > >>>>because you may want proxies to use a protocol that differs from the > >>>>original application protocol (so that you can ship metadata and > >>>>perhaps pipeline more efficiently). I will use curly (~) lines to show > >>>>that new protocol below. You may also want to do some load balancing: > >>>> > >>>> Figure C. > >>>> > >>>> ~~~~~ proxy1 --- > >>>> / > >>>> end -- proxy ~~~~~~ proxy2 --- ?? end > >>>> \ > >>>> ~~~~~ proxyN --- > >>>> > >>>> > >>>>I do not know how the proxies will get application data to the right > >>>>"end", but it is not important for this discussion. > >>>> > >>>>Note that the curly path may use a completely new protocol (e.g., OCP) > >>>>or can use a combination of the original application protocol to > >>>>deliver data and some other protocol for metadata (billing, etc.) > >>>>records. > >>>> > >>>>The above is OPES, but not a callout case. There are no callout > >>>>servers, just proxies. Whether you want to use OCP for the curly path > >>>>depends on what kind of data/metadata you want to exchange and what > >>>>other protocols you have available. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>To be a little more specific on my use case and to make sure I > >>>>>understand your response let me add more detail. Fundamentally, I wish > >>>>>to have an "open" IETF network environment. The second requirement is > >>>>>speed in adaptation processing, so I am thinking that callout will be > >>>>>faster than using a proxy (maybe this is an incorrect assumption). > >>>>> > >>>>> > >>>>> > >>>>> > >>>>It's an incorrect question :-). Adaptations at the callout server can > >>>>be as "fast" or as "slow" as adaptations performed internally at the > >>>>proxy. The primary reason to use a callout server is to "outsource" > >>>>(from business, development, support, logistics, legal, etc. points of > >>>>view) adaptations. The primary reasons not to use a callout server are > >>>>security and overheads of the data having to return back to the proxy. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>I may be a little confused about the distinction between classic > >>>>>proxy and classic call out in this situation (this word proxy isn't > >>>>>even mentioned in the opes architecture document as a > >>>>>consideration). > >>>>> > >>>>> > >>>>> > >>>>> > >>>>I hope the above diagrams clarify the distinction. OPES processor is > >>>>the term closest to the "proxy", I think. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>Also, I have a requirement to adapt a large volume of content for > >>>>>numerous devices. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>Both callout and builtin adaptations can handle large volumes of > >>>>content. There are many factors at play here, from legal concerns to > >>>>the kind of adaptation being performed. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>I expect that the volume of data will require a number of adaptation > >>>>>(call out) processors. I estimate 10 of them and therefore I would > >>>>>need load balancing as part of the solution for directing data to > >>>>>the call out servers (doing the adaptation). > >>>>> > >>>>> > >>>>> > >>>>> > >>>>Load balancing can be done with both callout and proxying schemes. > >>>>OPES mechanisms are usually per-message so any load balancing method > >>>>that does not split individual application messages should work just > >>>>fine. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>I am looking at Figure 3 in the opes architecture draft and > >>>>>considering a load balanced collection of ten call out servers. As I > >>>>>had mentioned previously, I'd like to have parallel pipeline > >>>>>approach where the adapted data from each of the opes call out > >>>>>server is simply forwarded on, directly to the producer or data > >>>>>consumer (what ever the case would be). > >>>>> > >>>>> > >>>>> > >>>>> > >>>>The latter makes the adapter a proxy, not a callout server (by > >>>>definition). See Figure C above. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>In addition each of the opes call out servers would then send > >>>>>billing and trace data back to the load balancer (or another network > >>>>>location). Is it realistic to expect that this could this be > >>>>>accomplished within the opes framework? > >>>>> > >>>>> > >>>>> > >>>>> > >>>>It is. The only question is what protocol(s) you will use between your > >>>>proxies (the curly lines in Figure C). > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>In fact a more fundamental question is the opes framework the best > >>>>>way to solve this problem and maintain an open system. I think this > >>>>>is what opes is all about. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>IMO, OPES framework accommodates, in principle, any intermediary > >>>>adaptation. Thus, your problem is within the framework. However, the > >>>>framework is not complete. It does not have ready-to-use tools for all > >>>>possible intermediary adaptations. I hope that you will find OCP Core > >>>>and OPES communications "tools" useful for your problems, but I lack > >>>>information to tell your whether they are the best. > >>>> > >>>>The system is "open" if it uses "open standards". If current OPES > >>>>tools are not right for you, and there are no better open tools, then > >>>>we can work together, within the OPES Framework, on defining open > >>>>standards (protocols and interfaces) that will solve your specific > >>>>problem. > >>>> > >>>>Alex. > >>>> > >>>> > >>>> > >>>> > >>>> > > > > > > > From tlhzhpuc@yahoo.com Sat Feb 28 17:52:25 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07503 for ; Sat, 28 Feb 2004 17:52:25 -0500 (EST) From: tlhzhpuc@yahoo.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxDJr-0003uu-00 for opes-archive@ietf.org; Sat, 28 Feb 2004 17:52:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxDIw-0003ox-00 for opes-archive@ietf.org; Sat, 28 Feb 2004 17:51:31 -0500 Received: from d14-69-187-98.try.wideopenwest.com ([69.14.98.187]) by ietf-mx with smtp (Exim 4.12) id 1AxDI0-0003id-00; Sat, 28 Feb 2004 17:50:33 -0500 Received: from 80.64.181.131 by 69.14.98.187; Sun, 29 Feb 2004 02:45:25 +0400 Message-ID: