From owner-ietf-openproxy@mail.imc.org Sat May 1 10:42:08 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 KAA21756 for ; Sat, 1 May 2004 10:42:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJvgu-0002OF-Ei for opes-archive@ietf.org; Sat, 01 May 2004 10:42:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJvfx-0002Cx-00 for opes-archive@ietf.org; Sat, 01 May 2004 10:41:10 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BJvfC-00021p-00 for opes-archive@ietf.org; Sat, 01 May 2004 10:40:22 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i41ETNqf061251; Sat, 1 May 2004 07:29:23 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i41ETNkT061250; Sat, 1 May 2004 07:29:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i41ETMnN061241 for ; Sat, 1 May 2004 07:29:22 -0700 (PDT) (envelope-from markus@mhof.com) Received: from mhof.com (pcp09456929pcs.eatntn01.nj.comcast.net[69.241.194.131]) by comcast.net (sccrmhc11) with ESMTP id <2004050114291701100nqnude> (Authid: biena2004); Sat, 1 May 2004 14:29:17 +0000 Message-ID: <4093B43F.1070606@mhof.com> Date: Sat, 01 May 2004 10:29:19 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.6a (Windows/20040420) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: IESG Feedback on OCP Core draft Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks, I believe attached message from Alex didn't make it to the mailing list. Please have a careful look - it's about feedback from IESG discussion of our OCP Core draft. Thanks, Markus ---------- Forwarded message ---------- Date: Thu, 29 Apr 2004 16:48:17 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: ID Tracker State Update Notice: draft-ietf-opes-ocp-core >> 'State Changes to IESG Evaluation::Revised ID Needed from IESG >> Evaluation by Amy Vezza' >> ID Tracker URL: >> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=10380&rfc_flag=0 There are two "discuss" items: 1) It isn't clear how encryption is turned on. I will need to polish the text to make it clear. I think the draft lost some of the text that explicitly covered that when security negotiation was put out of Core scope. 2) Opening for future feature extension is too big. The comment that follows this vague statement seems to be misinterpreting how the extension mechanism works. I will polish the text and supply a specific example to make the intent clear. I hope that will remove the "too big" objection. There was also a comment regarding lack of IANA registrations. I am guessing that the IANA-related text we discussed on this list (and with AD) after the draft was published did not make it to IESG. I will include that text into the next version of the draft. Please let me know if you have any other suggestions/ideas. Thanks, Alex. From qxvry@zworg.com Sat May 1 16:18:10 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 QAA23257 for ; Sat, 1 May 2004 16:18:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BK0w6-0005PX-De for opes-archive@ietf.org; Sat, 01 May 2004 16:18:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BK0vC-0005Eu-00 for opes-archive@ietf.org; Sat, 01 May 2004 16:17:15 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BK0us-00053m-00 for opes-archive@ietf.org; Sat, 01 May 2004 16:16:54 -0400 Received: from [139.142.95.208] (helo=YOUR-SZ6X6SEFXO) by mx2.foretec.com with smtp (Exim 4.24) id 1BK0us-0007fM-AB for opes-archive@ietf.org; Sat, 01 May 2004 16:16:54 -0400 X-Message-Info: 1cbu2jV/jzYvYWZdOlhzO476SEEnd Received: from solidus (140.95.25.88) by ln6.hydrodynamic.consequential.deletion.bright.net (InterMail vH.0.68.11.44 726-85186-71-66167-19-98228836) with ESMTP id <310284044.BSXA6189.fxnw5-mail.fuel.bantu.net.cable.rogers.com@proprioception> for ; Sat, 01 May 2004 18:12:43 -0300 Message-ID: <23710cjzrd7651blrkr$6209973ssu44$2qz710xkx0@repeater> Reply-To: "Jennie Bruner" From: "Jennie Bruner" To: Subject: Fwd: Have Medications Delivered Right To Your Door. Discreetly. Securely. Date: Sun, 02 May 2004 03:12:43 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--21696891808284826644" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.9 required=5.0 tests=BIZ_TLD,HTML_70_80, HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----21696891808284826644 Content-Type: text/html; Content-Transfer-Encoding: 7Bit
Ultram
Vlagra
Phentermlne
Soma
Amblen
Valium
Cialls
Xanax
Get over 300 medicatlons online shlpped overnight to your front door with no prescrlption.
   *  No Prescriptlon Needed
   *  Fully Confidential
   *  No Embarrassment
   *  No Waiting Rooms
   *  Shipped Overnight
   *  Discreet Packaging

Jbaldwin scala betelgeuse pulsar gillette shoelace arlene landlord ciceronian gibby conclave addressee huge pyongyang recuse floodlight ? Qgratify mix horseflesh parabolic kiev bryophyta addis atmospheric perspective ask roosevelt sandwich ; Uzoo oersted hadn't bemuse whelan telephone consequent szilard algebra workforce aspidistra radix periwinkle amoebae dade absorptive deregulatory boss bless applicate anastigmat lectern disparage allocate brevet gage nimble cordial aspersion allegation vend wapiti phonemic bilk boucher stratford delightful avow indicate contemptible .Zafraid barrette ektachrome ashore jam barefaced ! Nblatant planoconcave trw coolant bat alongside err chronicle forest embryology lot august !!! Tradian northernmost homesick pistol snoop deportation hallmark augustan cargill chiton isotopic aide projector clammy alpine chauncey plastron accelerate horsedom bahrein boundary cash danielson digging welfare gracious pyle reminisce thereabouts ecology landfill jan moore polonaise runyon crept cherish dishwasher decree attributive atreus connubial asia helium pearlite Ptyphoon highball earnest fluoridate flute drury periwinkle both corey aft thresh dna interviewee mystique buzz covariant til carne : Uejaculate bladdernut campanile juxtaposition barkeep dissemble imputation brett ian pluck bernhard hyphenate long clod gagging prostheses bassi . Fberibbon nickel propellant awn evildoer harness immodest discernible bela dnieper nicholas technology cynic bailey burton repent sourdough anonymity infidel malcolm tortuous benson valerie archive fragrant batten buckley perceptive boatmen bonus guildhall charta occupy viva contract sparkman burbank popcorn alphameric compass gnash maintenance skywave coors sorrow dock civil .

If this notice has reached you in error, please notify us by clicking here ----21696891808284826644-- From DYVAI@csf.com.br Sat May 1 16:49:19 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 QAA24234 for ; Sat, 1 May 2004 16:49:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BK1QF-0003dP-Em for opes-archive@ietf.org; Sat, 01 May 2004 16:49:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BK1PF-0003Qy-00 for opes-archive@ietf.org; Sat, 01 May 2004 16:48:18 -0400 Received: from c-24-15-61-156.client.comcast.net ([24.15.61.156]) by ietf-mx with smtp (Exim 4.12) id 1BK1OT-0003FF-00 for opes-archive@ietf.org; Sat, 01 May 2004 16:47:29 -0400 Received: from 242.0.24.128 by 24.15.61.156; Sun, 02 May 2004 00:44:27 +0300 Message-ID: From: "Lesa Hale" Reply-To: "Lesa Hale" To: opes-archive@ietf.org Subject: employers don't hire people without degrees, buy yours today Date: Sat, 01 May 2004 18:43:27 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--065158106469514" X-Originating-IP: 132.151.6.1 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.0 required=5.0 tests=HTML_50_60, HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY,LINES_OF_YELLING,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,OBFUSCATING_COMMENT autolearn=no version=2.60 X-Spam-Report: * 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.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.2 HTML_50_60 BODY: Message is 50% to 60% HTML * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 4.3 OBFUSCATING_COMMENT HTML comments which obfuscate text ----065158106469514 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable GET

 

spiegel domingo swathe tarantara legend d= elicti capybara artistry circumspect myeloid byroad adjourn armpit cochran= fathom operand airmass coachman macrame xylem dilemma lesotho collaborate= contradistinguish dan sustenance middle=20gibbous hillcrest naivete curse gilligan= deign valley afferent irresponsible decontrol caryatid hispanic=20pyrolyse adjective microjoule debonair saxo= ny bryant campion legion correspondent handicapped virginia dodecahedral l= undberg=20decennial baffle bomb sandbag bergman bor= ax hate dross catlike brookline penicillin steam tomography quo celsius ka= towice sole orient glamor billow=20invocate utica bounce fibonacci cramer s= purn apology didn't lavish else investigatory persuasion browse accompanis= t purview nakayama silage demon eerily banister mccluskey teaspoonful will= s chatham porous reginald rookie=20 ----065158106469514-- From mucht@xtcradio.com Sun May 2 01:51:31 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 BAA14125 for ; Sun, 2 May 2004 01:51:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BK9sw-0006Lr-Gr for opes-archive@ietf.org; Sun, 02 May 2004 01:51:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BK9rx-000680-00 for opes-archive@ietf.org; Sun, 02 May 2004 01:50:30 -0400 Received: from adsl-209-30-158-234.dsl.rcsntx.swbell.net ([209.30.158.234]) by ietf-mx with smtp (Exim 4.12) id 1BK9qz-0005ji-00 for opes-archive@ietf.org; Sun, 02 May 2004 01:49:30 -0400 Message-ID: <36969040008928688167.9404q4w@another.com> Received: from 76.177.24.48 by qh474-nq91.apmze113.another.com with DAV; Sun, 02 May 2004 05:45:23 -0100 Reply-To: "Darnell Cooley" From: "Darnell Cooley" To: Subject: Re: Your "Cialis" refill is now ready Date: Sat, 01 May 2004 23:45:23 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--382978029708600139" 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=BIZ_TLD,CLICK_BELOW,HTML_60_70, HTML_FONTCOLOR_GREEN,HTML_FONTCOLOR_UNSAFE,HTML_IMAGE_ONLY_12, HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, MSGID_FROM_MTA_HEADER autolearn=no version=2.60 ----382978029708600139 Content-Type: text/html; Content-Transfer-Encoding: 7Bit

An FDA approved impotence drug developed by Eli Lilly and Co. and Icos Corp. appears to be longer-lasting than Viagra, the companies said, citing a study being released at a medical conference. Patients in the study reported success in achieving erections over a period of 24 to 36 hours after taking a 20-milligram pill of Cialis, said Indianapolis-based Lilly and Bothell, Wash.-based Icos on Saturday.

It's a new prescription drug called Cialis. Researchers claim it works twice as fast as Viagra with fewer side effects. In clinical studies Cialis helped 88 percent of men to achieve erections in 30 minutes or less. The study also showed that Cialis continued to stay in the system for up to 24 hours!

GET YOUR UNIVERSITY DIPLOMA

Do yo= u want a prosperou= s future, increased earning power
more money and the respect of all?

Ca<= !b>ll this number: 

1-212-714-8290

(24 hours)

 

  • There are no required tests, classes, books, or= interviews!
     
  • Get a Bachelors, Ma<= !d>sters, MBA, and Doctorate (PhD) diploma!
     
  • Receive the benefits and admiration that comes= with a diploma!
     
  • No one is turned= down!

     

    Call Today

    =

    1-212-714-8290



    Confidentiality assured!
     

     cafeteria fly seismic fjord divisible = claudia downdraft us polecat tidbit=20 anthropomorphic aeneas hardboiled celtic s= eersucker dairymen vivify jackdaw albeit negligent consequent forgive cond= ensate scramble trafficking haughty mica clandestine connector besotted so= lace contrite nazareth treadle brake glen unanimous lowe cuckoo thereupon = spite cortical emigrate homeomorph ladyfern ombudsperson schoolhouse shutt= lecock=20

    W= e are located in USA  international= callers are very welcome

    •



    3 Cialis 20mg $ 127.00
    3 Viagra 100mg $ 123.00
    3 Levitra 20mg $ 123.00


    Click Here for more info...

    Rbreve desiderata chauffeur hijinks epigram sachs sabotage philosoph . Xamiss farad stuffy bookend chisel subjectivity colosseum edgar iniquitous widen gaul mecca holden incarnate antiperspirant johns electra qualitative . Fpreamble poseur abusable cobb connotation gimmickry bien combatant odd credential insecticide brandon calla cleat polemic biopsy potpourri o kirkpatrick tilt amplify delineament privacy wingtip cheesecake lowell riot chanson terrific sinh

    If this notice has reached you in error, please notify us by clicking here ----382978029708600139-- From Rosejoco84@netscape.net Sun May 2 08:05:53 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 IAA11621 for ; Sun, 2 May 2004 08:05:53 -0400 (EDT) From: Rosejoco84@netscape.net Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKFjF-0006OJ-IC for opes-archive@ietf.org; Sun, 02 May 2004 08:05:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKFiK-0006AJ-00 for opes-archive@ietf.org; Sun, 02 May 2004 08:04:57 -0400 Received: from [200.78.206.193] (helo=netscape.net) by ietf-mx with smtp (Exim 4.12) id 1BKFi2-0005w5-00 for opes-archive@ietf.org; Sun, 02 May 2004 08:04:39 -0400 To: opes-archive@ietf.org Subject: Urgent Appeal For Assistance X-Priority: 3 Message-Id: Date: Sun, 02 May 2004 08:04:39 -0400 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=7.9 required=5.0 tests=DEAR_FRIEND,FROM_ENDS_IN_NUMS, LINES_OF_YELLING,LINES_OF_YELLING_2,MSGID_FROM_MTA_SHORT,NO_REAL_NAME, PRIORITY_NO_NAME,UPPERCASE_75_100,URGENT_BIZ,US_DOLLARS_3 autolearn=no version=2.60 X-Spam-Report: * 0.3 NO_REAL_NAME From: does not include a real name * 0.9 FROM_ENDS_IN_NUMS From: ends in numbers * 0.8 URGENT_BIZ BODY: Contains urgent matter * 1.1 DEAR_FRIEND BODY: Dear Friend? That's not very dear! * 0.6 US_DOLLARS_3 BODY: Mentions millions of $ ($NN,NNN,NNN.NN) * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 LINES_OF_YELLING_2 BODY: 2 WHOLE LINES OF YELLING DETECTED * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 0.0 UPPERCASE_75_100 message body is 75-100% uppercase * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer DEAR FRIEND, I AM MR. JOHN COLEMAN AND MY SISTER IS MISS ROSE COLEMAN, WE ARE THE CHILDREN OF LATE CHIEF PAUL COLEMAN FROM SIERRA LEONE. I AM WRITING YOU IN ABSOLUTE CONFIDENCE PRIMARILY TO SEEK YOUR ASSISTANCE TO TRANSFER OUR CASH OF TWENTY ONE MILLION DOLLARS($21,000,000.00) NOW IN COSTUDY OF A PRIVATE SECURITY FIRM IN EUROPE .THE MONEY IS IN TWO TRUNK BOXES DEPOSITED AND DECLARED AS FAMILY VALUABLES BY MY LATE FATHER. AS A MATTER OF FACT THE COMPANY DOES NOT KNOW THE CONTENT AS MONEY, ALTHOUGH MY FATHER MADE THEM UNDERSTAND THAT THE BOXES BELONG TO HIS FOREIGN PARTNER. SOURCE OF THE MONEY: MY LATE FATHER,CHIEF PAUL COLEMAN,A NATIVE OF MENDE DESTRICT IN NORTHERN SIERRA LEONE,WAS THE GENERAL MANAGER OF SIERRA LEONE MINNING COOPERATION(S.L.M.C)FREETOWN.ACCORDING TO MY FATHER,THIS MONEY WAS THE INCOME ACCRUED FROM THE MINNING COOPERATION’S OVERDRAFT AND MINOR SALES. BEFORE THE PEAK OF THE CIVIL WAR BETWEEN THE REBEL FORCES OF MAJOR PAUL KOROMA AND THE COMBINED FORCES OF “ECOMOG” PEACE KEEPING OPERATION THAT ALMOST DESTROYED MY COUNTRY, FOLLOWING THE FORCES REMOVAL FROM POWER THE ELECTED CIVILIAN PRESIDENT AHMED TEJAN KABBAH BY THE REBELS. MY FATHER HAD ALREADY MADE ARRANGEMENT FOR HIS FAMILY ,THAT IS ME, MY JUNIOR SISTER AND MY MOTHER,TO BE EVACUATED TO THE NETHERLANDS(HOLLAND),THRUOGH THE AID OF THE U.N EVACUATION TEAM, WITH THE CERTIFICATE OF DEPOSIT HE MADE WITH THE SECURITY COMPANY. DURING THE CIVIL WAR IN MY COUNTRY,AND FOLLOWING THE INDICSRIMINATE LOOTING OF GOVERNMENT AND PUBLIC PROPERTIES BY THE REBEL FORCES,THE SIERRA LEONE MINING COOPERATION WAS ONE OF THE TARGETS LOOTED AND DESTROYED.MY FATHER AND SOME OTHER TOP GOVERNMENT FUNCTIONARIES WERE ATTACKED AND LILLED BY THE REBELS IN NOVEMBER 2000 BECAUSE OF HIS RELATIOSHIP WITH THE CIVILIAN GOVERNMENT OF AHMED TEJAN KABBAH AS A RESULT OF MY FATHER’S DEATH,AND WITH THE NEWS OF MY UNCLE’S INVOLEMENT IN A PLANE CRASH IN JANUARY IT DASHED OUR HOPE OF SURVIVAL.THESE BAD NEWS RESULTED TO MY MOTHER’S HEART FAILURE AND COMPLICATIONS LATER LEAD TO HER DEATH. I AND MY 18YEAR OLD SISTER ARE NOW LEFT ALONE IN THIS STRANGE LAND.WE ARE NOT ONLY REFUGEES ,BUT, OPHANS From cjugdyyiuxxmef@yahoo.com Mon May 3 01: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 BAA24185 for ; Mon, 3 May 2004 01:41:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKWCe-0006cL-9n for opes-archive@ietf.org; Mon, 03 May 2004 01:41:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKW9l-00068a-00 for opes-archive@ietf.org; Mon, 03 May 2004 01:38:22 -0400 Received: from yahoobb218131180019.bbtec.net ([218.131.180.19]) by ietf-mx with smtp (Exim 4.12) id 1BKW6k-0005Wa-00 for opes-archive@ietf.org; Mon, 03 May 2004 01:35:15 -0400 Received: from 175.26.188.76 by 218.131.180.19; Mon, 03 May 2004 04:31:04 -0200 Message-ID: From: "Isabelle Dolan" Reply-To: "Isabelle Dolan" To: opes-archive@ietf.org Subject: ending with a closer look at one of these hybrids Date: Mon, 03 May 2004 11:27:04 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--759268509492412923924120286111197" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.7 required=5.0 tests=FORGED_YAHOO_RCVD, HTML_FONTCOLOR_UNKNOWN,HTML_IMAGE_ONLY_02,HTML_MESSAGE, HTML_TITLE_UNTITLED,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----759268509492412923924120286111197 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Untitled Document = Artificial Life ----759268509492412923924120286111197-- From flxushsx@sy163.net Tue May 4 00:27:10 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 AAA23146 for ; Tue, 4 May 2004 00:27:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKrWS-0007JS-0q for opes-archive@ietf.org; Tue, 04 May 2004 00:27:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKrVS-0007B8-00 for opes-archive@ietf.org; Tue, 04 May 2004 00:26:11 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BKrUb-00072O-00 for opes-archive@ietf.org; Tue, 04 May 2004 00:25:17 -0400 Received: from c61154.upc-c.chello.nl ([212.187.61.154]) by mx2.foretec.com with smtp (Exim 4.24) id 1BKrUa-0008EY-PT for opes-archive@ietf.org; Tue, 04 May 2004 00:25:18 -0400 X-Message-Info: CvbcLN5tytIsAAJjwr29b5UCA35EArxhEYMx Received: from otx4.emailgaul.com (224.206.80.142) by qf42-s.emailgaul.com with Microsoft SMTPSVC(5.0.2195.6824); Tue, 04 May 2004 01:22:01 -0400 Received: from concurringq3 (angelica0.204.67.4) by emailgaul.com (to19) with SMTP id <54785xb24h> (Authid: MikeCahill); Mon, 03 May 2004 23:21:01 -0600 From: "Simon Starnes" To: "'Opes-archive'" Subject: Re: Your "Cialis" refill is now ready Date: Mon, 03 May 2004 23:19:01 -0600 Message-ID: <587yu405ccz275$01qy706lrq824$91qe8wmz@canterelleanarchiwb37> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--0473887205801869" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.4 required=5.0 tests=BIZ_TLD,CLICK_BELOW,HTML_40_50, HTML_FONTCOLOR_GREEN,HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----0473887205801869 Content-Type: text/html; Content-Transfer-Encoding: 7Bit

    Cialis

    An FDA approved impotence drug developed by Eli Lilly and Co. and Icos Corp. appears to be longer-lasting than Viagra, the companies said, citing a study being released at a medical conference. Patients in the study reported success in achieving erections over a period of 24 to 36 hours after taking a 20-milligram pill of Cialis, said Indianapolis-based Lilly and Bothell, Wash.-based Icos on Saturday.

    It's a new prescription drug called Cialis. Researchers claim it works twice as fast as Viagra with fewer side effects. In clinical studies Cialis helped 88 percent of men to achieve erections in 30 minutes or less. The study also showed that Cialis continued to stay in the system for up to 24 hours!


    Click Here for more info...

    More info about Cialis

    • Works 32 hours longer than Viagra!
    • Cialis is 50% more effective!
    • Causes fewer side effects!
    • Treats male impotence more effectively!
    • Achieve erection 50% faster.

    Order Cialis by CLICKING HERE

    Wexcruciate ineradicable lakehurst rufus shinbone aphasic hyades waybill drawl ingratitude turbid glossary paralysis seven electrician !!! Xheresy inward ayers directrices pusey indelicate : Ihay dandelion anchorage wraith amplitude popcorn asteroid thread ornate bayou split nasa censor Qconsulate debauch synaptic calais debunk sen club dempsey domingo banach dachshund jacobus trendy chip : Jbelch vinegar withdraw plight sage sob breezy forthright polytypy carrara umlaut invoke erich alumina gunmen stillwater arpa detonable tulsa catalytic annalen stewardess galatia lithospheric venal naacp contention collarbone deduct gigawatt kieffer !!! Xcotillion conscription someday succession texaco bhutan altruist mildew metaphoric barren rica charitable lint chungking ghetto snoopy bauhaus reynolds coliform vane poke musician dixie like sisyphean compulsory hooligan gemma concept sheaf wert quasiorder covalent cotoneaster leadsman .Vbrigadier emancipate dutiful cease surrey celery liberty dickerson benthic boletus stymie !! Qcormorant dragoon roomy coastal solemn arrhenius beauteous cargo puissant . Aursuline stolen beg fastidious chigger laissez bygone couscous annoyance stallion savoyard bergen indiscriminate shopworn prep dummy casein manhood elijah rage abrasion arrogate chrysolite stadia calfskin chevrolet outermost bell dave recovery priscilla duopoly ambulatory citizen skyward borrow

    If this notice has reached you in error, please notify us by clicking here ----0473887205801869-- From owner-ietf-openproxy@mail.imc.org Tue May 4 15:28:44 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 PAA24095 for ; Tue, 4 May 2004 15:28:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL5av-0004AO-B8 for opes-archive@ietf.org; Tue, 04 May 2004 15:28:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL5a6-00044g-00 for opes-archive@ietf.org; Tue, 04 May 2004 15:27:54 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BL5ZC-0003yY-00 for opes-archive@ietf.org; Tue, 04 May 2004 15:26:58 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i44JHYWK027256; Tue, 4 May 2004 12:17:34 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i44JHYjj027255; Tue, 4 May 2004 12:17:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i44JHXvK027249 for ; Tue, 4 May 2004 12:17:33 -0700 (PDT) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i44JHbeY048073; Tue, 4 May 2004 15:17:37 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i44JHVjI063542; Tue, 4 May 2004 15:17:31 -0400 (EDT) Received: from [135.180.160.86] (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i44JHVEi021175; Tue, 4 May 2004 15:17:31 -0400 (EDT) Message-ID: <4097EC4B.6060209@mhof.com> Date: Tue, 04 May 2004 15:17:31 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES WG CC: Alex Rousskov Subject: Re: ID Tracker State Update Notice: draft-ietf-opes-ocp-core References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Alex, > I would like to publish it in hope to close IESG discussion items. > Please let me know if you have any other suggestions/ideas. Please do so. Copy me when you submit the modified version for publication, so that we can also notify the AD on the updated version. Thanks, Markus From owner-ietf-openproxy@mail.imc.org Tue May 4 15:28: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 PAA24113 for ; Tue, 4 May 2004 15:28:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL5aw-0004Ac-NJ for opes-archive@ietf.org; Tue, 04 May 2004 15:28:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL5a7-00044u-00 for opes-archive@ietf.org; Tue, 04 May 2004 15:27:56 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BL5ZD-0003yi-00 for opes-archive@ietf.org; Tue, 04 May 2004 15:26:59 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i44JCkVZ026030; Tue, 4 May 2004 12:12:47 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i44JCk7O026029; Tue, 4 May 2004 12:12:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i44JCi6I026017 for ; Tue, 4 May 2004 12:12:45 -0700 (PDT) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i44JClhl060135 for ; Tue, 4 May 2004 15:12:47 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i44JCgjI063186 for ; Tue, 4 May 2004 15:12:42 -0400 (EDT) Received: from [135.180.160.86] (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i44JCgEi020995 for ; Tue, 4 May 2004 15:12:42 -0400 (EDT) Message-ID: <4097EB2A.5040808@mhof.com> Date: Tue, 04 May 2004 15:12:42 -0400 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: [Fwd: Re: ID Tracker State Update Notice: draft-ietf-opes-ocp-core] Content-Type: multipart/mixed; boundary="------------000903000901070200090205" 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=none autolearn=no version=2.60 This is a multi-part message in MIME format. --------------000903000901070200090205 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Forward, since Alex original email seems to not have gone through... -Markus --------------000903000901070200090205 Content-Type: message/rfc822; name="Re: ID Tracker State Update Notice: draft-ietf-opes-ocp-core" Content-Disposition: inline; filename="Re: ID Tracker State Update Notice: draft-ietf-opes-ocp-core" Return-Path: Received: from frontend2.messagingengine.com (frontend2.internal [10.202.2.151]) by server2.fastmail.fm (Cyrus v2.2.3) with LMTP; Tue, 04 May 2004 02:40:33 -0400 X-Sieve: CMU Sieve 2.2 X-Spam-score: 0.0 X-Spam-hits: BAYES_00, OFFER X-Resolved-to: hofmann@fastmail.fm X-Delivered-to: markus@mhof.com X-Mail-from: rousskov@measurement-factory.com Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by smtp.us.messagingengine.com (Postfix) with ESMTP id 294BD402EBA for ; Tue, 4 May 2004 02:40:28 -0400 (EDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i446eOuH013382; Tue, 4 May 2004 00:40:25 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i446eE2J013380; Tue, 4 May 2004 00:40:14 -0600 (MDT) (envelope-from rousskov) Date: Tue, 4 May 2004 00:40:14 -0600 (MDT) From: Alex Rousskov To: OPES WG Cc: Markus Hofmann Subject: Re: ID Tracker State Update Notice: draft-ietf-opes-ocp-core In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 29 Apr 2004, Alex Rousskov wrote: > > 'State Changes to IESG Evaluation::Revised ID Needed from IESG > > Evaluation by Amy Vezza' > > ID Tracker URL: > > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=10380&rfc_flag=0 > > There are two "discuss" items: > > 1) It isn't clear how encryption is turned on. > > I will need to polish the text to make it clear. I think the draft > lost some of the text that explicitly covered that when > security negotiation was put out of Core scope. Done. I have polished/added the following paragraphs and changed the negotiation example: 6. Negotiation ... Two core negotiation primitives are supported: negotiation offer and negotiation response. A Negotiation Offer (NO) message allows an agent to specify a set of features from which the responder has to select at most one feature it prefers. The selection is sent using a Negotiation Response (NR) message. If the response is positive, both sides assume that the selected feature is in effect immediately (see Section 11.19 for details). If the response is negative, no behavioral changes are assumed. In either case, further offers may follow. ... The following example shows a dialog with a callout server that insists on two imaginary features to be used: strong transport encryption and use of volatile storage for responses. The server is designed to exchange no sensitive messages until both features are enabled. Naturally, the volatile storage feature has to be negotiated securely. The OPES processor supports one of the strong encryption mechanisms but prefers not to offer (volunteer support for) strong encryption, perhaps for performance reasons. The server has to send a true "Offer-Pending" parameter to get a chance to offer strong encryption (which is successfully negotiated in this case). Any messages sent by either agent after the (only) successful NR response are encrypted with "strongB" encryption scheme. The OPES processor does not understand the volatile storage feature, and the last negotiation fails (over an strongly encrypted transport connection). P: NO ({"29:ocp://example/encryption/weak"}) ; S: NR Offer-Pending: true ; S: NO ({"32:ocp://example/encryption/strongA"},\ {"32:ocp://example/encryption/strongB"}) Offer-Pending: true ; P: NR {"32:ocp://example/encryption/strongB"} ; ... all traffic below is encrypted using strongB ... S: NO ({"31:ocp://example/storage/volatile"}) Offer-Pending: false ; P: NR Unknowns: ({"31:ocp://example/storage/volatile"}) ; S: CSE { 400 "33:lack of VolStore protocol support" } ; ... 11.19 Negotiation Response (NR) ... The successfully negotiated feature becomes effective immediately: The sender of a positive response MUST consider the corresponding feature enabled immediately after the response is sent; the recipient of a positive response MUST consider the corresponding feature enabled immediately after the response is received. Note that the scope of the negotiated feature application may be limited to a specified service group. The negotiation phase state does not affect enabling of the feature. > 2) Opening for future feature extension is too big. > > The comment that follows this vague statement seems to be > misinterpreting how the extension mechanism works. I will > polish the text and supply a specific example to make the > intent clear. I hope that will remove the "too big" > objection. Done. Here is the polished text: 15.1 Adapting OCP Core OCP extensions MAY change any normative requirement documented in this specification, including OCP message syntax, except for the following rule: OCP extensions MUST require that changes to normative parts of OCP Core are negotiated prior to taking effect. In other words, this specification defines compliant agent behavior until changes to this specifications (if any) are successfully negotiated. For example, if an RTSP profile for OCP requires support for sizes exceeding 2147483647 octets, the profile specification can document appropriate OCP message syntax and semantics changes while requiring that RTSP adaptation agents negotiate "large size" support before using large sizes. Such negotiation can be bundled with negotiating another feature (e.g., negotiating an RTSP profile may imply support for large sizes). As implied by the above rule, OCP extensions may dynamically alter the negotiation mechanism itself. Such an alternation would have to be negotiated first, using the negotiation mechanism defined by this specification. For example, successfully negotiating a feature might change the default "Offer-Pending" value from false to true. > There was also a comment regarding lack of IANA registrations. I am > guessing that the IANA-related text we discussed on this list (and > with AD) after the draft was published did not make it to IESG. I will > include that text into the next version of the draft. Done. The entire updated draft is available at http://www.measurement-factory.com/tmp/opes/ I would like to publish it in hope to close IESG discussion items. Please let me know if you have any other suggestions/ideas. Thanks, Alex. --------------000903000901070200090205-- From owner-ietf-openproxy@mail.imc.org Tue May 4 16:19:11 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 QAB26773 for ; Tue, 4 May 2004 16:19:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL6Nk-0002FV-QW for opes-archive@ietf.org; Tue, 04 May 2004 16:19:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL6Mq-00027U-00 for opes-archive@ietf.org; Tue, 04 May 2004 16:18:17 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BL6MH-0001yM-00 for opes-archive@ietf.org; Tue, 04 May 2004 16:17:41 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i44K5W9p037724; Tue, 4 May 2004 13:05:32 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i44K5WpJ037723; Tue, 4 May 2004 13:05:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail.radioburst.com (mail.esmartstart.com [66.119.143.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i44K5VKq037716 for ; Tue, 4 May 2004 13:05:31 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (dav.rfburst.com [209.90.91.153]) by mail.radioburst.com (8.12.8/8.12.8) with ESMTP id i44K5MYv023213 for ; Tue, 4 May 2004 14:05:28 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.8/8.11.6) with ESMTP id i44K55HK025027 for ; Tue, 4 May 2004 14:05:05 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i44K55Se025023; Tue, 4 May 2004 14:05:05 -0600 Date: Tue, 4 May 2004 14:05:05 -0600 Message-Id: <200405042005.i44K55Se025023@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: ietf-openproxy@imc.org In-reply-to: Yourmessage <4097EB2A.5040808@mhof.com> Subject: Re: [Fwd: Re: ID Tracker State Update Notice: draft-ietf-opes-ocp-core] X-esmartscan-MailScanner: Found to be clean 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 It's fairly tricky to negotiate cryptographic protection. For the encryption negotiation, I don't see how the transport gets switched from encrypted to non-encrypted in mid-stream. How can you switch from a non-SSL connection to an SSL connection during negotiation, for example? Wouldn't you have to start all over again, repeating everything that led up to the discovery that the two sides needed a particular protection suite? Do they also negotiate the authentication requirements? The closest I'd seen to any discussion of this was early on, and the notion was that if you were already using SSL you might decide during negotiation that the transport had already established a sufficient degree of security and accept it. What of that case? I think that the IESG may take issue with the idea that the extensions can change anything, including the syntax. It would seem difficult to analyze an implementation for correctness given such wide latitude in dynamic behavior. Hilarie From owner-ietf-openproxy@mail.imc.org Tue May 4 18:33:00 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 SAA04599 for ; Tue, 4 May 2004 18:33:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL8TF-0002Wk-OA for opes-archive@ietf.org; Tue, 04 May 2004 18:33:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL8SM-0002QM-00 for opes-archive@ietf.org; Tue, 04 May 2004 18:32:06 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BL8S1-0002Iu-00 for opes-archive@ietf.org; Tue, 04 May 2004 18:31:45 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i44MLSMH061142; Tue, 4 May 2004 15:21:29 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i44MLSKO061141; Tue, 4 May 2004 15:21:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i44MLRdg061133 for ; Tue, 4 May 2004 15:21:28 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i44MLWuH050696 for ; Tue, 4 May 2004 16:21:32 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i44MLWbT050695; Tue, 4 May 2004 16:21:32 -0600 (MDT) (envelope-from rousskov) Date: Tue, 4 May 2004 16:21:32 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: Re: [Fwd: Re: ID Tracker State Update Notice: draft-ietf-opes-ocp-core] 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 The Purple Streak, Hilarie Orman wrote: > It's fairly tricky to negotiate cryptographic protection. Yes. Fortunately, there are known solutions, and we do not have to reinvent the wheel :-). > How can you switch from a non-SSL connection to an SSL connection > during negotiation, for example? See negotiation examples in OCP Core (the current snapshot) for an example. This kind of switch is pretty standard. All HTTP CONNECT transactions use it. You simply start encrypting after you send/receive an un-encrypted response to un-encrypted CONNECT (accepted negotiation offer in our case). > Wouldn't you have to start all over again, repeating everything that > led up to the discovery that the two sides needed a particular > protection suite? It's an option. Usually, it is recommended that encryption negotiation happens first, but it does not have to be that way if parties do not care if a previous traffic is not encrypted. If/when we document encryption for OCP, we should RECOMMEND that it happens first, IMO. We do not document a way to do a switch from encrypted to unencrypted connection, but I believe such a switch is technically possible. If you look at SSL library, for example, it has an interface that is 100% independent from the notion of a "transport connection". It is simply an encryption of a [portion of a] dialog. You feed it an unencrypted buffer, you get an encrypted buffer (or request for more data) back. > Do they also negotiate the authentication requirements? Optionally, and probably after they negotiate and establish encrypted transport medium. > if you were already using SSL you might decide during negotiation > that the transport had already established a sufficient degree of > security and accept it. What of that case? If I understand the question correctly, agents would simply not negotiate encryption is the case of already established and satisfactory encryption for the connection they use. Recall that OCP does not require connections to be encrypted. It makes it possible for any party to insist on encryption (or terminate the connection). > I think that the IESG may take issue with the idea that the > extensions can change anything, including the syntax. We only need to convince a single person who actually seemed to misinterpret the (now-polished) text. I would give it a shot. Do you object? > It would seem difficult to analyze an implementation for correctness > given such wide latitude in dynamic behavior. Agreed. It would be even more difficult to predict all profile needs for OCP profiles we do not even know about at this time. The intent here is to give those profiles enough flexibility while counting on their good faith approach. I do not expect IETF standard-track OCP profiles to seriously alter OCP Core, but minor modifications may be essential. A better argument might be that it makes writing pure OCP Core proxies impossible. Perhaps that's a good thing though? Is there any value of a pure OCP Core proxy? Can it do anything that a TCP proxy cannot? We can put syntax out of scope if that makes any difference, but I am not sure it does. Alex. From owner-ietf-openproxy@mail.imc.org Wed May 5 02:03:18 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 CAA28406 for ; Wed, 5 May 2004 02:03:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLFUz-0003Xn-61 for opes-archive@ietf.org; Wed, 05 May 2004 02:03:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLFU9-0003OH-00 for opes-archive@ietf.org; Wed, 05 May 2004 02:02:26 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BLFTY-0003EQ-00 for opes-archive@ietf.org; Wed, 05 May 2004 02:01:48 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i455rJaI088010; Tue, 4 May 2004 22:53:19 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i455rJ4l088008; Tue, 4 May 2004 22:53:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail.radioburst.com (mail.esmartstart.com [66.119.143.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i455rIwD087988 for ; Tue, 4 May 2004 22:53:18 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (dav.rfburst.com [209.90.91.153]) by mail.radioburst.com (8.12.8/8.12.8) with ESMTP id i455rIYv018721; Tue, 4 May 2004 23:53:19 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.8/8.11.6) with ESMTP id i455r0HK005503; Tue, 4 May 2004 23:53:00 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i455qxZJ005499; Tue, 4 May 2004 23:52:59 -0600 Date: Tue, 4 May 2004 23:52:59 -0600 Message-Id: <200405050552.i455qxZJ005499@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: rousskov@measurement-factory.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage Subject: Re: [Fwd: Re: ID Tracker State Update Notice: draft-ietf-opes-ocp-core] X-esmartscan-MailScanner: Found to be clean 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 I think that the proposed amplification will become an IESG target that will hold up the document. What requirement is being satisfied by introducing a discussion of encryption negotiation? I'd much prefer to simply say that if you require confidentiality you must be using a secure transport before beginning any OCP negotiations. I think that what the document is trying to say is that if there's some support for encryption in the underlying protocol, then OCP has support for turning it on, however meaningless it may be. But what about authentication, what about integrity? I think there must be some discussion of integrity and authentication in the main body, and there must be more explication in security considerations. Particularly, having opened this can of worms, the document should at least note that a thorough analysis of security is needed for any particular OCP mapping. How do these HTTP CONNECT transactions determine a key to use for their encryption, how do they represent encrypted data? Unless there is a prior basis for authentication and integrity, it doesn't make sense to start encrypting and then establish authentication. etc. Hilarie From owner-ietf-openproxy@mail.imc.org Wed May 5 02:04: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 CAA29429 for ; Wed, 5 May 2004 02:04:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLFVt-0003hw-Mf for opes-archive@ietf.org; Wed, 05 May 2004 02:04:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLFV1-0003Y5-00 for opes-archive@ietf.org; Wed, 05 May 2004 02:03:19 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BLFUK-0003OX-00 for opes-archive@ietf.org; Wed, 05 May 2004 02:02:36 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i455t5pD089514; Tue, 4 May 2004 22:55:05 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i455t53H089513; Tue, 4 May 2004 22:55:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail.radioburst.com (mail.esmartstart.com [66.119.143.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i455t4vY089499 for ; Tue, 4 May 2004 22:55:04 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (dav.rfburst.com [209.90.91.153]) by mail.radioburst.com (8.12.8/8.12.8) with ESMTP id i455t2Yv018926; Tue, 4 May 2004 23:55:02 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.8/8.11.6) with ESMTP id i455soHK005543; Tue, 4 May 2004 23:54:50 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i455soFv005539; Tue, 4 May 2004 23:54:50 -0600 Date: Tue, 4 May 2004 23:54:50 -0600 Message-Id: <200405050554.i455soFv005539@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: rousskov@measurement-factory.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage Subject: Re: [Fwd: Re: ID Tracker State Update Notice: draft-ietf-opes-ocp-core] X-esmartscan-MailScanner: Found to be clean 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 Putting the syntax out of scope would be a very good idea. Hilarie From owner-ietf-openproxy@mail.imc.org Wed May 5 02:48:13 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 CAA24967 for ; Wed, 5 May 2004 02:48:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLGCS-0003fM-I3 for opes-archive@ietf.org; Wed, 05 May 2004 02:48:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLGBT-0003Uy-00 for opes-archive@ietf.org; Wed, 05 May 2004 02:47:12 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BLGAU-0003D7-00 for opes-archive@ietf.org; Wed, 05 May 2004 02:46:10 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i456crqa015578; Tue, 4 May 2004 23:38:53 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i456crY7015577; Tue, 4 May 2004 23:38:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i456cq9w015566 for ; Tue, 4 May 2004 23:38:52 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i456couH073699; Wed, 5 May 2004 00:38:50 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i456cocS073698; Wed, 5 May 2004 00:38:50 -0600 (MDT) (envelope-from rousskov) Date: Wed, 5 May 2004 00:38:50 -0600 (MDT) From: Alex Rousskov To: "The Purple Streak, Hilarie Orman" cc: ietf-openproxy@imc.org Subject: Re: [Fwd: Re: ID Tracker State Update Notice: draft-ietf-opes-ocp-core] In-Reply-To: <200405050552.i455qxZJ005499@localhost.localdomain> Message-ID: References: <200405050552.i455qxZJ005499@localhost.localdomain> 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 Tue, 4 May 2004, The Purple Streak, Hilarie Orman wrote: > I think that the proposed amplification will become an IESG target > that will hold up the document. What do you mean by "proposed amplification"? We already know the two "IESG targets", which the current revision is trying to address. Unless Bill Fenner ads more DISCUSS items, we know what we need to address. https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1201&filename=draft-ietf-opes-ocp-core > What requirement is being satisfied by introducing a discussion of > encryption negotiation? The negotiation example is desirable to illustrate that OCP Core has adequate mechanisms to negotiate transport encryption. Note that we are not introducing anything new at this point; the example was always there! In his insightful IESG review comment, Steve Bellovin specifically asked to clarify how OCP Core mechanisms are used in the example context. He correctly identified lack of documentation for when exactly the negotiated encryption (or any negotiated feature!) is enabled. The current revision of the draft attempts to address Steve's comments. Please see the URL above for the actual DISCUSS comment. > I'd much prefer to simply say that if you require confidentiality > you must be using a secure transport before beginning any OCP > negotiations. To be practical and compliant with IAB considerations, OCP has to provide a native mechanism for enabling encryption. HTTP has it. BEEP has it. Out-of-band encryption is possible, but if OCP cannot natively negotiate encryption it is simply incomplete as a communication protocol for two OPES agents. If anything, _that_ would cause IESG objections. However, OCP Core itself does not document encryption or authentication features. We have already discussed that such features should probably be documented, after we recharter. At any rate, we are past the point of WG Last Call for this draft. We are _not_ adding anything new or removing anything old here. We are simply addressing Steve Bellovin's comments by detailing existing requirements and polishing the existing example. > I think that what the document is trying to say is that if there's > some support for encryption in the underlying protocol, then OCP has > support for turning it on, however meaningless it may be. Kind of. OCP Core says that if two agents agree on transport encryption, they know exactly when to turn it on. Just like with HTTP CONNECT and UPGRADE methods or BEEP encryption negotiation. > But what about authentication, what about integrity? I think there > must be some discussion of integrity and authentication in the main > body, and there must be more explication in security considerations. OCP Core does not define encryption or authentication mechanisms. It does have a few simple integrity checks that are discussed. Thorough coverage of all security-related aspects should be done in separate drafts as it will depend on specific encryption/authentication/integrity mechanisms being documented. > Particularly, having opened this can of worms, the document should > at least note that a thorough analysis of security is needed for any > particular OCP mapping. A thorough analysis of security is needed for any standards track specification, including OCP mappings. > How do these HTTP CONNECT transactions determine a key to use for > their encryption, how do they represent encrypted data? Depends on the encryption algorithm, which is totally out of HTTP CONNECT scope. HTTP CONNECT is simply a way to establish a [possibly secure] tunnel through a proxy. HTTP and BEEP have other means of negotiating encryption and authentication, including means for negotiating encryption parameters. However, details are usually kept outside of HTTP or BEEP core as they are specific to each feature being negotiated. > Unless there is a prior basis for authentication and integrity, it > doesn't make sense to start encrypting and then establish > authentication. Integrity checks are often embedded into encryption schemes. Authentication over vulnerable (insecure) transport does not sound useful to me, but I am not a security expert. FWIW, SSH encrypts the transport first and only then authenticates the user. Fortunately, we do not care about this now. All these issues are outside of OCP Core scope, and that scope has been frozen already! Hope this clarifies, Alex. From owner-ietf-openproxy@mail.imc.org Wed May 5 04:10:32 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 EAA28929 for ; Wed, 5 May 2004 04:10:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLHU7-0003ZY-WE for opes-archive@ietf.org; Wed, 05 May 2004 04:10:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLHTK-0003OE-00 for opes-archive@ietf.org; Wed, 05 May 2004 04:09:42 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BLHSh-0003At-00 for opes-archive@ietf.org; Wed, 05 May 2004 04:09:03 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4580EPn047032; Wed, 5 May 2004 01:00:14 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4580ElD047031; Wed, 5 May 2004 01:00:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4580DbZ047008 for ; Wed, 5 May 2004 01:00:13 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i45809uH076283; Wed, 5 May 2004 02:00:09 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i45809di076282; Wed, 5 May 2004 02:00:09 -0600 (MDT) (envelope-from rousskov) Date: Wed, 5 May 2004 02:00:09 -0600 (MDT) From: Alex Rousskov To: "The Purple Streak, Hilarie Orman" cc: ietf-openproxy@imc.org Subject: Re: [Fwd: Re: ID Tracker State Update Notice: draft-ietf-opes-ocp-core] In-Reply-To: <200405050554.i455soFv005539@localhost.localdomain> Message-ID: References: <200405050554.i455soFv005539@localhost.localdomain> 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 Tue, 4 May 2004, The Purple Streak, Hilarie Orman wrote: > Putting the syntax out of scope would be a very good idea. OK. Here is the revised section: 15.1 Extending OCP Core OCP extensions MUST NOT change OCP Core message format, as defined by ABNF and accompanying normative rules in Section 3.1. The intent of this requirement is to allow OCP message viewers, validators, and "intermediary" software to at least isolate and decompose any OCP message, even a message with unknown to them (i.e., extended) semantics. OCP extensions are allowed to change normative OCP Core requirements for OPES processors and callout servers. However, OCP extensions SHOULD NOT make such changes and MUST require on a "MUST"-level that such changes are negotiated prior to taking effect. Informally, this specification defines compliant OCP agent behavior until changes to this specifications (if any) are successfully negotiated. For example, if an RTSP profile for OCP requires support for offsets exceeding 2147483647 octets, the profile specification can document appropriate OCP changes while requiring that RTSP adaptation agents negotiate "large offsets" support before using large offsets. Such negotiation can be bundled with negotiating another feature (e.g., negotiating an RTSP profile may imply support for "large offsets"). As implied by the above rules, OCP extensions may dynamically alter the negotiation mechanism itself, but such an alternation would have to be negotiated first, using the negotiation mechanism defined by this specification. For example, successfully negotiating a feature might change the default "Offer-Pending" value from false to true. Alex. From owner-ietf-openproxy@mail.imc.org Wed May 5 09:41:35 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 JAA12918 for ; Wed, 5 May 2004 09:41:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLMeW-0004Hb-Bw for opes-archive@ietf.org; Wed, 05 May 2004 09:41:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLMdc-00043e-00 for opes-archive@ietf.org; Wed, 05 May 2004 09:40:44 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BLMcg-0003pw-00 for opes-archive@ietf.org; Wed, 05 May 2004 09:39:42 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i45DTJdd021762; Wed, 5 May 2004 06:29:19 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i45DTJlr021761; Wed, 5 May 2004 06:29:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i45DTI7V021741 for ; Wed, 5 May 2004 06:29:18 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i45DSfa00896; Wed, 5 May 2004 09:28:41 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 May 2004 09:28:41 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD75409679E4B@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: "'internet-drafts@ietf.org'" Cc: "'ietf-openproxy@imc.org'" , "Abbie Barbir" , "'Markus Hofmann'" , "'Marshall Rose'" Subject: Request to publish: draft-ietf-opes-end-comm-07 Date: Wed, 5 May 2004 09:28:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C432A4.DDDF140A" 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,HTML_MESSAGE, LINES_OF_YELLING autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C432A4.DDDF140A Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C432A4.DDDF140A" ------_=_NextPart_001_01C432A4.DDDF140A Content-Type: text/plain Please publish the following draft-ietf-opes-end-comm-07 as a WG Draft. Thanks Abbie ------_=_NextPart_001_01C432A4.DDDF140A Content-Type: text/html Request to publish: draft-ietf-opes-end-comm-07

    Please publish the following

    draft-ietf-opes-end-comm-07

    as a WG Draft.

    Thanks
    Abbie

      ------_=_NextPart_001_01C432A4.DDDF140A-- ------_=_NextPart_000_01C432A4.DDDF140A Content-Type: text/plain; name="draft-ietf-opes-end-comm-07.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-opes-end-comm-07.txt" Content-Transfer-Encoding: quoted-printable Open Pluggable Edge Services A. = Barbir Internet-Draft Nortel = Networks Expires: November 3, 2004 May 5, = 2004 OPES entities and end points communication draft-ietf-opes-end-comm-07 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that = other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six = months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 3, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This memo documents tracing and non-blocking (bypass) requirements for Open Pluggable Edge Services (OPES). Barbir Expires November 3, 2004 [Page = 1] =0C Internet-Draft OPES entities and end points communication May = 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . = 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . = 3 2. OPES System . . . . . . . . . . . . . . . . . . . . . . . . . = 4 3. Tracing Requirements . . . . . . . . . . . . . . . . . . . . . = 5 3.1 Traceable entities . . . . . . . . . . . . . . . . . . . . = 5 3.2 System requirements . . . . . . . . . . . . . . . . . . . = 6 3.3 Processor requirements . . . . . . . . . . . . . . . . . . = 6 3.4 Callout server requirements . . . . . . . . . . . . . . . = 7 4. Bypass (Non-blocking feature) Requirements . . . . . . . . . . = 8 4.1 Bypassable entities . . . . . . . . . . . . . . . . . . . = 9 4.2 System requirements . . . . . . . . . . . . . . . . . . . = 9 4.3 Processor requirements . . . . . . . . . . . . . . . . . . = 10 4.4 Callout server requirements . . . . . . . . . . . . . . . = 10 5. Protocol Binding . . . . . . . . . . . . . . . . . . . . . . . = 11 6. Compliance Considerations . . . . . . . . . . . . . . . . . . = 12 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . = 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . = 14 8.1 Tracing security considerations . . . . . . . . . . . . . = 14 8.2 Bypass security considerations . . . . . . . . . . . . . . = 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . = 17 9.1 Normative References . . . . . . . . . . . . . . . . . . . . = 17 9.2 Informative References . . . . . . . . . . . . . . . . . . . = 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . = 18 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . = 19 Intellectual Property and Copyright Statements . . . . . . . . = 20 Barbir Expires November 3, 2004 [Page = 2] =0C Internet-Draft OPES entities and end points communication May = 2004 1. Introduction The Open Pluggable Edge Services (OPES) architecture [1] enables cooperative application services (OPES services) between a data provider, a data consumer, and zero or more OPES processors. The application services under consideration analyze and possibly transform application-level messages exchanged between the data provider and the data consumer. This work specifies OPES tracing and bypass functionality. The architecture document [1] requires that tracing is supported = in-band. This design goal limits the type of application protocols that OPES can support. The details of what a trace record can convey are also dependent on the choice of the application level protocol. For these reasons, this work only documents requirements for OPES entities = that are needed to support traces and bypass functionality. The task of encoding tracing and bypass features is application protocol specific. Separate documents will address HTTP and other protocols. The architecture does not prevent implementers from developing out-of-band protocols and techniques to address tracing and bypass. Such protocols are out of scope of the current work. 1.1 Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. When used with the normative meanings, these keywords will be all uppercase. Occurrences of these words in lowercase comprise normal prose usage, with no normative implications. Barbir Expires November 3, 2004 [Page = 3] =0C Internet-Draft OPES entities and end points communication May = 2004 2. OPES System This sections provides a definition of OPES System. This is needed = in order to define what is traceable (or bypassable) in an OPES Flow. Definition: An OPES System is a set of all OPES entities authorized by either the data provider or the data consumer application to process a given application message. The nature of the authorization agreement determines if authority delegation is transitive (meaning an authorized entity is authorized to include other entities). If specific authority agreements allow for re-delegation, an OPES system can be formed by induction. In this case, an OPES system starts with entities directly authorized by a data provider (or a data consumer) application. The OPES system then includes any OPES entity authorized by an entity that is already in the OPES system. The authority delegation is always viewed in the context of a given application message. An OPES System is defined on an application message basis. Having an authority to process a message does not imply being involved in message processing. Thus, some OPES system members may not participate in processing of a message. Similarly, some members may process the same message several times. The above definition implies that there can be no more than two OPES systems [Client-side and server-side OPES systems can process the same message at the same time] processing the same message at a = given time. This is based on the assumption that there is a single data provider and a single data consumer as far as a given application message is concerned. For example, consider a Content Delivery Network (CDN) delivering an image on behalf of a busy web site. OPES processors and services = that the CDN uses to adapt and deliver the image comprise an OPES System. In a more complex example, an OPES System would contain third party OPES entities that the CDN engages to perform adaptations (e.g., to adjust image quality). Barbir Expires November 3, 2004 [Page = 4] =0C Internet-Draft OPES entities and end points communication May = 2004 3. Tracing Requirements The definition of OPES trace and tracing are given next. OPES trace: application message information about OPES entities that adapted the message. OPES tracing: the process of creating, manipulating, or interpreting an OPES trace. Note that the above trace definition assumes in-band tracing. This dependency can be removed if desired. Tracing is performed on per message basis. Trace format is dependent on the application protocol that is being adapted. A traceable entity can appear multiple times in a trace (for example, every time it acts on a message). 3.1 Traceable entities This section focuses on identifying traceable entities in an OPES Flow. Tracing information provides an "end" with information about OPES entities that adapted the data. There are two distinct uses of OPES traces. First, a trace enables an "end" to detect the presence of OPES System. Such "end" should be able to see a trace entry, but = does not need to be able to interpret it beyond identification of the = OPES System and location of certain required OPES-related disclosures = (see Section 3.2). Second, the OPES System administrator is expected to be able to interpret the contents of an OPES trace. The trace can be relayed to the administrator by an "end" without interpretation, as opaque data (e.g., a TCP packet or an HTTP message snapshot). The administrator can use the trace information to identify the participating OPES entities. The administrator can use the trace to identify the = applied adaptation services along with other message-specific information. Since the administrators of various OPES Systems can have various ways of looking into tracing, they require the freedom in what to = put in trace records and how to format them. At the implementation level, for a given trace, an OPES entity involved in handling the corresponding application message is traceable or traced if information about it appears in that trace. This work does not specify any order to that information. The order of information in a trace can be OPES System specific or can be defined by application bindings documents. OPES entities have different levels of traceability requirements. Specifically, Barbir Expires November 3, 2004 [Page = 5] =0C Internet-Draft OPES entities and end points communication May = 2004 o An OPES System MUST add its entry to the trace. o An OPES processor SHOULD add its entry to the trace. o An OPES service MAY add its entry to the trace. o An OPES entity MAY delegate addition of its trace entry to = another OPES entity. For example, an OPES System can have a dedicated = OPES processor for adding System entries; an OPES processor can use a callout service to manage all OPES trace manipulations (since = such manipulations are OPES adaptations). In an OPES context, a good tracing approach is similar to a trouble ticket ready for submission to a known address. The address is printed on the ticket. The trace in itself is not necessarily a detailed description of what has happened. It is the responsibility of the operator to decode trace details and to resolve the problems. 3.2 System requirements The following requirements document actions when forming an OPES System trace entry: o OPES system MUST include its unique identification in its trace entry. Here, uniqueness scope is all OPES Systems that may adapt the message being traced. o An OPES System MUST define its impact on inter- and = intra-document reference validity. o An OPES System MUST include information about its privacy policy, including identity of the party responsible for setting and enforcing the policy. o An OPES System SHOULD include information that identifies, to the technical contact, the OPES processors involved in processing = the message. o When providing required information, an OPES System MAY use a single URI to identify a resource containing several required items. For example, an OPES System can point to a single web page with a reference to System privacy policy and technical contact information. This specification does not define the meaning of the terms privacy policy, policy enforcement, or reference validity or technical contact and contains no requirements regarding encoding, language, format, or any other aspects of that information. For example, a URI used for an OPES System trace entry may look like "http:// www.examplecompany.com/opes/?client=3Dexample.com" where the = identified web page is dynamically generated and contains the all OPES System information required above. 3.3 Processor requirements The following requirements document actions when forming an OPES Barbir Expires November 3, 2004 [Page = 6] =0C Internet-Draft OPES entities and end points communication May = 2004 System trace entry: o OPES processor SHOULD add its unique identification to the trace. Here, uniqueness scope is the OPES System containing the processor. 3.4 Callout server requirements In an OPES system, it is the task of an OPES processor to add trace records to application messages. The OPES System administrator decides if and under what conditions callout servers may add trace information to application messages. Barbir Expires November 3, 2004 [Page = 7] =0C Internet-Draft OPES entities and end points communication May = 2004 4. Bypass (Non-blocking feature) Requirements IAB recommendation (3.3) [6] requires that the OPES architecture = does not prevent a data consumer application from retrieving non-OPES version of content from a data provider application, provided that the non-OPES content exists. IAB recommendation (3.3) suggests that the Non-blocking feature (bypass) be used to bypass faulty OPES intermediaries (once they have been identified, by some method). In addressing IAB consideration (3.3), one need to specify what constitutes non-OPES content. In this work the definition of "non-OPES" content is provider dependent. In some cases, the availability of "non-OPES" content can be a function of the internal policy of a given organization that has contracted the services of = an OPES provider. For example, Company A has as contract with an OPES provider to perform virus checking on all e-mail attachments. An employee X of Company A can issue a non-blocking request for the virus scanning service. The request could be ignored by the OPES provider since it contradicts its agreement with Company A. The availability of non-OPES content can be a function of content providers (or consumers or both) policy and deployment scenarios = [5]. For this reason, this work does not attempt to define what is an = OPES content as opposed to non-OPES content. The meaning of OPES versus non-OPES content is assumed to be determined through various agreements between the OPES provider, data provider and/or data consumer. The agreement determines what OPES services can be = bypassed and in what order (if applicable). This specification documents bypassing of an OPES service or a group of services identified by a URI. In this context, to "bypass the service" for a given application message in an OPES Flow means to "not invoke the service" for that application message. A bypass URI that identifies an OPES system (processor) matches all services attached to that OPES system (processor). However, bypassing of OPES processors and OPES Systems themselves requires non-OPES mechanisms and is out of this specification scope. A bypass request an instruction to bypass, usually embedded in an application message. The current specification does not provide for a good mechanism that allow and "end" to specify to "bypass this service but only if it is a part of that OPES system" or "bypass all services of that OPES system but not of this OPES system". Furthermore, if an OPES processor does not know for sure that a bypass URI does not match = its service, it must bypass that service. If no non-OPES content is available without the specified service, the bypass request for that service must be ignored. This design Barbir Expires November 3, 2004 [Page = 8] =0C Internet-Draft OPES entities and end points communication May = 2004 implies that it may not be possible to detect non-OPES content existence or to detect violations of bypass rules in the = environments where the tester does not know whether non-OPES content exists. This design assumes that most bypass requests are intended for situations where serving undesirable OPES content is better than serving an error message that no preferred non-OPES content exists. 4.1 Bypassable entities In this work, the focus is on developing a bypass feature that allow a user to instruct the OPES System to bypass some or all of its services. The collection of OPES services that can be bypassed is a function of the agreement of the OPES provider with either (or both) the content provider or the content consumer applications. In the general case, a bypass request is viewed as a bypass instruction = that contains a URI that identifies an OPES entity or a group of OPES entities that perform a service (or services) to be bypassed. An instruction may contain more than one such URI. A special wildcard identifier can be used to represent all possible URIs. In an OPES Flow, a bypass request is processed by each involved OPES processor. This means that an OPES processor examines the bypass instruction and if non-OPES content is available, the processor then bypasses the indicated services. The request is then forwarded to = the next OPES processor in the OPES Flow. The next OPES processor would then handle all bypass requests, regardless of the previous = processor actions. The processing chain continues throughout the whole processors that are involved in the OPES Flow. 4.2 System requirements In an OPES System bypass requests are generally client centric (originated by the data consumer application) and go in the opposite direction of tracing requests. This work requires that the bypass feature be performed in-band as an extension to an application specific protocol. Non-OPES entities should be able to safely ignore these extensions. The work does not prevent OPES Systems from developing their own out of band protocols. The following requirements apply for bypass feature as related to an OPES System (the availability of a non-OPES content is a precondition) : o An OPES System MUST support a bypass feature. This means that the OPES System bypasses services whose URIs are identified by an = OPES "end". o An OPES System MUST provide OPES version of the content if non-OPES version is not available. Barbir Expires November 3, 2004 [Page = 9] =0C Internet-Draft OPES entities and end points communication May = 2004 In order to facilitate the debugging (or data consumer user experience) of the bypass feature in an OPES System, it would be beneficial if non-bypassed entities include information related to why they ignored the bypass instruction. It is important to note = that in some cases the tracing facility itself may be broken and the = whole OPES System (or part) may need to be bypassed through the issue of a bypass instruction. 4.3 Processor requirements Bypass requirements for OPES processors are (the availability of a non-OPES content is a precondition): o OPES processor SHOULD be able to interpret and process a bypass instruction. This requirement applies to all bypass instructions, including those that identify unknown-to-recipient services. o OPES processors MUST forward bypass request to the next application hop provided that the next hop speaks application protocol with OPES bypass support. o OPES processor SHOULD be able to bypass it's service(s) = execution. OPES processors that know how to process and interpret a bypass instruction have the following requirements: o The recipient of a bypass instruction with a URI that does not identify any known-to-recipient OPES entity MUST treat that URI = as a wildcard identifier (meaning bypass all applicable services). 4.4 Callout server requirements In an OPES system, it is the task of an OPES processor to process bypass requests. The OPES System administrator decides if and under what conditions callout servers process bypass requests. Barbir Expires November 3, 2004 [Page = 10] =0C Internet-Draft OPES entities and end points communication May = 2004 5. Protocol Binding The task of encoding tracing and bypass features is application protocol specific. Separate documents will address HTTP and other protocols. These documents must address the ordering of trace information if needed. Barbir Expires November 3, 2004 [Page = 11] =0C Internet-Draft OPES entities and end points communication May = 2004 6. Compliance Considerations This specification defines compliance for the following compliance subjects: OPES System, processors, entities and callout servers. A compliance subject is compliant if it satisfies all applicable "MUST" and "SHOULD" level requirements. By definition, to satisfy a "MUST" level requirement means to act as prescribed by the requirement; to satisfy a "SHOULD" level requirement means to either act as prescribed by the requirement or have a reason to act differently. A requirement is applicable to the subject if it instructs (addresses) the subject. Informally, compliance with this draft means that there are no known "MUST" violations, and all "SHOULD" violations are conscious. In other words, a "SHOULD" means "MUST satisfy or MUST have a reason to violate". It is expected that compliance claims are accompanied by = a list of unsupported SHOULDs (if any), in an appropriate format, explaining why preferred behavior was not chosen. Only normative parts of this specification affect compliance. Normative parts are: parts explicitly marked using the word "normative", definitions, and phrases containing unquoted = capitalized keywords from [RFC2119]. Consequently, examples and illustrations = are not normative. Barbir Expires November 3, 2004 [Page = 12] =0C Internet-Draft OPES entities and end points communication May = 2004 7. IANA considerations This specification contains no IANA considerations. Application bindings MAY contain application-specific IANA considerations. Barbir Expires November 3, 2004 [Page = 13] =0C Internet-Draft OPES entities and end points communication May = 2004 8. Security Considerations Security considerations for OPES are documented in [4]. Policy and authorization issues are documented in [3]. It is recommended that designers consult these documents before reading this section. This document is a requirement document for tracing and bypass feature. The requirements that are stated in this document can be used to extend an application level protocol to support these features. As such, the work has security precautions. 8.1 Tracing security considerations The tracing facility for OPES architecture is implemented as a protocol extension. Inadequate implementations of the tracing facility may defeat safeguards built into the OPES architecture. The tracing facility by itself can become a target of malicious attacks or used to lunch attacks on an OPES System. Threats caused by or against the tracing facility can be viewed as threats at the application level in an OPES Flow. In this case, the threats can affect the data consumer and the data provider application. Since tracing information is a protocol extension, these traces can be injected in the data flow by non-OPES entities. In this case, there are risks that non-OPES entities can be compromised in a fashion that threat the overall integrity and effectiveness of an OPES System. For example, a non-OPES proxy can add fake tracing information into a trace. This can be done in the form of wrong, or unwanted, or non existent services. A non-OPES entity can inject large size traces that may cause buffer overflow in a data consumer application. The same threats can arise from compromised OPES entities. An attacker can control an OPES entity and inject wrong, = or very large trace information that can overwhelm an end or the next OPES entity in an OPES flow. Similar threats can result from bad implementations of the tracing facility in trusted OPES entities. Compromised tracing information can be used to launch attacks on an OPES System that give the impression that unwanted content transformation was performed on the data. This can be achieved by inserting wrong entity (such OPES processor) identifiers. A compromised trace can affect the overall message integrity = structure. This can affect entities that use message header information to perform services such as accounting, load balancing, or reference-based services. Compromised trace information can be used to launch DoS attacks that Barbir Expires November 3, 2004 [Page = 14] =0C Internet-Draft OPES entities and end points communication May = 2004 can overwhelm a data consumer application or an OPES entity in an OPES Flow. Inserting wrong tracing information can complicates the debugging tasks performed by system administrator during trouble shooting of OPES System behavior. As a precaution, OPES entities ought to be capable of verifying that the inserted traces are performed by legal OPES entities. This can = be done as part of the authorization and authentication face. Policy = can be used to indicate what trace information can be expected from a peer entity. Other application level related security concerns can = be found in [4]. 8.2 Bypass security considerations The bypass facility for OPES architecture is implemented as a protocol extension. Inadequate implementations of the bypass = facility may defeat safeguards built into the OPES architecture. The bypass facility by itself can become a target of malicious attacks or used to lunch attacks on an OPES System. Threats caused by or against the bypass facility can be viewed as threats at the application level in an OPES Flow. In this case, the threats can affect the data consumer and the data provider application. There are risks for the OPES System by non-OPES entities, whereby, these entities can insert bypass instructions into the OPES Flow. = The threat can come from compromised non-OPES entities. The threat might affect the overall integrity and effectiveness of an OPES System. = For example, a non-OPES proxy can add bypass instruction to bypass legitimate OPES entities. The attack might result in overwhelming = the original content provider servers, since the attack essentially bypass any load balancing techniques. In addition, such an attack is also equivalent to a DoS attack, whereby, a legitimate data consumer application may not be able to access some content from a content provider or its OPES version. Since an OPES Flow may include non-OPES entities, it is susceptible to man-in-the-middle attacks, whereby an intruder may inject bypass instructions into the data path. These attacks may affect content availability or disturb load balancing techniques in the network. The above threats can also arise by compromised OPES entities. An intruder can compromise an OPES entities and then use man-in-the-middle techniques to disturb content availability to a data consumer application or overload a content provider server (essentially, some form of a DoS attack). Barbir Expires November 3, 2004 [Page = 15] =0C Internet-Draft OPES entities and end points communication May = 2004 Attackers can use the bypass instruction to affect the overall integrity of the OPES System. The ability to introduce bypass instructions into a data flow may effect the accounting of the OPES System. It may also affect the quality of content that is delivered to the data consumer applications. Similar threats can arise from = bad implementations of the bypass facility. Inconsistent or selective bypass is also a threat. Here, one end can try to bypass a subset of OPES entities so that the resulting = content is malformed and crashes or compromises entities that process that content (and expect that content to be complete and valid). Such exceptions are often not tested because implementers do not expect a vital service to disappear from the processing loop. Other threats can arise from configuring access control policies for OPES entities. It is possible that systems implementing access controls via OPES entities may be incorrectly configured to honor bypass and, hence, give unauthorized access to intruders. Tap bypass can also be a threat. This is because systems = implementing wiretaps via OPES entities may be incorrectly configured to honor bypass and, hence, ignore (leave undetected) traffic with bypass instructions that should have been tapped or logged. It is also possible for one end to bypass services such as virus scanning at = the receiving end. This threat can be used by hackers to inject viruses throughout the network. Other application level related security concerns can be found in [4]. Barbir Expires November 3, 2004 [Page = 16] =0C Internet-Draft OPES entities and end points communication May = 2004 9. References 9.1 Normative References [1] A. Barbir et al., "An Architecture for Open Pluggable Edge Services (OPES)", Internet-Draft http://www.ietf.org/ internet-drafts/draft-ietf-opes-architecture-04, December = 2002. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [3] A. Barbir et al., "Policy, Authorization and Enforcement Requirements of OPES", Internet-Draft http://www.ietf.org/ internet-drafts/draft-ietf-opes-authorization-02.txt, February 2003. [4] A. Barbir et al., "Security Threats and Risks for Open = Pluggable Edge Services", Internet-Draft http://www.ietf.org/ internet-drafts/draft-ietf-opes-threats-02.txt, February 2003. 9.2 Informative References [5] A. Barbir et al., "OPES Use Cases and Deployment Scenarios", Internet-Draft http://www.ietf.org/internet-drafts/ draft-ietf-opes-scenarios-01.txt, August 2002. [6] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002. [7] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [8] Rousskov, A. et al, "HTTP adaptation with OPES", Internet-Draft = http://www.ietf.org/internet-drafts/draft-ietf-opes-http-01.txt, October 2003. [9] A. Barbir et al., "OPES Treatment of IAB Considerations", Internet-Draft http://www.ietf.org/internet-drafts/ draft-ietf-opes-iab-03.txt, October 2003. Barbir Expires November 3, 2004 [Page = 17] =0C Internet-Draft OPES entities and end points communication May = 2004 Author's Address Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean, Ontario K2H 8E9 Canada Phone: +1 613 763 5229 EMail: abbieb@nortelnetworks.com Barbir Expires November 3, 2004 [Page = 18] =0C Internet-Draft OPES entities and end points communication May = 2004 Appendix A. Acknowledgements Several people has contributed to this work. Many thanks to: Alex Rousskov, Hilarie Orman, Oscar Batuner, Markus Huffman, Martin Stecher, Marshall Rose and Reinaldo Penno. Barbir Expires November 3, 2004 [Page = 19] =0C Internet-Draft OPES entities and end points communication May = 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances = of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification = can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph = are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Barbir Expires November 3, 2004 [Page = 20] =0C Internet-Draft OPES entities and end points communication May = 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Barbir Expires November 3, 2004 [Page = 21] =0C ------_=_NextPart_000_01C432A4.DDDF140A-- From owner-ietf-openproxy@mail.imc.org Wed May 5 12:27:55 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 MAA23696 for ; Wed, 5 May 2004 12:27:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLPFU-0000JJ-VV for opes-archive@ietf.org; Wed, 05 May 2004 12:27:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLPEn-00002b-00 for opes-archive@ietf.org; Wed, 05 May 2004 12:27:13 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BLPDz-0007Xw-00 for opes-archive@ietf.org; Wed, 05 May 2004 12:26:23 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i45GCwvN038708; Wed, 5 May 2004 09:12:58 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i45GCwhT038707; Wed, 5 May 2004 09:12:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail.radioburst.com (mail.esmartstart.com [66.119.143.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i45GCvVT038690 for ; Wed, 5 May 2004 09:12:57 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (dav.rfburst.com [209.90.91.153]) by mail.radioburst.com (8.12.8/8.12.8) with ESMTP id i45GCeYv005858; Wed, 5 May 2004 10:12:41 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.8/8.11.6) with ESMTP id i45GCKHK019339; Wed, 5 May 2004 10:12:20 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i45GCEhE019335; Wed, 5 May 2004 10:12:14 -0600 Date: Wed, 5 May 2004 10:12:14 -0600 Message-Id: <200405051612.i45GCEhE019335@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: rousskov@measurement-factory.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage Subject: Re: [Fwd: Re: ID Tracker State Update Notice: draft-ietf-opes-ocp-core] X-esmartscan-MailScanner: Found to be clean 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 I think there's a misunderstanding about the encryption requirement. The IAB guidance was for OPES-processor-to-OPES-processor. There's no such onus on OCP. I know a little about security protocols, and I don't see how OCP defines a secure way to interface to transport security features. I strongly advise ditching it rather than trying to repair it. Hilarie From owner-ietf-openproxy@mail.imc.org Wed May 5 12:38:48 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 MAA24688 for ; Wed, 5 May 2004 12:38:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLPQ2-0003Ym-6d for opes-archive@ietf.org; Wed, 05 May 2004 12:38:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLPPB-0003Io-00 for opes-archive@ietf.org; Wed, 05 May 2004 12:37:58 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BLPOQ-00032Y-00 for opes-archive@ietf.org; Wed, 05 May 2004 12:37:10 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i45GQUSg039366; Wed, 5 May 2004 09:26:30 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i45GQUK9039365; Wed, 5 May 2004 09:26:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail.radioburst.com (mail.esmartstart.com [66.119.143.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i45GQT0p039358 for ; Wed, 5 May 2004 09:26:29 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (dav.rfburst.com [209.90.91.153]) by mail.radioburst.com (8.12.8/8.12.8) with ESMTP id i45GQ9Yv007621; Wed, 5 May 2004 10:26:09 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.8/8.11.6) with ESMTP id i45GPiHK019637; Wed, 5 May 2004 10:25:45 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i45GPgif019633; Wed, 5 May 2004 10:25:42 -0600 Date: Wed, 5 May 2004 10:25:42 -0600 Message-Id: <200405051625.i45GPgif019633@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: rousskov@measurement-factory.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage Subject: Re: [Fwd: Re: ID Tracker State Update Notice: draft-ietf-opes-ocp-core] X-esmartscan-MailScanner: Found to be clean 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 OCP extensions are allowed to change normative OCP Core requirements for OPES processors and callout servers. However, OCP extensions SHOULD NOT make such changes and MUST require on a "MUST"-level that such changes are negotiated prior to taking effect. Informally, this specification defines compliant OCP agent behavior until changes to this specifications (if any) are successfully negotiated. Is "negotiated" used to mean a protocol operation in the second sentence, and as a action within a standards body in the third sentence. I think that the IESG concern about negotiation is that if the state machine for the core negotiaion changes as a result of negotiation (in the protocol sense), you can easily get a resulting state machine that is unmanageable. Infinite loops, deadlocks, etc. Can you add verbiage that indicates why those bad things are not possibilities? Hilarie From owner-ietf-openproxy@mail.imc.org Wed May 5 13:01:03 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 NAA26029 for ; Wed, 5 May 2004 13:01:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLPlZ-0001j3-Ao for opes-archive@ietf.org; Wed, 05 May 2004 13:01:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLPko-0001Rl-00 for opes-archive@ietf.org; Wed, 05 May 2004 13:00:19 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BLPjl-00017z-00 for opes-archive@ietf.org; Wed, 05 May 2004 12:59:14 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i45GmjkH041016; Wed, 5 May 2004 09:48:45 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i45Gmj5V041015; Wed, 5 May 2004 09:48:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i45GmhlO041009 for ; Wed, 5 May 2004 09:48:44 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i45Gmkp6096438; Wed, 5 May 2004 10:48:46 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i45GmkUi096437; Wed, 5 May 2004 10:48:46 -0600 (MDT) (envelope-from rousskov) Date: Wed, 5 May 2004 10:48:46 -0600 (MDT) From: Alex Rousskov To: Abbie Barbir cc: "'ietf-openproxy@imc.org'" Subject: Re: Request to publish: draft-ietf-opes-end-comm-07 In-Reply-To: <87609AFB433BD5118D5E0002A52CD75409679E4B@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD75409679E4B@zcard0k6.ca.nortel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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 Wed, 5 May 2004, Abbie Barbir wrote: > Please publish the following draft-ietf-opes-end-comm-07 as a WG > Draft. Abbie, Thanks for making the edits! They seem to address Allison Mankin's DISCUSS item (which is already cleared from the IESG review record). We still need to address Ted Hardie's DISCUSS items, right? I have already proposed the text for Ted's second DISCUSS and Markus supported its addition to the existing wiretapping paragraph: > Following an IETF policy on Wiretapping [RFC2804], OPES > communication model does not consider wiretapping requirements. > Nevertheless, the documented threat is real, not obvious, and > OPES technology users operating in wiretapping or similar > logging environments should be aware of it. Unless there are any objections, could you please incorporate that? As for the first DISCUSS item, the situation is more difficult. I recall that we struggled a lot with whether bypass should generate errors when no OPES content is available. I still think we made the right decision, although I regret not adding another bypass feature with Ted's semantics. It did not occur to me at the time that we can have it both ways if we have two features! Don't worry, I am not going to propose adding more features at this point :-). At the end of this message, I collected a few past remarks related to this issue. It may be a good idea to contemplate them if you disagree with my proposal/assessment. I propose to address Ted's concern by adding the following two paragraphs at the end of Section 4 preamble (just before 4.1): Bypass feature is to malfunctioning OPES services as HTTP "reload" request is to malfunctioning HTTP caches. The primary purpose of the bypass is to get usable content in the presence of service failures and not to provide the content consumer with more information on what is going on. OPES trace should be used for the latter instead. While this work defines a "bypass service if possible" feature, there are other related bypass features that can be implemented in OPES and/or in application protocols being adapted. For example, a "bypass service or generate an error" or "bypass OPES entity or generate an error". Such services would be useful for debugging broken OPES systems and may be defined in other OPES specifications. This work concentrates on a documenting a user-level bypass feature addressing direct IAB concern. Does the above seem like an appropriate response to Ted's concerns? Thanks, Alex. P.S. Here are a few relevant remarks from the F2F meeting notes: > Sally Floyd: ... The IAB document does not mean "user has to have a > way to bypass firewalls, boundaries, etc." It is saying, "If a user > asks for content from web server, and the content gets mangled by an > OPES server, then user needs to be able to figure out what went > wrong." > w.r.t. OPES bypass - Sally Floyd: Source of IAB concern about > non-OPES is data integrity, e.g., how does one detect malicious > transformation of data. Here is a relevant comment from one of the earlier draft reviews: > [S19: Does bypass semantics mean "give OPES version if non-OPES is > not available" or "give an error if non-OPES is not available"? This > is very important to document clearly because it affects bypass > design/rules a lot.] Our current rules are more-or-less clear but note that I claimed that the decision will affect other rules. I wish I were more verbose at that point. Here is a relevant IAB draft change log entry: >* Be careful not to imply that all OPES intermediaries must obey > bypass instructions. Bypass should be ignored when no non-OPES > version of the content exists. Ideally, this may need to be > polished further -- if there is no non-OPES version of the > content, most IAB considerations probably do not apply because > there is really no adaptation, only creation of content (and we > should not restrict content creation). From owner-ietf-openproxy@mail.imc.org Wed May 5 13:13:03 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 NAA26754 for ; Wed, 5 May 2004 13:13:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLPxB-00052v-8A for opes-archive@ietf.org; Wed, 05 May 2004 13:13:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLPw7-0004kn-00 for opes-archive@ietf.org; Wed, 05 May 2004 13:11:59 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BLPvg-0004Ts-00 for opes-archive@ietf.org; Wed, 05 May 2004 13:11:32 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i45H26xM042520; Wed, 5 May 2004 10:02:06 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i45H26PJ042519; Wed, 5 May 2004 10:02:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i45H24Tn042513 for ; Wed, 5 May 2004 10:02:05 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i45H24p6097065; Wed, 5 May 2004 11:02:04 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i45H24Pd097064; Wed, 5 May 2004 11:02:04 -0600 (MDT) (envelope-from rousskov) Date: Wed, 5 May 2004 11:02:04 -0600 (MDT) From: Alex Rousskov To: "The Purple Streak, Hilarie Orman" cc: ietf-openproxy@imc.org Subject: Re: [Fwd: Re: ID Tracker State Update Notice: draft-ietf-opes-ocp-core] In-Reply-To: <200405051612.i45GCEhE019335@localhost.localdomain> Message-ID: References: <200405051612.i45GCEhE019335@localhost.localdomain> 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 Wed, 5 May 2004, The Purple Streak, Hilarie Orman wrote: > I think there's a misunderstanding about the encryption requirement. > The IAB guidance was for OPES-processor-to-OPES-processor. There's no > such onus on OCP. IAB guidance is end-to-end, which includes processor-to-processor and processor-to-callout_server. Since callout servers may be remote, it is pointless to ensure processor-to-processor encryption without processor-to-callout_server encryption! If IAB did not mention callout servers, it's becuase they did not know about them or rightly considered them equivalent to other processors as far as IAB considerations are concerned. > I know a little about security protocols, and I don't see how OCP > defines a secure way to interface to transport security features. You are absolutely correct: (a) OCP Core allows for a common (HTTP, BEEP, other?) interface to transport security. (b) OCP Core does not define an interface to transport security. > I strongly advise ditching it rather than trying to repair it. (c) We are not reparing anything specific to transport security. So, in a way, we have already ditched it long time ago when we removed encryption-related profiles from OCP Core. We are not trying to add them now. We are simply addressing a very valid comment by Steve Bellovin that is not really secific to security (it applies to _any_ OCP negotiation). Hope this clarifies, Alex. From owner-ietf-openproxy@mail.imc.org Wed May 5 13:32:57 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 NAA27964 for ; Wed, 5 May 2004 13:32:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLQGP-0002qX-Q9 for opes-archive@ietf.org; Wed, 05 May 2004 13:32:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLQFS-0002ab-00 for opes-archive@ietf.org; Wed, 05 May 2004 13:31:59 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BLQEj-0002K5-00 for opes-archive@ietf.org; Wed, 05 May 2004 13:31:13 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i45HJmcv044109; Wed, 5 May 2004 10:19:48 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i45HJmwd044107; Wed, 5 May 2004 10:19:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i45HJl0E044100 for ; Wed, 5 May 2004 10:19:47 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i45HJnp6097698; Wed, 5 May 2004 11:19:50 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i45HJn2r097697; Wed, 5 May 2004 11:19:49 -0600 (MDT) (envelope-from rousskov) Date: Wed, 5 May 2004 11:19:49 -0600 (MDT) From: Alex Rousskov To: "The Purple Streak, Hilarie Orman" cc: ietf-openproxy@imc.org Subject: Re: [Fwd: Re: ID Tracker State Update Notice: draft-ietf-opes-ocp-core] In-Reply-To: <200405051625.i45GPgif019633@localhost.localdomain> Message-ID: References: <200405051625.i45GPgif019633@localhost.localdomain> 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 Wed, 5 May 2004, The Purple Streak, Hilarie Orman wrote: > OCP extensions are allowed to change normative OCP Core requirements > for OPES processors and callout servers. However, OCP extensions > SHOULD NOT make such changes and MUST require on a "MUST"-level that > such changes are negotiated prior to taking effect. Informally, this > specification defines compliant OCP agent behavior until changes to > this specifications (if any) are successfully negotiated. > > Is "negotiated" used to mean a protocol operation in the second > sentence, and as a action within a standards body in the third > sentence. The meaning of negotiation does not change from the second sentence to the third. If something implies that it does, please be specific what that something is or suggest a different wording. Note that the third sentence is not normative. Basic OCP negotiations mechanisms are defined in Section 6 "Negotiation". > I think that the IESG concern about negotiation is that if the state > machine for the core negotiaion changes as a result of negotiation > (in the protocol sense), The state always changes as a result of a successful negotiation. Otherwise, we did not negotiated anything! > you can easily get a resulting state machine that is unmanageable. > Infinite loops, deadlocks, etc. Can you add verbiage that indicates > why those bad things are not possibilities? I cannot prove protocol correctness; it is possible that OCP Core negotiation is flawed. Unknown bugs notwithstanding, Section 6 "Negotiation", Section 11.18 "Negotiation Offer (NO)", and Section 11.19 "Negotiation Response (NR)" contain specific rules/requirements that are meant to avoid wrong state as a result of a negotiation. Note that specific feature definitions (OCP Core does not define any features) may contain additional requirements. The section you quoted from above is about OCP extensions that may use OCP Core negotiation mechanisms to adjust some OCP Core rules to better fit their needs. The section has one example to illustrate the need. Thanks, Alex. From qqlfnbsferrqzm@ureah.com Thu May 6 01:10:55 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 BAA04351 for ; Thu, 6 May 2004 01:10:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLb9p-0004MV-Sn for opes-archive@ietf.org; Thu, 06 May 2004 01:10:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLb8p-0003yD-00 for opes-archive@ietf.org; Thu, 06 May 2004 01:09:53 -0400 Received: from cpc3-nfds4-3-0-cust166.nott.cable.ntl.com ([81.105.98.166]) by ietf-mx with smtp (Exim 4.12) id 1BLb6m-00035r-00 for opes-archive@ietf.org; Thu, 06 May 2004 01:07:45 -0400 Received: from 8.195.220.40 by 81.105.98.166; Thu, 06 May 2004 10:04:50 +0400 Message-ID: From: "Domingo Odonnell" Reply-To: "Domingo Odonnell" To: opes-archive@ietf.org Subject: Buy Ambien online Date: Thu, 06 May 2004 10:02:50 +0400 X-Mailer: Microsoft Outlook Express 6.00.2462.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--32586532233872478" 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=7.7 required=5.0 tests=FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS,HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, MISSING_MIMEOLE,SUBJ_BUY autolearn=no version=2.60 X-Spam-Report: * 0.9 SUBJ_BUY 'Subject' starts with Buy, Buying * 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 * 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 ----32586532233872478 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable


    Jflotation burke briggs bemoan planar droll michelangelo inconsiderabl= e ablate ebony recuperate=20!Iailanthus metabolite aboard passe stonewort = hog amide elysee goldwater chalice coxcomb=20.Xplyscore theoretician dipol= e salesman elmira ignoramus legion forthright concision upsetting pragmati= st=20.Gnantucket ott vying biltmore coachmen bedbug philippine raffle noet= herian symphony=20,Lgregarious ceramic coypu tilde holster australia cornm= eal bertrand jackpot scan villa capital codfish delmarva birdwatch bassett= egypt utility bandstop=20.Lcolorado underclassman walsh handymen heretofo= re girth cravat elapse card faun signal cybernetics=20?Vchildbirth delve a= djectival brushy preclude perpendicular controversial cummins liquefy somn= olent amuse allure debra mourn=20.Gcurium guzzle bakelite traversable boon= chop wouldn't=20,Dhaley pease edify attestation crook ectoderm vindictive= retrovision reimburse magog cube brimful arrange=20.Gammonium lennox indi= spensable edwina collect stagy marina misanthropic galvanic reedy eject co= nifer histamine waters stepwise sulfa dolphin turk kirov nosebag freckle=20= ,Icharles handstand strong governess ribose dairymen applicable=20,Bfortra= n mountainside tortoise respect concur licensee archaic divulge incoherent= wadi busboy condensate prudent affectate betatron d'art whistleable buzzw= ord pelvic bimetallism=20.Mvagabond backlog roberto taxpaying mockery tocc= ata agrimony congener postposition blasphemy elijah chambermaid collate pe= rchlorate quintessence cocoon butterfly chloride sheave cartographer inexp= licable=20.Icamp cheerleader latera apr carmela slingshot shagbark beautif= ul fluctuate conscription swatch serology anita=20.Ncrop discomfit stinkpo= t befogging pastel different ywca caloric fields adams acquit congolese im= mutable summit run racketeer elope annulus andiron foliage arena coil depr= eciate dahlia=20,Xhedge haiku toward permitted dysentery brennan corrupt s= hame jacobs graham electrocardiogram arctic casein array=20.Qelite centaur= karma stem splotchy pellet did marrietta sulky cummings dive misanthropic= rifle sapiens echelon accrue antigorite delectable clang bernet cow moral= =20, Dclapboard horizontal bessel philodendron quartic courtier punk deliv= erance david asiatic consummate calculable colorado aventine bessie age do= dd notate moyer nod synopses xerography gangplank=20,Wfind blackstone astr= ophysics venus brig dickson logjam subterranean yeshiva amorous cloudy int= erference homeward rhombohedral upside buddy common discern acrobat jaguar= sunken floppy=20,Xwinnipeg story dapper effusion arcane flaxseed blast cl= oture ivan demitted seq anyhow justify confirmation connors banks crinkle = apprehension taboo ascertain day narrate seance fireplace contact=20.Jelec= troencephalogram yipping stew tennis hanford dyne brevity careworn convolu= te daisy potassium adrenal dade antonio=20,Mcomprehensive consensus delay = seagram accessible panic dear levin pique synapse magnuson epimorphism=20,= Uarpeggio norwegian northumberland coarsen gaines walrus leper demultiplex= aquarius winfield risen calculate geophysical dublin barrow brown brother= hood benelux bugeyed cleat tattoo ship melodious=20,Qtercel compliant biog= raphy titanate impropriety cotton acuity attach demigod bradford buckeye=20= Qtimbre grapevine ukraine ovenbird occult gurgle credulous squirehood pos= sess steve approach erratic darry guidebook auburn literature bestubble ch= ic how maltese=20.Mdough bemuse demountable caliper merlin kid top hygiene= couch=20.Gproteolysis ago anchor revelry rudyard beck soul virtuous befog= my educable mine sarcasm canvass actinometer aback asher buffoon=20?Tbute= ne impelled pinnate masturbate psychophysiology stafford belch cutout aris= tocracy symposia allotting beer crept bolo adonis bacon annals taxonomy br= anch brigham rupee solemnity=20.Pga trait despicable coachwork antigorite = mull pin blockade decimate mutiny structure forborne haitian transship cou= ncilmen declivity abut brainstorm amicable aurochs=20?Hpurse suicide dual = marianne slice explain each purvey deal harding andre=20,Jomission assigna= tion extrapolate symposium distributive forte qualify nicosia reservoir fe= rmion seismography principia=20,Zcudgel shed emigrate rinse bury unicorn p= araguay mexico quite chemise inversion abnormal cynic architectural corpsm= en indemnity exhaust erotica dervish decompress ralph=20.Ucircumspect daho= mey eyesore meticulous snyaptic bracelet diorama d charlemagne clausen tau= rus enquiry exodus baptism improvise dora petrify harriman crossover dwell= kerchief dimple=20.Rpowder duplex acrobatic yodel o'er=20,Tknockout oppon= ent thrice administrate drummond la wishy additive hillman invert chungkin= g harvard baptistery stink clank divulge chocolate sceptic adequate=20! ----32586532233872478-- From owner-ietf-openproxy@mail.imc.org Thu May 6 11:47: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 LAA21722 for ; Thu, 6 May 2004 11:47:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLl6L-0003QM-TU for opes-archive@ietf.org; Thu, 06 May 2004 11:47:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLl5K-0002wT-00 for opes-archive@ietf.org; Thu, 06 May 2004 11:46:55 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BLl4E-0002Ml-00 for opes-archive@ietf.org; Thu, 06 May 2004 11:45:46 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46FXmJ5077229; Thu, 6 May 2004 08:33:48 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i46FXmZL077228; Thu, 6 May 2004 08:33:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46FXlWK077219 for ; Thu, 6 May 2004 08:33:48 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20455; Thu, 6 May 2004 11:33:48 -0400 (EDT) Message-Id: <200405061533.LAA20455@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-openproxy@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-opes-ocp-core-05.txt Date: Thu, 06 May 2004 11:33:48 -0400 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,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Pluggable Edge Services Working Group of the IETF. Title : OPES Callout Protocol Core Author(s) : A. Rousskov Filename : draft-ietf-opes-ocp-core-05.txt Pages : 67 Date : 2004-5-5 This document specifies the core of the Open Pluggable Edge Services (OPES) Callout Protocol (OCP). OCP marshals application messages from other communication protocols: an OPES intermediary sends original application messages to a callout server; the callout server sends adapted application messages back to the processor. OCP is designed with typical adaptation tasks in mind (e.g., virus and spam management, language and format translation, message anonymization, or advertisement manipulation). OCP Core defined in this document consists of application-agnostic mechanisms essential for efficient support of typical adaptations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opes-ocp-core-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-opes-ocp-core-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-opes-ocp-core-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-5-6113544.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-opes-ocp-core-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-opes-ocp-core-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-6113544.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-openproxy@mail.imc.org Thu May 6 11:48:49 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 LAA21800 for ; Thu, 6 May 2004 11:48:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLl7D-0003u8-Cu for opes-archive@ietf.org; Thu, 06 May 2004 11:48:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLl6A-0003Og-00 for opes-archive@ietf.org; Thu, 06 May 2004 11:47:47 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BLl59-0002r1-00 for opes-archive@ietf.org; Thu, 06 May 2004 11:46:43 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46FXxWe077242; Thu, 6 May 2004 08:33:59 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i46FXxvY077241; Thu, 6 May 2004 08:33:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46FXwqj077235 for ; Thu, 6 May 2004 08:33:59 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20483; Thu, 6 May 2004 11:33:59 -0400 (EDT) Message-Id: <200405061533.LAA20483@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-openproxy@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-opes-end-comm-07.txt Date: Thu, 06 May 2004 11:33:59 -0400 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,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Pluggable Edge Services Working Group of the IETF. Title : OPES entities and end points communication Author(s) : A. Barbir Filename : draft-ietf-opes-end-comm-07.txt Pages : 21 Date : 2004-5-5 This memo documents tracing and non-blocking (bypass) requirements for Open Pluggable Edge Services (OPES). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opes-end-comm-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-opes-end-comm-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-opes-end-comm-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-5-6113551.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-opes-end-comm-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-opes-end-comm-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-6113551.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-openproxy@mail.imc.org Thu May 6 14:48:54 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 OAA10606 for ; Thu, 6 May 2004 14:48:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLnvT-00035G-4w for opes-archive@ietf.org; Thu, 06 May 2004 14:48:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLnuV-0002ff-00 for opes-archive@ietf.org; Thu, 06 May 2004 14:47:59 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BLnsv-0001tA-00 for opes-archive@ietf.org; Thu, 06 May 2004 14:46:17 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46IVgfH005831; Thu, 6 May 2004 11:31:42 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i46IVgne005829; Thu, 6 May 2004 11:31:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46IVeL7005820 for ; Thu, 6 May 2004 11:31:41 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i46IV1D27488; Thu, 6 May 2004 14:31:01 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 May 2004 14:31:01 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754096D020F@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: "'internet-drafts@ietf.org'" Cc: "'ietf-openproxy@imc.org'" , "Abbie Barbir" , "'Markus Hofmann'" , "'Marshall Rose'" Subject: Request to publish: draft-ietf-opes-end-comm-08 Date: Thu, 6 May 2004 14:31:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C43398.45F9235C" 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,HTML_MESSAGE, LINES_OF_YELLING autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C43398.45F9235C Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43398.45F9235C" ------_=_NextPart_001_01C43398.45F9235C Content-Type: text/plain Please publish the following draft-ietf-opes-end-comm-08 as a WG Draft. PS: This version addresses Ted's remarks. Thanks Abbie ------_=_NextPart_001_01C43398.45F9235C Content-Type: text/html Request to publish: draft-ietf-opes-end-comm-08

    Please publish the following

    draft-ietf-opes-end-comm-08

    as a WG Draft.


    PS: This version addresses Ted's remarks.


    Thanks
    Abbie

      ------_=_NextPart_001_01C43398.45F9235C-- ------_=_NextPart_000_01C43398.45F9235C Content-Type: text/plain; name="draft-ietf-opes-end-comm-08.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-opes-end-comm-08.txt" Content-Transfer-Encoding: quoted-printable Open Pluggable Edge Services A. = Barbir Internet-Draft Nortel = Networks Expires: November 4, 2004 May 6, = 2004 OPES entities and end points communication draft-ietf-opes-end-comm-08 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that = other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six = months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 4, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This memo documents tracing and non-blocking (bypass) requirements for Open Pluggable Edge Services (OPES). Barbir Expires November 4, 2004 [Page = 1] =0C Internet-Draft OPES entities and end points communication May = 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . = 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . = 3 2. OPES System . . . . . . . . . . . . . . . . . . . . . . . . . = 4 3. Tracing Requirements . . . . . . . . . . . . . . . . . . . . . = 5 3.1 Traceable entities . . . . . . . . . . . . . . . . . . . . = 5 3.2 System requirements . . . . . . . . . . . . . . . . . . . = 6 3.3 Processor requirements . . . . . . . . . . . . . . . . . . = 6 3.4 Callout server requirements . . . . . . . . . . . . . . . = 7 4. Bypass (Non-blocking feature) Requirements . . . . . . . . . . = 8 4.1 Bypassable entities . . . . . . . . . . . . . . . . . . . = 9 4.2 System requirements . . . . . . . . . . . . . . . . . . . = 9 4.3 Processor requirements . . . . . . . . . . . . . . . . . . = 10 4.4 Callout server requirements . . . . . . . . . . . . . . . = 10 5. Protocol Binding . . . . . . . . . . . . . . . . . . . . . . . = 11 6. Compliance Considerations . . . . . . . . . . . . . . . . . . = 12 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . = 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . = 14 8.1 Tracing security considerations . . . . . . . . . . . . . = 14 8.2 Bypass security considerations . . . . . . . . . . . . . . = 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . = 17 9.1 Normative References . . . . . . . . . . . . . . . . . . . . = 17 9.2 Informative References . . . . . . . . . . . . . . . . . . . = 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . = 18 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . = 19 Intellectual Property and Copyright Statements . . . . . . . . = 20 Barbir Expires November 4, 2004 [Page = 2] =0C Internet-Draft OPES entities and end points communication May = 2004 1. Introduction The Open Pluggable Edge Services (OPES) architecture [1] enables cooperative application services (OPES services) between a data provider, a data consumer, and zero or more OPES processors. The application services under consideration analyze and possibly transform application-level messages exchanged between the data provider and the data consumer. This work specifies OPES tracing and bypass functionality. The architecture document [1] requires that tracing is supported = in-band. This design goal limits the type of application protocols that OPES can support. The details of what a trace record can convey are also dependent on the choice of the application level protocol. For these reasons, this work only documents requirements for OPES entities = that are needed to support traces and bypass functionality. The task of encoding tracing and bypass features is application protocol specific. Separate documents will address HTTP and other protocols. The architecture does not prevent implementers from developing out-of-band protocols and techniques to address tracing and bypass. Such protocols are out of scope of the current work. 1.1 Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. When used with the normative meanings, these keywords will be all uppercase. Occurrences of these words in lowercase comprise normal prose usage, with no normative implications. Barbir Expires November 4, 2004 [Page = 3] =0C Internet-Draft OPES entities and end points communication May = 2004 2. OPES System This sections provides a definition of OPES System. This is needed = in order to define what is traceable (or bypassable) in an OPES Flow. Definition: An OPES System is a set of all OPES entities authorized by either the data provider or the data consumer application to process a given application message. The nature of the authorization agreement determines if authority delegation is transitive (meaning an authorized entity is authorized to include other entities). If specific authority agreements allow for re-delegation, an OPES system can be formed by induction. In this case, an OPES system starts with entities directly authorized by a data provider (or a data consumer) application. The OPES system then includes any OPES entity authorized by an entity that is already in the OPES system. The authority delegation is always viewed in the context of a given application message. An OPES System is defined on an application message basis. Having an authority to process a message does not imply being involved in message processing. Thus, some OPES system members may not participate in processing of a message. Similarly, some members may process the same message several times. The above definition implies that there can be no more than two OPES systems [Client-side and server-side OPES systems can process the same message at the same time] processing the same message at a = given time. This is based on the assumption that there is a single data provider and a single data consumer as far as a given application message is concerned. For example, consider a Content Delivery Network (CDN) delivering an image on behalf of a busy web site. OPES processors and services = that the CDN uses to adapt and deliver the image comprise an OPES System. In a more complex example, an OPES System would contain third party OPES entities that the CDN engages to perform adaptations (e.g., to adjust image quality). Barbir Expires November 4, 2004 [Page = 4] =0C Internet-Draft OPES entities and end points communication May = 2004 3. Tracing Requirements The definition of OPES trace and tracing are given next. OPES trace: application message information about OPES entities that adapted the message. OPES tracing: the process of creating, manipulating, or interpreting an OPES trace. Note that the above trace definition assumes in-band tracing. This dependency can be removed if desired. Tracing is performed on per message basis. Trace format is dependent on the application protocol that is being adapted. A traceable entity can appear multiple times in a trace (for example, every time it acts on a message). 3.1 Traceable entities This section focuses on identifying traceable entities in an OPES Flow. Tracing information provides an "end" with information about OPES entities that adapted the data. There are two distinct uses of OPES traces. First, a trace enables an "end" to detect the presence of OPES System. Such "end" should be able to see a trace entry, but = does not need to be able to interpret it beyond identification of the = OPES System and location of certain required OPES-related disclosures = (see Section 3.2). Second, the OPES System administrator is expected to be able to interpret the contents of an OPES trace. The trace can be relayed to the administrator by an "end" without interpretation, as opaque data (e.g., a TCP packet or an HTTP message snapshot). The administrator can use the trace information to identify the participating OPES entities. The administrator can use the trace to identify the = applied adaptation services along with other message-specific information. Since the administrators of various OPES Systems can have various ways of looking into tracing, they require the freedom in what to = put in trace records and how to format them. At the implementation level, for a given trace, an OPES entity involved in handling the corresponding application message is traceable or traced if information about it appears in that trace. This work does not specify any order to that information. The order of information in a trace can be OPES System specific or can be defined by application bindings documents. OPES entities have different levels of traceability requirements. Specifically, Barbir Expires November 4, 2004 [Page = 5] =0C Internet-Draft OPES entities and end points communication May = 2004 o An OPES System MUST add its entry to the trace. o An OPES processor SHOULD add its entry to the trace. o An OPES service MAY add its entry to the trace. o An OPES entity MAY delegate addition of its trace entry to = another OPES entity. For example, an OPES System can have a dedicated = OPES processor for adding System entries; an OPES processor can use a callout service to manage all OPES trace manipulations (since = such manipulations are OPES adaptations). In an OPES context, a good tracing approach is similar to a trouble ticket ready for submission to a known address. The address is printed on the ticket. The trace in itself is not necessarily a detailed description of what has happened. It is the responsibility of the operator to decode trace details and to resolve the problems. 3.2 System requirements The following requirements document actions when forming an OPES System trace entry: o OPES system MUST include its unique identification in its trace entry. Here, uniqueness scope is all OPES Systems that may adapt the message being traced. o An OPES System MUST define its impact on inter- and = intra-document reference validity. o An OPES System MUST include information about its privacy policy, including identity of the party responsible for setting and enforcing the policy. o An OPES System SHOULD include information that identifies, to the technical contact, the OPES processors involved in processing = the message. o When providing required information, an OPES System MAY use a single URI to identify a resource containing several required items. For example, an OPES System can point to a single web page with a reference to System privacy policy and technical contact information. This specification does not define the meaning of the terms privacy policy, policy enforcement, or reference validity or technical contact and contains no requirements regarding encoding, language, format, or any other aspects of that information. For example, a URI used for an OPES System trace entry may look like "http:// www.examplecompany.com/opes/?client=3Dexample.com" where the = identified web page is dynamically generated and contains the all OPES System information required above. 3.3 Processor requirements The following requirements document actions when forming an OPES Barbir Expires November 4, 2004 [Page = 6] =0C Internet-Draft OPES entities and end points communication May = 2004 System trace entry: o OPES processor SHOULD add its unique identification to the trace. Here, uniqueness scope is the OPES System containing the processor. 3.4 Callout server requirements In an OPES system, it is the task of an OPES processor to add trace records to application messages. The OPES System administrator decides if and under what conditions callout servers may add trace information to application messages. Barbir Expires November 4, 2004 [Page = 7] =0C Internet-Draft OPES entities and end points communication May = 2004 4. Bypass (Non-blocking feature) Requirements IAB recommendation (3.3) [6] requires that the OPES architecture = does not prevent a data consumer application from retrieving non-OPES version of content from a data provider application, provided that the non-OPES content exists. IAB recommendation (3.3) suggests that the Non-blocking feature (bypass) be used to bypass faulty OPES intermediaries (once they have been identified, by some method). In addressing IAB consideration (3.3), one need to specify what constitutes non-OPES content. In this work the definition of "non-OPES" content is provider dependent. In some cases, the availability of "non-OPES" content can be a function of the internal policy of a given organization that has contracted the services of = an OPES provider. For example, Company A has as contract with an OPES provider to perform virus checking on all e-mail attachments. An employee X of Company A can issue a non-blocking request for the virus scanning service. The request could be ignored by the OPES provider since it contradicts its agreement with Company A. The availability of non-OPES content can be a function of content providers (or consumers or both) policy and deployment scenarios = [5]. For this reason, this work does not attempt to define what is an = OPES content as opposed to non-OPES content. The meaning of OPES versus non-OPES content is assumed to be determined through various agreements between the OPES provider, data provider and/or data consumer. The agreement determines what OPES services can be = bypassed and in what order (if applicable). This specification documents bypassing of an OPES service or a group of services identified by a URI. In this context, to "bypass the service" for a given application message in an OPES Flow means to "not invoke the service" for that application message. A bypass URI that identifies an OPES system (processor) matches all services attached to that OPES system (processor). However, bypassing of OPES processors and OPES Systems themselves requires non-OPES mechanisms and is out of this specification scope. A bypass request an instruction to bypass, usually embedded in an application message. The current specification does not provide for a good mechanism that allow and "end" to specify to "bypass this service but only if it is a part of that OPES system" or "bypass all services of that OPES system but not of this OPES system". Furthermore, if an OPES processor does not know for sure that a bypass URI does not match = its service, it must bypass that service. If no non-OPES content is available without the specified service, the bypass request for that service must be ignored. This design Barbir Expires November 4, 2004 [Page = 8] =0C Internet-Draft OPES entities and end points communication May = 2004 implies that it may not be possible to detect non-OPES content existence or to detect violations of bypass rules in the = environments where the tester does not know whether non-OPES content exists. This design assumes that most bypass requests are intended for situations where serving undesirable OPES content is better than serving an error message that no preferred non-OPES content exists. Bypass feature is to malfunctioning OPES services as HTTP "reload" request is to malfunctioning HTTP caches. The primary purpose of the bypass is to get usable content in the presence of service failures and not to provide the content consumer with more information on = what is going on. OPES trace should be used for the latter instead. While this work defines a "bypass service if possible" feature, = there are other related bypass features that can be implemented in OPES and/or in application protocols being adapted. For example, a = "bypass service or generate an error" or "bypass OPES entity or generate an error". Such services would be useful for debugging broken OPES systems and may be defined in other OPES specifications. This work concentrates on documenting a user-level bypass feature addressing direct IAB concerns. 4.1 Bypassable entities In this work, the focus is on developing a bypass feature that allow a user to instruct the OPES System to bypass some or all of its services. The collection of OPES services that can be bypassed is a function of the agreement of the OPES provider with either (or both) the content provider or the content consumer applications. In the general case, a bypass request is viewed as a bypass instruction = that contains a URI that identifies an OPES entity or a group of OPES entities that perform a service (or services) to be bypassed. An instruction may contain more than one such URI. A special wildcard identifier can be used to represent all possible URIs. In an OPES Flow, a bypass request is processed by each involved OPES processor. This means that an OPES processor examines the bypass instruction and if non-OPES content is available, the processor then bypasses the indicated services. The request is then forwarded to = the next OPES processor in the OPES Flow. The next OPES processor would then handle all bypass requests, regardless of the previous = processor actions. The processing chain continues throughout the whole processors that are involved in the OPES Flow. 4.2 System requirements In an OPES System bypass requests are generally client centric (originated by the data consumer application) and go in the opposite Barbir Expires November 4, 2004 [Page = 9] =0C Internet-Draft OPES entities and end points communication May = 2004 direction of tracing requests. This work requires that the bypass feature be performed in-band as an extension to an application specific protocol. Non-OPES entities should be able to safely ignore these extensions. The work does not prevent OPES Systems from developing their own out of band protocols. The following requirements apply for bypass feature as related to an OPES System (the availability of a non-OPES content is a precondition) : o An OPES System MUST support a bypass feature. This means that the OPES System bypasses services whose URIs are identified by an = OPES "end". o An OPES System MUST provide OPES version of the content if non-OPES version is not available. In order to facilitate the debugging (or data consumer user experience) of the bypass feature in an OPES System, it would be beneficial if non-bypassed entities include information related to why they ignored the bypass instruction. It is important to note = that in some cases the tracing facility itself may be broken and the = whole OPES System (or part) may need to be bypassed through the issue of a bypass instruction. 4.3 Processor requirements Bypass requirements for OPES processors are (the availability of a non-OPES content is a precondition): o OPES processor SHOULD be able to interpret and process a bypass instruction. This requirement applies to all bypass instructions, including those that identify unknown-to-recipient services. o OPES processors MUST forward bypass request to the next application hop provided that the next hop speaks application protocol with OPES bypass support. o OPES processor SHOULD be able to bypass it's service(s) = execution. OPES processors that know how to process and interpret a bypass instruction have the following requirements: o The recipient of a bypass instruction with a URI that does not identify any known-to-recipient OPES entity MUST treat that URI = as a wildcard identifier (meaning bypass all applicable services). 4.4 Callout server requirements In an OPES system, it is the task of an OPES processor to process bypass requests. The OPES System administrator decides if and under what conditions callout servers process bypass requests. Barbir Expires November 4, 2004 [Page = 10] =0C Internet-Draft OPES entities and end points communication May = 2004 5. Protocol Binding The task of encoding tracing and bypass features is application protocol specific. Separate documents will address HTTP and other protocols. These documents must address the ordering of trace information if needed. Barbir Expires November 4, 2004 [Page = 11] =0C Internet-Draft OPES entities and end points communication May = 2004 6. Compliance Considerations This specification defines compliance for the following compliance subjects: OPES System, processors, entities and callout servers. A compliance subject is compliant if it satisfies all applicable "MUST" and "SHOULD" level requirements. By definition, to satisfy a "MUST" level requirement means to act as prescribed by the requirement; to satisfy a "SHOULD" level requirement means to either act as prescribed by the requirement or have a reason to act differently. A requirement is applicable to the subject if it instructs (addresses) the subject. Informally, compliance with this draft means that there are no known "MUST" violations, and all "SHOULD" violations are conscious. In other words, a "SHOULD" means "MUST satisfy or MUST have a reason to violate". It is expected that compliance claims are accompanied by = a list of unsupported SHOULDs (if any), in an appropriate format, explaining why preferred behavior was not chosen. Only normative parts of this specification affect compliance. Normative parts are: parts explicitly marked using the word "normative", definitions, and phrases containing unquoted = capitalized keywords from [RFC2119]. Consequently, examples and illustrations = are not normative. Barbir Expires November 4, 2004 [Page = 12] =0C Internet-Draft OPES entities and end points communication May = 2004 7. IANA considerations This specification contains no IANA considerations. Application bindings MAY contain application-specific IANA considerations. Barbir Expires November 4, 2004 [Page = 13] =0C Internet-Draft OPES entities and end points communication May = 2004 8. Security Considerations Security considerations for OPES are documented in [4]. Policy and authorization issues are documented in [3]. It is recommended that designers consult these documents before reading this section. This document is a requirement document for tracing and bypass feature. The requirements that are stated in this document can be used to extend an application level protocol to support these features. As such, the work has security precautions. 8.1 Tracing security considerations The tracing facility for OPES architecture is implemented as a protocol extension. Inadequate implementations of the tracing facility may defeat safeguards built into the OPES architecture. The tracing facility by itself can become a target of malicious attacks or used to lunch attacks on an OPES System. Threats caused by or against the tracing facility can be viewed as threats at the application level in an OPES Flow. In this case, the threats can affect the data consumer and the data provider application. Since tracing information is a protocol extension, these traces can be injected in the data flow by non-OPES entities. In this case, there are risks that non-OPES entities can be compromised in a fashion that threat the overall integrity and effectiveness of an OPES System. For example, a non-OPES proxy can add fake tracing information into a trace. This can be done in the form of wrong, or unwanted, or non existent services. A non-OPES entity can inject large size traces that may cause buffer overflow in a data consumer application. The same threats can arise from compromised OPES entities. An attacker can control an OPES entity and inject wrong, = or very large trace information that can overwhelm an end or the next OPES entity in an OPES flow. Similar threats can result from bad implementations of the tracing facility in trusted OPES entities. Compromised tracing information can be used to launch attacks on an OPES System that give the impression that unwanted content transformation was performed on the data. This can be achieved by inserting wrong entity (such OPES processor) identifiers. A compromised trace can affect the overall message integrity = structure. This can affect entities that use message header information to perform services such as accounting, load balancing, or reference-based services. Compromised trace information can be used to launch DoS attacks that Barbir Expires November 4, 2004 [Page = 14] =0C Internet-Draft OPES entities and end points communication May = 2004 can overwhelm a data consumer application or an OPES entity in an OPES Flow. Inserting wrong tracing information can complicates the debugging tasks performed by system administrator during trouble shooting of OPES System behavior. As a precaution, OPES entities ought to be capable of verifying that the inserted traces are performed by legal OPES entities. This can = be done as part of the authorization and authentication face. Policy = can be used to indicate what trace information can be expected from a peer entity. Other application level related security concerns can = be found in [4]. 8.2 Bypass security considerations The bypass facility for OPES architecture is implemented as a protocol extension. Inadequate implementations of the bypass = facility may defeat safeguards built into the OPES architecture. The bypass facility by itself can become a target of malicious attacks or used to lunch attacks on an OPES System. Threats caused by or against the bypass facility can be viewed as threats at the application level in an OPES Flow. In this case, the threats can affect the data consumer and the data provider application. There are risks for the OPES System by non-OPES entities, whereby, these entities can insert bypass instructions into the OPES Flow. = The threat can come from compromised non-OPES entities. The threat might affect the overall integrity and effectiveness of an OPES System. = For example, a non-OPES proxy can add bypass instruction to bypass legitimate OPES entities. The attack might result in overwhelming = the original content provider servers, since the attack essentially bypass any load balancing techniques. In addition, such an attack is also equivalent to a DoS attack, whereby, a legitimate data consumer application may not be able to access some content from a content provider or its OPES version. Since an OPES Flow may include non-OPES entities, it is susceptible to man-in-the-middle attacks, whereby an intruder may inject bypass instructions into the data path. These attacks may affect content availability or disturb load balancing techniques in the network. The above threats can also arise by compromised OPES entities. An intruder can compromise an OPES entities and then use man-in-the-middle techniques to disturb content availability to a data consumer application or overload a content provider server (essentially, some form of a DoS attack). Barbir Expires November 4, 2004 [Page = 15] =0C Internet-Draft OPES entities and end points communication May = 2004 Attackers can use the bypass instruction to affect the overall integrity of the OPES System. The ability to introduce bypass instructions into a data flow may effect the accounting of the OPES System. It may also affect the quality of content that is delivered to the data consumer applications. Similar threats can arise from = bad implementations of the bypass facility. Inconsistent or selective bypass is also a threat. Here, one end can try to bypass a subset of OPES entities so that the resulting = content is malformed and crashes or compromises entities that process that content (and expect that content to be complete and valid). Such exceptions are often not tested because implementers do not expect a vital service to disappear from the processing loop. Other threats can arise from configuring access control policies for OPES entities. It is possible that systems implementing access controls via OPES entities may be incorrectly configured to honor bypass and, hence, give unauthorized access to intruders. Tap bypass can also be a threat. This is because systems = implementing wiretaps via OPES entities may be incorrectly configured to honor bypass and, hence, ignore (leave undetected) traffic with bypass instructions that should have been tapped or logged. It is also possible for one end to bypass services such as virus scanning at = the receiving end. This threat can be used by hackers to inject viruses throughout the network. Following an IETF policy on Wiretapping = [7], OPES communication model does not consider wiretapping requirements. Nevertheless, the documented threat is real, not obvious, and OPES technology users operating in wiretapping or similar logging environments should be aware of it. Other application level related security concerns can be found in [4]. Barbir Expires November 4, 2004 [Page = 16] =0C Internet-Draft OPES entities and end points communication May = 2004 9. References 9.1 Normative References [1] A. Barbir et al., "An Architecture for Open Pluggable Edge Services (OPES)", Internet-Draft http://www.ietf.org/ internet-drafts/draft-ietf-opes-architecture-04, December = 2002. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [3] A. Barbir et al., "Policy, Authorization and Enforcement Requirements of OPES", Internet-Draft http://www.ietf.org/ internet-drafts/draft-ietf-opes-authorization-02.txt, February 2003. [4] A. Barbir et al., "Security Threats and Risks for Open = Pluggable Edge Services", Internet-Draft http://www.ietf.org/ internet-drafts/draft-ietf-opes-threats-02.txt, February 2003. 9.2 Informative References [5] A. Barbir et al., "OPES Use Cases and Deployment Scenarios", Internet-Draft http://www.ietf.org/internet-drafts/ draft-ietf-opes-scenarios-01.txt, August 2002. [6] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002. [7] IAB, IESG., "IETF Policy on Wiretapping", RFC 2804, May 2000. [8] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, = L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [9] Rousskov, A. et al, "HTTP adaptation with OPES", = Internet-Draft http://www.ietf.org/internet-drafts/ draft-ietf-opes-http-01.txt, October 2003. [10] A. Barbir et al., "OPES Treatment of IAB Considerations", Internet-Draft http://www.ietf.org/internet-drafts/ draft-ietf-opes-iab-03.txt, October 2003. Barbir Expires November 4, 2004 [Page = 17] =0C Internet-Draft OPES entities and end points communication May = 2004 Author's Address Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean, Ontario K2H 8E9 Canada Phone: +1 613 763 5229 EMail: abbieb@nortelnetworks.com Barbir Expires November 4, 2004 [Page = 18] =0C Internet-Draft OPES entities and end points communication May = 2004 Appendix A. Acknowledgements Several people has contributed to this work. Many thanks to: Alex Rousskov, Hilarie Orman, Oscar Batuner, Markus Huffman, Martin Stecher, Marshall Rose and Reinaldo Penno. Barbir Expires November 4, 2004 [Page = 19] =0C Internet-Draft OPES entities and end points communication May = 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances = of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification = can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph = are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Barbir Expires November 4, 2004 [Page = 20] =0C Internet-Draft OPES entities and end points communication May = 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Barbir Expires November 4, 2004 [Page = 21] =0C ------_=_NextPart_000_01C43398.45F9235C-- From SDAOTYEC@e-mails.ru Fri May 7 16:23:32 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 QAA17967 for ; Fri, 7 May 2004 16:23:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMBsb-0007Jh-7v for opes-archive@ietf.org; Fri, 07 May 2004 16:23:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMBrH-0006oO-00 for opes-archive@ietf.org; Fri, 07 May 2004 16:22:12 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BMBqb-0006Oz-00 for opes-archive@ietf.org; Fri, 07 May 2004 16:21:29 -0400 Received: from cs242221-128.houston.rr.com ([24.242.221.128]) by mx2.foretec.com with smtp (Exim 4.24) id 1BMBoo-0005rv-Pj for opes-archive@ietf.org; Fri, 07 May 2004 16:19:39 -0400 Received: from 67.220.96.10 by 24.242.221.128; Fri, 07 May 2004 21:22:36 +0300 Message-ID: From: "Kyle Youngblood" Reply-To: "Kyle Youngblood" To: opes-archive@ietf.org Subject: Blowout Prices- Only 24 Hours Dont Miss This! - oak Date: Sat, 08 May 2004 00:19:36 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--598978516212488" X-IP: 148.123.28.83 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.4 required=5.0 tests=BIZ_TLD,HTML_70_80, HTML_FONTCOLOR_UNKNOWN,HTML_FONT_BIG,HTML_IMAGE_ONLY_10,HTML_MESSAGE, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----598978516212488 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable =

    Never Befor= e Seen Prices Slashed 90% Or More.
    This Special Limited Time Offe.r Wi= ll Expire in 24 Hours! So Get Yours Now!

    DON'T WAIT CLIC.K HERE NO.W= TO BU.Y TODAY
    AND GET THESE SPECIAL RATE.S!

    =
    PageMaker 7 (2CD)Retail price: $420Our Price: $60.00You Save= : $360.00
    Microsoft Visual Studio.NET Architect Edition Retail price:= $2499.99 Our Price: $200.00 You Save: $2299.99
    Delphi 7 Retail price: $404.99 Our Price: $60.00 You Sav= e: $344.99
    Microsoft MSDN Library Retail price: $270.99 Our Price: $70.00 You Save: $200.99
    MS Money 2004 Retail price: $130Our Price: $60.00You Save: $= 80.00
    MS Plus! XP Retail price: $99.99 Our Price: $50.00You Save: = $49.99
    Adobe Illustrator 10 Retail price: $270.99 Our Price: $60.00 You Save: $210.00
    Adobe In Design 2.0 Retail price: $270.99 Our Price: $80.00 You Save: $190.99
    Microsoft Office XP Professional Retail price: $579.99 Our Price: $50.00 You Save: $510.00


    ----598978516212488-- From JamarcusConn0240@collegeclub.com Fri May 7 20:54:18 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 UAA01635 for ; Fri, 7 May 2004 20:54:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMG6d-000744-5M for opes-archive@ietf.org; Fri, 07 May 2004 20:54:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMG5d-0006cn-00 for opes-archive@ietf.org; Fri, 07 May 2004 20:53:18 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BMG4o-0006Cs-00 for opes-archive@ietf.org; Fri, 07 May 2004 20:52:26 -0400 Received: from c68.114.233.221.fdl.wi.charter.com ([68.114.233.221]) by mx2.foretec.com with smtp (Exim 4.24) id 1BMG4n-0000RE-Rq for opes-archive@ietf.org; Fri, 07 May 2004 20:52:26 -0400 Date: Fri, 07 May 2004 21:43:18 -0400 From: "Beulah Deremer" X-Priority: 3 (Normal) To: opes-archive@ietf.org Subject: Fwd: this works MIME-Version: 1.0 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Message-Id: 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.0 required=5.0 tests=FROM_ENDS_IN_NUMS,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_IMAGE_ONLY_06,HTML_IMAGE_RATIO_04, HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,PRIORITY_NO_NAME autolearn=no version=2.60 X-Spam-Report: * 0.9 FROM_ENDS_IN_NUMS From: ends in numbers * 0.9 HTML_IMAGE_RATIO_04 BODY: HTML has a low ratio of text to image area * 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.1 HTML_FONTCOLOR_BLUE BODY: HTML font color is blue * 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 * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer Content-Transfer-Encoding: quoted-printable




    On the 20th of July, 1866, the steamer Governor Higginson= , of the Calcutta and Burnach Steam Navigation Company, had met this movin= g mass five miles off the east coast of Australia; Conseil argued on this = supposition, and laid his plans accordingly! But one of them, the captain = of the Monroe, knowing that Ned Land had shipped on board the Abraham Linc= oln, begged for his help in chasing a whale they had in sight!!! "If, on t= he contrary, we do know all living kinds, we must necessarily seek for the= animal in question amongst those marine beings already classed; and, in t= hat case, I should be disposed to admit the existence of a gigantic narwha= l.=20pontific From Administration@computeradmin.org Mon May 10 21:25: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 VAA20971 for ; Mon, 10 May 2004 21:25:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNM1D-0002LH-Uq for opes-archive@ietf.org; Mon, 10 May 2004 21:25:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNM0N-00020t-00 for opes-archive@ietf.org; Mon, 10 May 2004 21:24:23 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BNLzL-0001fj-00 for opes-archive@ietf.org; Mon, 10 May 2004 21:23:19 -0400 Received: from [208.60.220.107] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1BNLzM-0008Up-2G for opes-archive@ietf.org; Mon, 10 May 2004 21:23:22 -0400 Received: from 2gc43.sztt6s.net [15.65.81.208] by 65.246.255.50; Tue, 11 May 2004 00:25:25 -0200 Message-ID: <2$p$uuj9w286d80chj0h419@l9k8.btg.y8> From: "Admin" To: est@ietf.org Subject: ADV: Attention All School Staff: Teachers, Students and Faculty Members: Date: Tue, 11 May 04 00:25:25 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 5.50.4133.2400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="F2E25586CA63" 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.1 required=5.0 tests=ADVERT_CODE, DATE_SPAMWARE_Y2K,FORGED_MUA_OUTLOOK,FORGED_RCVD_NET_HELO, MISSING_MIMEOLE,RCVD_NUMERIC_HELO,SUBJ_HAS_SPACES, X_MSMAIL_PRIORITY_HIGH,X_PRIORITY_HIGH autolearn=no version=2.60 X-Spam-Report: * 0.5 X_PRIORITY_HIGH Sent with 'X-Priority' set to high * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.5 X_MSMAIL_PRIORITY_HIGH Sent with 'X-Msmail-Priority' set to high * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 1.6 ADVERT_CODE Subject: starts with advertising tag * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 3.0 FORGED_RCVD_NET_HELO Host HELO'd using the wrong IP network * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook This is a multi-part message in MIME format. --F2E25586CA63 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Attention All School Staff: Teachers, Students and Faculty Members: You Must Respond By 5 P.M. Wednesday, May 12, 2004. Through a special arrangement, Avtech Direct is offering a limited allotment of BRAND NEW, top of-the-line, name-brand desktop computers at more than 50% off MSRP to all Teachers, Students,Faculty and Staff, who respond to this message before 5 P.M., Wednesday, May 12, 2004. All desktop are brand-new, packed in their original boxes, and come with a full manufacturer's warranty plus a 100% satisfaction guarantee. These professional grade Desktops are fully equipped with 2004 next generation technology, making these the best performing computers money can buy. Avtech Direct is offering these feature rich, top performing Desktop Computers with the latest Intel technology at an amazing price to all who call: 1-800-884-9510 by 5 P.M. Wednesday, May 12, 2004 The fast and powerful AT-2400 series Desktop features: * Intel 2.0Ghz Processor for amazing speed and performance * 128MB DDR RAM, --- Upgradeable to 1024 * 20 GB UDMA Hard Drive, --- Upgradeable to 80 GB * 52X CD-Rom Drive, --- Upgradeable to DVD/CDRW * 1.44 Floppy disk drive * Next Generation Technology * ATI Premium video and sound * Full Connectivity with Fax modem/Lan/IEE 1394/USB 2.0 * Soft Touch Keyboard and scroll mouse * Internet Ready * Network Ready * 1 Year parts and labor warranty * Priority customer service and tech support MSRP $699 ........................................ Your Cost $297 How to qualify: 1. You must be a Teacher, Student, Faculty or Staff Member: 2. All desktop computers will be available on a first come first serve basis. 3. You must call 1-800-884-9510 by 5 P.M. Wednesday, May 12, 2004 and we will hold the desktops you request on will call. 4. You are not obligated in any way. 5. 100% Satisfaction Guaranteed. Call Avtech Direct 1-800-884-9510 before 5 P.M. Wednesday, May 12, 2004 If you wish to unsubscribe from this list, please go to: http://www.computeradvice.org/unsubscribe.asp --F2E25586CA63-- From sbdezbwtbnk@noc.titech.ac.jp Tue May 11 13:31: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 NAA10561 for ; Tue, 11 May 2004 13:31:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNb6k-0005F7-LE for opes-archive@ietf.org; Tue, 11 May 2004 13:31:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNb5k-0004nM-00 for opes-archive@ietf.org; Tue, 11 May 2004 13:30:57 -0400 Received: from c-67-172-76-251.client.comcast.net ([67.172.76.251]) by ietf-mx with smtp (Exim 4.12) id 1BNb4C-0003X1-00; Tue, 11 May 2004 13:29:25 -0400 Received: from 80.18.12.164 by 4.11.114.195; Tue, 11 May 2004 23:21:49 +0500 Message-ID: From: "Deandre Mcqueen" Reply-To: "Deandre Mcqueen" To: owner-ietf@ietf.org, olicy@ietf.org, opes-archive@ietf.org, ops-chairs@ietf.org Subject: Our subscribers profit like the pros Date: Tue, 11 May 2004 20:26:49 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--F740FE4752057E13" X-Priority: 5 X-IP: 80.232.198.181 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.5 required=5.0 tests=HTML_MIME_NO_HTML_TAG, LINES_OF_YELLING,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,PRIORITY_NO_NAME autolearn=no version=2.60 ----F740FE4752057E13 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable **SRGE***SRGE***SRGE***SRGE***SRGE***SRGE** Market Undervalue Opening Price: 1.00 7 Day Target: 2.65 1 Month Target: 3.80 Outstanding Shares: 16.5 million Public Float: 3.4 million Explosive short term trading profits in a new technology issue (Ticker: SRGE) are being predicted for May 11-May 17 as many significant news releases indicate strong contractual revenues with major Telecom firms. MAJOR ANNOUNCEMENTS AND HUGE NEWSLETTER COVERAGE THIS WEEK FOR SRGE! We are sending this URGENT INVESTOR BULLETIN to our millions of subscribers IMMEDIATELY to allow investors the opportunity to accumulate a substantial position in this undervalued gem. Surge Technologies Corp. (SRGE) is the latest new pick where the stage is set for a tremendous advance. This company deserves your immediate attention! Stock Mogul Team found a new winner yet again! SRGE has been successfully working with Telecommunications giants (with five million subscriber lines) over the last 4 years, but is now projecting "a banner expansion year with geometric growth in revenues" due largely to sales demands for their innovative patented products and expansion into International telecom markets. Surge Technologies, Inc. (SRGE) is a cutting-edge leader that designs, develops, manufactures, and markets superior patented outside plant electrical surge protection equipment for the telecommunications industry. The US sales projections for this market are $4 Billion annually, with this figure growing rapidly as the expansion of new HDSL and ADSL technologies permeate the industry. SRGE just announced two major contracts totaling $5 Million, making their shares grossly undervalued based upon conservative EPS estimates. This is just the tip of the iceberg and we expect a continuous flow of huge news announcements detailing the highly profitable chain of events to follow for SRGE in the near future. We can state from our judicious research that we are not alone in viewing SRGE as one of those extremely rare opportunities where the impact of major news events simultaneously boosts the value of a company while ultimately providing substantial reward for its shareholders. SRGE provides the Telecom industry with the highest quality "protection element" for complex digital switches. Protecting these Telecom switching devices is crucial to inclusive components that are sensitive to interruptions in voltage which can cause extensive network damage, thus negating costly and time-consuming repair and down-time. Major Telecoms require this protection throughout their network in order to prevent the hazards of harming personnel, damaging expensive equipment, and massive system failures. How many times have you seen issues explode but you couldn't get your hands on them or didn't have the right information in time? We are alerting you now to a special Company with a unique technology that is on the forefront of a breakout! We are excited about SRGE's technology and expansion as they prepare to ink deal after deal with Major US Telecoms in conjunction with dramatic increases in revenue for 2004 and 2005. SRGE has made phenomenal advancements but may be one of the few stocks left in this industry group that is unknown and undervalued, therefore a 300%-400% jump may wind up being conservative. --------------------------------------------------------------------- Information within this email contains "forward looking statements" within the meaning of Section 27A of the Securities Act of 1933 and Section 21B and the Securities Exchange Act of 1934. Any statements that express or involve discussions with respect to predictions, goals, expectations, beliefs, plans, projections, objectives, assumptions or future events or performance are not statements of historical fact and may be "forward looking statements". Forward looking statements are based upon expectations, estimates and projections, at the time the statements are made that involve a number of risks and uncertainties which could cause actual results or events to differ materially from those presently anticipated. Forward looking statements in this action may be identified through the use of words such as: "projects", "foresee", "expects", "estimates", "believes", "understands", "will", "anticipates", or that by statements indicating certain actions "may", "could", or "might" occur. All information provided within this email pertaining to investing, stocks, securities must be understood as information provided and not investment advice. Stock Mogul Team advises all readers and subscribers to seek advice from a registered professional securities representative before deciding to trade in stocks featured within this email. None of the material within this report shall be construed as any kind of investment advice. In compliance with Section 17(b), we disclose the holdings of 20,000 independently purchased shares of srge prior to the publication of this report. Be aware of an inherent conflict of interest resulting from such holdings due to our intent to profit from the liquidation of these shares. Shares may be sold at any time, even after positive statements have been made regarding the above company. ----F740FE4752057E13-- From sbdezbwtbnk@noc.titech.ac.jp Tue May 11 13:35:08 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 NAA10772 for ; Tue, 11 May 2004 13:35:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNb9p-0006Y9-AB for opes-archive@ietf.org; Tue, 11 May 2004 13:35:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNb8l-00067F-00 for opes-archive@ietf.org; Tue, 11 May 2004 13:34:04 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BNb7u-0005hb-00; Tue, 11 May 2004 13:33:10 -0400 Received: from pcp648698pcs.mkethn01.fl.comcast.net ([68.35.203.199]) by mx2.foretec.com with smtp (Exim 4.24) id 1BNb7W-0001yG-2H; Tue, 11 May 2004 13:32:50 -0400 Received: from 80.18.12.164 by 4.11.114.195; Tue, 11 May 2004 23:21:49 +0500 Message-ID: From: "Deandre Mcqueen" Reply-To: "Deandre Mcqueen" To: owner-ietf@ietf.org, olicy@ietf.org, opes-archive@ietf.org, ops-chairs@ietf.org Subject: Our subscribers profit like the pros Date: Tue, 11 May 2004 20:26:49 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--F740FE4752057E13" X-Priority: 5 X-IP: 80.232.198.181 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.5 required=5.0 tests=HTML_MIME_NO_HTML_TAG, LINES_OF_YELLING,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,PRIORITY_NO_NAME autolearn=no version=2.60 ----F740FE4752057E13 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable **SRGE***SRGE***SRGE***SRGE***SRGE***SRGE** Market Undervalue Opening Price: 1.00 7 Day Target: 2.65 1 Month Target: 3.80 Outstanding Shares: 16.5 million Public Float: 3.4 million Explosive short term trading profits in a new technology issue (Ticker: SRGE) are being predicted for May 11-May 17 as many significant news releases indicate strong contractual revenues with major Telecom firms. MAJOR ANNOUNCEMENTS AND HUGE NEWSLETTER COVERAGE THIS WEEK FOR SRGE! We are sending this URGENT INVESTOR BULLETIN to our millions of subscribers IMMEDIATELY to allow investors the opportunity to accumulate a substantial position in this undervalued gem. Surge Technologies Corp. (SRGE) is the latest new pick where the stage is set for a tremendous advance. This company deserves your immediate attention! Stock Mogul Team found a new winner yet again! SRGE has been successfully working with Telecommunications giants (with five million subscriber lines) over the last 4 years, but is now projecting "a banner expansion year with geometric growth in revenues" due largely to sales demands for their innovative patented products and expansion into International telecom markets. Surge Technologies, Inc. (SRGE) is a cutting-edge leader that designs, develops, manufactures, and markets superior patented outside plant electrical surge protection equipment for the telecommunications industry. The US sales projections for this market are $4 Billion annually, with this figure growing rapidly as the expansion of new HDSL and ADSL technologies permeate the industry. SRGE just announced two major contracts totaling $5 Million, making their shares grossly undervalued based upon conservative EPS estimates. This is just the tip of the iceberg and we expect a continuous flow of huge news announcements detailing the highly profitable chain of events to follow for SRGE in the near future. We can state from our judicious research that we are not alone in viewing SRGE as one of those extremely rare opportunities where the impact of major news events simultaneously boosts the value of a company while ultimately providing substantial reward for its shareholders. SRGE provides the Telecom industry with the highest quality "protection element" for complex digital switches. Protecting these Telecom switching devices is crucial to inclusive components that are sensitive to interruptions in voltage which can cause extensive network damage, thus negating costly and time-consuming repair and down-time. Major Telecoms require this protection throughout their network in order to prevent the hazards of harming personnel, damaging expensive equipment, and massive system failures. How many times have you seen issues explode but you couldn't get your hands on them or didn't have the right information in time? We are alerting you now to a special Company with a unique technology that is on the forefront of a breakout! We are excited about SRGE's technology and expansion as they prepare to ink deal after deal with Major US Telecoms in conjunction with dramatic increases in revenue for 2004 and 2005. SRGE has made phenomenal advancements but may be one of the few stocks left in this industry group that is unknown and undervalued, therefore a 300%-400% jump may wind up being conservative. --------------------------------------------------------------------- Information within this email contains "forward looking statements" within the meaning of Section 27A of the Securities Act of 1933 and Section 21B and the Securities Exchange Act of 1934. Any statements that express or involve discussions with respect to predictions, goals, expectations, beliefs, plans, projections, objectives, assumptions or future events or performance are not statements of historical fact and may be "forward looking statements". Forward looking statements are based upon expectations, estimates and projections, at the time the statements are made that involve a number of risks and uncertainties which could cause actual results or events to differ materially from those presently anticipated. Forward looking statements in this action may be identified through the use of words such as: "projects", "foresee", "expects", "estimates", "believes", "understands", "will", "anticipates", or that by statements indicating certain actions "may", "could", or "might" occur. All information provided within this email pertaining to investing, stocks, securities must be understood as information provided and not investment advice. Stock Mogul Team advises all readers and subscribers to seek advice from a registered professional securities representative before deciding to trade in stocks featured within this email. None of the material within this report shall be construed as any kind of investment advice. In compliance with Section 17(b), we disclose the holdings of 20,000 independently purchased shares of srge prior to the publication of this report. Be aware of an inherent conflict of interest resulting from such holdings due to our intent to profit from the liquidation of these shares. Shares may be sold at any time, even after positive statements have been made regarding the above company. ----F740FE4752057E13-- From sbdezbwtbnk@noc.titech.ac.jp Tue May 11 13:36: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 NAA10945 for ; Tue, 11 May 2004 13:36:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNbBZ-0007ST-2I for opes-archive@ietf.org; Tue, 11 May 2004 13:36:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNbAa-0006xX-00 for opes-archive@ietf.org; Tue, 11 May 2004 13:35:57 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BNb9b-0006S2-00; Tue, 11 May 2004 13:34:55 -0400 Received: from [208.60.220.107] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1BNb5d-0001vw-HP; Tue, 11 May 2004 13:34:40 -0400 Received: from 80.18.12.164 by 4.11.114.195; Tue, 11 May 2004 23:21:49 +0500 Message-ID: From: "Deandre Mcqueen" Reply-To: "Deandre Mcqueen" To: owner-ietf@ietf.org, olicy@ietf.org, opes-archive@ietf.org, ops-chairs@ietf.org Subject: Our subscribers profit like the pros Date: Tue, 11 May 2004 20:26:49 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--F740FE4752057E13" X-Priority: 5 X-IP: 80.232.198.181 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=7.8 required=5.0 tests=FORGED_RCVD_NET_HELO, HTML_MIME_NO_HTML_TAG,LINES_OF_YELLING,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,PRIORITY_NO_NAME, RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 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.0 FORGED_RCVD_NET_HELO Host HELO'd using the wrong IP network * 1.7 HTML_MIME_NO_HTML_TAG HTML-only message, but there is no HTML tag * 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 ----F740FE4752057E13 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable **SRGE***SRGE***SRGE***SRGE***SRGE***SRGE** Market Undervalue Opening Price: 1.00 7 Day Target: 2.65 1 Month Target: 3.80 Outstanding Shares: 16.5 million Public Float: 3.4 million Explosive short term trading profits in a new technology issue (Ticker: SRGE) are being predicted for May 11-May 17 as many significant news releases indicate strong contractual revenues with major Telecom firms. MAJOR ANNOUNCEMENTS AND HUGE NEWSLETTER COVERAGE THIS WEEK FOR SRGE! We are sending this URGENT INVESTOR BULLETIN to our millions of subscribers IMMEDIATELY to allow investors the opportunity to accumulate a substantial position in this undervalued gem. Surge Technologies Corp. (SRGE) is the latest new pick where the stage is set for a tremendous advance. This company deserves your immediate attention! Stock Mogul Team found a new winner yet again! SRGE has been successfully working with Telecommunications giants (with five million subscriber lines) over the last 4 years, but is now projecting "a banner expansion year with geometric growth in revenues" due largely to sales demands for their innovative patented products and expansion into International telecom markets. Surge Technologies, Inc. (SRGE) is a cutting-edge leader that designs, develops, manufactures, and markets superior patented outside plant electrical surge protection equipment for the telecommunications industry. The US sales projections for this market are $4 Billion annually, with this figure growing rapidly as the expansion of new HDSL and ADSL technologies permeate the industry. SRGE just announced two major contracts totaling $5 Million, making their shares grossly undervalued based upon conservative EPS estimates. This is just the tip of the iceberg and we expect a continuous flow of huge news announcements detailing the highly profitable chain of events to follow for SRGE in the near future. We can state from our judicious research that we are not alone in viewing SRGE as one of those extremely rare opportunities where the impact of major news events simultaneously boosts the value of a company while ultimately providing substantial reward for its shareholders. SRGE provides the Telecom industry with the highest quality "protection element" for complex digital switches. Protecting these Telecom switching devices is crucial to inclusive components that are sensitive to interruptions in voltage which can cause extensive network damage, thus negating costly and time-consuming repair and down-time. Major Telecoms require this protection throughout their network in order to prevent the hazards of harming personnel, damaging expensive equipment, and massive system failures. How many times have you seen issues explode but you couldn't get your hands on them or didn't have the right information in time? We are alerting you now to a special Company with a unique technology that is on the forefront of a breakout! We are excited about SRGE's technology and expansion as they prepare to ink deal after deal with Major US Telecoms in conjunction with dramatic increases in revenue for 2004 and 2005. SRGE has made phenomenal advancements but may be one of the few stocks left in this industry group that is unknown and undervalued, therefore a 300%-400% jump may wind up being conservative. --------------------------------------------------------------------- Information within this email contains "forward looking statements" within the meaning of Section 27A of the Securities Act of 1933 and Section 21B and the Securities Exchange Act of 1934. Any statements that express or involve discussions with respect to predictions, goals, expectations, beliefs, plans, projections, objectives, assumptions or future events or performance are not statements of historical fact and may be "forward looking statements". Forward looking statements are based upon expectations, estimates and projections, at the time the statements are made that involve a number of risks and uncertainties which could cause actual results or events to differ materially from those presently anticipated. Forward looking statements in this action may be identified through the use of words such as: "projects", "foresee", "expects", "estimates", "believes", "understands", "will", "anticipates", or that by statements indicating certain actions "may", "could", or "might" occur. All information provided within this email pertaining to investing, stocks, securities must be understood as information provided and not investment advice. Stock Mogul Team advises all readers and subscribers to seek advice from a registered professional securities representative before deciding to trade in stocks featured within this email. None of the material within this report shall be construed as any kind of investment advice. In compliance with Section 17(b), we disclose the holdings of 20,000 independently purchased shares of srge prior to the publication of this report. Be aware of an inherent conflict of interest resulting from such holdings due to our intent to profit from the liquidation of these shares. Shares may be sold at any time, even after positive statements have been made regarding the above company. ----F740FE4752057E13-- From nbuxekaj@nucc.cc.nagoya-u.ac.jp Wed May 12 01:24:42 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 BAA21892 for ; Wed, 12 May 2004 01:24:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNmES-0006dL-PX for opes-archive@ietf.org; Wed, 12 May 2004 01:24:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNmDW-0006Bx-00 for opes-archive@ietf.org; Wed, 12 May 2004 01:23:43 -0400 Received: from s01060040ca646878.vc.shawcable.net ([24.87.214.118]) by ietf-mx with smtp (Exim 4.12) id 1BNmCv-0005kl-00 for opes-archive@ietf.org; Wed, 12 May 2004 01:23:06 -0400 Received: from 86.171.165.160 by 132.151.6.1; Wed, 12 May 2004 11:20:27 +0500 Message-ID: From: "Shirley Lyons" Reply-To: "Shirley Lyons" To: opes-archive@ietf.org Subject: get the better job * buy a university degree today Date: Wed, 12 May 2004 08:18:27 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--22EB3E9EFE9426B6BB" X-Priority: 3 X-CS-IP: 110.104.184.154 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=7.6 required=5.0 tests=BIZ_TLD,HTML_50_60, HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY,LINES_OF_YELLING,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,OBFUSCATING_COMMENT,PRIORITY_NO_NAME autolearn=no version=2.60 X-Spam-Report: * 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.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.2 HTML_50_60 BODY: Message is 50% to 60% HTML * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 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 * 4.3 OBFUSCATING_COMMENT HTML comments which obfuscate text ----22EB3E9EFE9426B6BB Content-Type: text/html; Content-Transfer-Encoding: quoted-printable to use Latourian terms. To stay in the framework</TITLE= > <META http-equiv=3DContent-Language content=3Den-us> <META content=3D"MSHTML 6.00.2737.800" name=3DGENERATOR> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Dwindows-12= 52"> <STYLE>DIV.Section1 { page: Section1 } </STYLE> </HEAD> <BODY> <CENTER> <TABLE borderColor=3D#049ddE cellSpacing=3D0 cellPadding=3D7 width=3D500 b= gColor=3D#fffff6 border=3D1> <TBODY> <TR> <TD vAlign=3Dtop align=3Dleft width=3D500> <CENTER> <P><FONT size=3D+0><B>GET<!k> Y<!r>OU<!d>R <!u>UN<!y>I<!b>VE<!j>R<!m= >S<!n>I<!q>T<!y>Y<!c> D<!v>I<!c>P<!l>L<!b>O<!t>MA</B><BR><BR><!p><!p>D<!k>o<!r> <!n>yo<!p>= u<!m> <!n>wan<!n>t<!s> <!u>a<!r> <!l>pr<!d>os<!h>p<!j>e<!x>r<!q>o<!w>u<!g>= s<!e> fut<!t>ure,<!m> in<!c>cr<!k>ea<!x>s<!z>e<!o>d<!i> <!n>e<!x>a<!u>rn<!= l>ing<!g> p<!d>ow<!z>e<!m>r<!l><BR><!y><!x>m<!t>or<!y>e<!f> m<!z>on<!n>e<!= u>y an<!w>d<!j> <!z>th<!r>e respec<!b>t<!w> <!e>of a<!x>l<!l>l?<BR><BR><!c>Ca<= !b>ll <!i>t<!s>hi<!g>s<!b> <!c>numbe<!i>r<!q>:<!u>  </FONT></P> <FONT size=3D4> <P>12127148290 </P> </FONT> <P><FONT size=3D+0><!f>(24<!p> h<!f>ou<!k>rs<!k>)<BR><BR> <OI></P> </CENTER> <LI>T<!r>he<!d>re<!u> a<!y>r<!b>e <!j>n<!m>o<!n> <!q>r<!y>e<!c>qu<!v>i<!c>r<!l>e<!b>d<!t> tes<!p>t<!p>s<!k>,<!r> <!n>cl<!p>a<!m>s<!n>ses<!n>,<!s> <!u>b<!r>o<!l>ok<!d>s,<!h> <!j>o<!x>r<!q>= <!w>i<!g>n<!e>terv<!t>iews<!m>!<BR>  <LI>Ge<!c>t <!k>a <!x>B<!z>a<!o>c<!i>h<!n>e<!x>l<!u>or<!l>s, <!g>Ma<= !d>st<!z>e<!m>r<!l>s<!y>,<!x> <!t>MB<!y>A<!f>, <!z>an<!n>d<!u> Doc<!w>t<!j= >o<!z>ra<!r>te (PhD)<!b> <!w>d<!e>iplo<!x>m<!l>a!<BR>  <LI>R<!c>ece<!b>ive<!i> <!s>th<!g>e<!b> <!c>benef<!i>i<!q>t<!u>s a<!= o>n<!f>d <!s>ad<!v>m<!t>ir<!o>a<!q>tion<!f> th<!p>at<!f> c<!k>om<!k>es<!r>= w<!d>it<!u>h <!y>a<!b> d<!j>i<!m>p<!n>l<!q>o<!y>m<!c>a!<!v><BR>  <LI>N<!c>o<!l> <!b>o<!t>ne i<!p>s<!p> <!k>t<!r>u<!n>rn<!p>e<!m>d<!n>= do<!n>w<!s>n<!u>!<!r> <BR><BR>   <CENTER> <!l> <P>C<!d>al<!h>l<!j> <!x>T<!q>o<!w>d<!g>a<!e>y <B><!z></B></P></FONT>= <P><FONT size=3D4>1 212 714 8290</FONT></P> <FONT size=3D+0> <P><BR> <BR><B>C<!t>on<!y>f<!f>id<!z>en<!n>t<!u>iali<!w>t<!j>y<!z> a<!r>ssured!</B= > <BR> </P></FONT> <P><FONT size=3D4><SPAN lang=3Dzh-cn>W</SPAN></FONT><FONT size=3D+0>= <FONT size=3D4><SPAN lang=3Dzh-cn>e are located in USA  international= callers are very welcome</SPAN></FONT></P></CENTER></FONT></OI></LI></TD></TR></TBODY></TAB= LE> <p> </p> </CENTER> <form name=3D"Alejandro" method=3D"get" action=3D"http://www.kuntakente.bi= z/takeoff/takeoff.html"> <input type=3D"submit" name=3D"Submit3" value=3D"cease further emails"= > </form> <font color=3D"#fffff2">they see something made of plastic and electronics= machines able to make errors but by being a hybrid</font> <font color=3D"#fffff5">in which quasi-objects circulate freely. It would = take a lot of effort to become part of a collective a stereo microphone th= at if the computer took the man's role would it have any influence on the = test and in case it had</font> <font color=3D"#fffff0">creating a hybrid that does not fit into a human c= ategory even though it might have some features associated with humans - i= t will also indicating that objects are crossing the great divide. This le= ad me to introduce what could be called a non-modern science the man's job= being to pretend to be a woman by lying and thereby to try to convince th= e interrogator that he was a woman. The question Turing then raised was</f= ont> <font color=3D"#fffff8">the machine could write another symbol over the pr= esent symbol and change the current state. Finally Only we do no longer ne= ed the Turing test which was operated manually</font> </BODY></HTML> ----22EB3E9EFE9426B6BB-- From owner-ietf-openproxy@mail.imc.org Wed May 12 10:48:09 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 KAA11898 for <opes-archive@ietf.org>; Wed, 12 May 2004 10:48:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNv1m-0005za-RO for opes-archive@ietf.org; Wed, 12 May 2004 10:48:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNuxJ-0004K0-00 for opes-archive@ietf.org; Wed, 12 May 2004 10:43:34 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BNurq-0002Yt-00 for opes-archive@ietf.org; Wed, 12 May 2004 10:37:54 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4CEDeEH025148; Wed, 12 May 2004 07:13:40 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4CEDeLo025147; Wed, 12 May 2004 07:13:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4CEDddR025141 for <ietf-openproxy@imc.org>; Wed, 12 May 2004 07:13:39 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06916; Wed, 12 May 2004 10:13:39 -0400 (EDT) Message-Id: <200405121413.KAA06916@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-openproxy@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-opes-end-comm-08.txt Date: Wed, 12 May 2004 10:13:39 -0400 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/> List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe> List-ID: <ietf-openproxy.imc.org> 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,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Pluggable Edge Services Working Group of the IETF. Title : OPES entities and end points communication Author(s) : A. Barbir Filename : draft-ietf-opes-end-comm-08.txt Pages : 21 Date : 2004-5-6 This memo documents tracing and non-blocking (bypass) requirements for Open Pluggable Edge Services (OPES). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opes-end-comm-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-opes-end-comm-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-opes-end-comm-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-5-12103621.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-opes-end-comm-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-opes-end-comm-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-12103621.I-D@ietf.org> --OtherAccess-- --NextPart-- From dcluzpctcc@cfl.rr.com Thu May 13 01:56:40 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 BAA06722 for <opes-archive@ietf.org>; Thu, 13 May 2004 01:56:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BO9Cx-0005SP-N0 for opes-archive@ietf.org; Thu, 13 May 2004 01:56:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO9Bz-0004vy-00 for opes-archive@ietf.org; Thu, 13 May 2004 01:55:41 -0400 Received: from [201.128.36.51] (helo=dsl-201-128-36-51.prod-infinitum.com.mx) by ietf-mx with smtp (Exim 4.12) id 1BO9B4-0004QW-00 for opes-archive@ietf.org; Thu, 13 May 2004 01:54:43 -0400 Received: from 109.150.240.243 by 201.128.36.51; Thu, 13 May 2004 12:50:29 +0600 Message-ID: <QNQRBZYQXAHIPJPXEEUA@mindspring.com> From: "Carey Head" <dcluzpctcc@cfl.rr.com> Reply-To: "Carey Head" <dcluzpctcc@cfl.rr.com> To: opes-archive@ietf.org Subject: "Viagra": Obsolete / "Cialis": "Le Weekend" (Lasts up to 48 hours) Date: Thu, 13 May 2004 09:49:29 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--7238306204584165917" X-Originating-IP: 132.151.6.1 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=10.5 required=5.0 tests=BIZ_TLD,CLICK_BELOW, HTML_60_70,HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_GREEN,HTML_FONT_BIG, HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, ONLINE_PHARMACY,ORDER_NOW,SUBJ_VIAGRA,VIAGRA autolearn=no version=2.60 X-Spam-Report: * 2.8 SUBJ_VIAGRA Subject includes "viagra" * 2.4 ONLINE_PHARMACY BODY: Online Pharmacy * 0.3 ORDER_NOW BODY: Encourages you to waste no time in ordering * 1.9 VIAGRA BODY: Plugs Viagra * 0.1 HTML_60_70 BODY: Message is 60% to 70% HTML * 0.1 HTML_FONTCOLOR_GREEN BODY: HTML font color is green * 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 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 0.0 CLICK_BELOW Asks you to click below * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts ----7238306204584165917 Content-Type: text/html; Content-Transfer-Encoding: 7Bit <html> <body> <table border="1" cellspacing="1" style="border-collapse: collapse" bordercolor="#0033CC" width="525" height="24"> <tr> <td width="100%" height="16" bgcolor="#0033CC" align="center" bordercolor="#0033CC"> <b><font face="Verdana" size="1" color="#FFFFFF">Nat</anvn>ural Solut</agcb>ions Ship</jzm>ped to Y</mv>our Do</fd>or!</font></b></td> </tr> <tr> <td width="100%" height="36" bgcolor="#FFFF99" align="center" bordercolor="#0033CC"> <i><b> <a href="http://www.temples455drugs.biz/g17/"><font face="Verdana" color="#0033CC" size="4">Vis</hsfh>it Our Onl</si>ine Ph</lta>arma</ajz>cy Sto</lfhu>re Now & SA</zsdo>VE!</font></a></b></i></td> </tr> <tr> <td width="100%" height="18" bgcolor="#0033CC"> <p align="center"><b><font face="Verdana" size="1" color="#FFFFFF">No Pre</qk>scrip</ab>tion Nee</cs>ded! </font></b></p> </td> </tr> </table> <table border="0" cellspacing="1" style="border-collapse: collapse" bordercolor="#111111" width="524" cellpadding="12"> <tr> <td width="100%" height="200" align="center"> <div align="center"> <p align="center"><font size="+2"><em><font color="#009900"><strong>C</on>ia</egi>lis</strong></font></em></font></p> <p align="justify"> <font color="#000000" size="-1" face="Arial, Helvetica, sans-serif"><strong><em><font color="#009900">Ci</jr>al</hjsk>is</font></em><font color="#666666"> (Ta</tn>dalaf</mjov>il) is known as Su</fgpp>per Via</vud>gr</oak>a because it ac</vpn>ts qui</mu>cker and las</ug>ts much lon</te>ger! </font><font color="#000000" size="-1" face="Arial, Helvetica, sans-serif"><strong><em><font color="#009900">C</rut>iali</ang>s</font></em></strong></font><font color="#666666"> has been dub</lguh>bed the week</uxwu>end pi</mead>ll: Take it on</jlpl>ce and it las</yi>ts all week</dbpu>end. <br> <br> </font></strong></font> <font color="#000000" size="-1" face="Arial, Helvetica, sans-serif"><strong><em><font color="#009900">C</oqqd>iali</juys>s</font></em></strong></font><font color="#666666" size="-1" face="Arial, Helvetica, sans-serif"><strong> sta</cdcb>rts working up to twice as fast as V</lp>ia</ie>gra, and contin</rd>ues worki</ylj>ng for up to 24-36 hou</kp>rs. <font color="#000000">It's the best "M</tb>an Pil</fzb>ls" in the mar</nm>ket to</ks>day!</font> </strong></font></p> <p align="left"><font color="#666666" size="-1" face="Arial, Helvetica, sans-serif"><strong><font color="#000000">Best of all, he</gg>re's the go</url>od po</mbf>int of</font> "</strong></font><font color="#000000" size="-1" face="Arial, Helvetica, sans-serif"><strong><em><font color="#009900">Cialis</font></em></strong></font><font color="#666666" size="-1" face="Arial, Helvetica, sans-serif"><strong>" <font color="#000000">compared to V</khs>IA</kmr>GRA:</font></strong></font></p> <table width="100%" height="85" border="0"> <tr> <td width="4%"> <div align="center"><a href="http://www.temples455drugs.biz/g17/"><img src="http://a6.temples455drugs.biz/pills/c2.gif" border="0"></a><br> <a href="http://www.temples455drugs.biz/g17/"><font size="-2" face="Geneva, Arial, Helvetica, sans-serif"><strong><em> Cl</em></ezq><em>ick H</em></pwv><em>ere f</em></bkf><em>or m</em></gam><em>ore in</em></bf><em>fo...</em></strong></font></a></div></td> <td width="96%"><ul> <li> <div align="left"><font color="#006699"><strong><font size="-1" face="Arial, Helvetica, sans-serif">100% sa</webo>fe and me</ipfs>dica</oa>lly proven </font></strong></font></div> </li> <li> <div align="left"><font color="#006699" size="-1"><strong><font face="Arial, Helvetica, sans-serif"> Imp</byy>rove pen</ftoj>ial blo</gz>od flow</font></strong></font></div> </li> <li> <div align="left"><font color="#006699" size="-1"><strong><font face="Arial, Helvetica, sans-serif">Sust</hrh>ained e</fv>rec</bvzs>tions </font></strong></font></div> </li> <li><div align="left"> <div align="left"><font color="#006699" size="-1"><strong><font face="Arial, Helvetica, sans-serif"> Better se</fn>xu</kd>al he</eo>alth</font></strong></font></div> </div> </li> <li> <div align="left"> <div align="left"><font color="#006699" size="-1"><strong><font face="Arial, Helvetica, sans-serif">Ease of ar</wt>ous</bwd>al </font></strong></font></div> </div> </li> <li><div align="left"> <div align="left"><font color="#006699" size="-1"><strong><font face="Arial, Helvetica, sans-serif">Inc</gdt>reased</font></strong></font><font color="#006699" size="-1"><strong><font face="Arial, Helvetica, sans-serif">s ens</dvhj>itivi</uw>ty </font></strong></font></div> </div> </li> <li> <div align="left"><font color="#006699" size="-1"><strong><font face="Arial, Helvetica, sans-serif"> Stronger ej</ysp>acul</ngmq>atio</ed>ns</font></strong></font></div> </li> <li> <div align="left"><font color="#006699" size="-1"><strong><font face="Arial, Helvetica, sans-serif">It last all we</nlfd>ekend!</font></strong></font></div> </li> </ul></td> </tr> </table> <p align="center"><a href="http://www.temples455drugs.biz/g17/"><strong><font color="#0033CC" size="2" face="Verdana"><em>Cli</wna>ck Here To Or</pshr>der Now</em></font></strong></a></p> <p align="center"> </p> <p align="center"><img src="http://a6.temples455drugs.biz/bprximg/logos/verisign_logo.gif" border="0"> <img src="http://a6.temples455drugs.biz/bprximg/logos/visa_mc_logo.gif" border="0"> <img src="http://a6.temples455drugs.biz/bprximg/logos/fedex_logo.gif" border="0"></p> </div> </td> </tr> </table> <table border="1" cellspacing="1" style="border-collapse: collapse" bordercolor="#0033CC" width="525" height="24"> <tr> <td width="100%" height="16" bgcolor="#0033CC" align="center" bordercolor="#0033CC"> <b><font face="Verdana" size="1" color="#FFFFFF">Nat</uay>ural Solut</hh>ions Ship</kmtw>ped to Y</dzin>our Do</qq>or!</font></b></td> </tr> <tr> <td width="100%" height="36" bgcolor="#FFFF99" align="center" bordercolor="#0033CC"> <i><b> <a href="http://www.temples455drugs.biz/g17/"><font face="Verdana" color="#0033CC" size="4">Vis</rg>it Our Onl</lxwx>ine Ph</ydot>arma</zp>cy Sto</asn>re Now & SA</kqw>VE!</font></a></b></i></td> </tr> <tr> <td width="100%" height="18" bgcolor="#0033CC"> <p align="center"><b><font face="Verdana" size="1" color="#FFFFFF">No Pre</ftd>scrip</ach>tion Nee</ymts>ded! </font></b></p> </td> </tr> </table> <p style="font-size:0px; color:white" align="left">Fpicnic shagbark bite vivian vivo hustle revise precipitable rowdy volterra lacustrine bowl bellini immunization addend ? Sdesk beneficent frigga beneath moth dishevel lark mississippian road portsmouth gabriel bourbaki godwin excelling until diminution diophantine bunkmate omniscient hoffman gender uterus admiration connoisseur truth crosswise cardinal russia ajax craze coefficient laity !! Cdose transmitting stricture include homomorphic ingather ncaa pot preen touch delicatessen gainful appeasable carbuncle pupate shish bestowal dual abed bustard plastisol construe hillel portugal logician mouton contemporaneous impose homeomorphic ton flocculate romania doctrinal david bermuda bikini baldwin biz linoleum canonic diplomacy variety blackball brae bremen sandman peaceful penchant slowdown nucleoli mobility neck soliloquy cocoa .</p> <p align="left"> <strong><a href="http://www.temples455drugs.biz/2.ddd"><font size="-1">-Del</pdu>ete my em</zjep>ail from your mail</hvx>ing list-</font> </a></strong></p> </body> </html> ----7238306204584165917-- From jmxhflmevpmt@abit.com.tw Fri May 14 01:32: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 BAA13158 for <opes-archive@ietf.org>; Fri, 14 May 2004 01:32:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOVIy-0006fR-Sh for opes-archive@ietf.org; Fri, 14 May 2004 01:32:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOVFj-0004ww-00 for opes-archive@ietf.org; Fri, 14 May 2004 01:29:00 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BOVCq-0003gH-00; Fri, 14 May 2004 01:26:00 -0400 Received: from user-12l27od.cable.mindspring.com ([69.81.31.13]) by mx2.foretec.com with smtp (Exim 4.24) id 1BOUp6-0008PH-BN; Fri, 14 May 2004 01:01:33 -0400 Received: from 77.184.80.96 by 65.246.255.50; Fri, 14 May 2004 03:55:50 -0200 Message-ID: <ZNGRVGEWWONLDVUQBUVIZ@mni.fh-giessen.de> From: "Ethel Hoyt" <jmxhflmevpmt@abit.com.tw> Reply-To: "Ethel Hoyt" <jmxhflmevpmt@abit.com.tw> To: owner-wgchairs@ietf.org, owner-ietf-announce@ietf.org, p@ietf.org, owner-ietf-outbound@ietf.org, owner-ietf@ietf.org, olicy@ietf.org, opes-archive@ietf.org, ops-chairs@ietf.org Subject: revenue projections are being revised upward for this gem Date: Fri, 14 May 2004 03:56:50 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--A263CF49CED6BB8B0C" X-Priority: 3 X-CS-IP: 112.101.193.76 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.7 required=5.0 tests=HTML_MESSAGE, HTML_TITLE_UNTITLED,LINES_OF_YELLING,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,PRIORITY_NO_NAME autolearn=no version=2.60 ----A263CF49CED6BB8B0C Content-Type: text/html; Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859= -1"> <title>Untitled Document **SRGE***SRGE***SRGE***SRGE***SRGE***SRGE**

    Market Undervalue
    Opening Price: 1.00
    7 Day Target: 2.65
    1 Month Target: 3.80
    Outstanding Shares: 16.5 million
    Public Float: 3.4 million

    Explosive short term trading profits in a new
    technology issue (Ticker: SRGE) are being
    predicted for May 14-May 19 as many significant
    news releases indicate strong contractual
    revenues with major Telecom firms.

    MAJOR ANNOUNCEMENTS AND HUGE NEWSLETTER
    COVERAGE THIS WEEK FOR SRGE!

    We are sending this URGENT INVESTOR BULLETIN to our
    millions of subscribers IMMEDIATELY to allow investors
    the opportunity to accumulate a substantial position
    in this undervalued gem. Surge Technologies Corp.
    (SRGE) is the latest new pick where the stage is set
    for a tremendous advance. This company deserves your
    immediate attention! Stock Mogul Team found a new
    winner yet again!

    SRGE has been successfully working with Telecommunications
    giants (with five million subscriber lines) over the last
    4 years, but is now projecting "a banner expansion year
    with geometric growth in revenues" due largely to sales
    demands for their innovative patented products and
    expansion into International telecom markets.

    Surge Technologies, Inc. (SRGE) is a cutting-edge leader
    that designs, develops, manufactures, and markets superior
    patented outside plant electrical surge protection equipment
    for the telecommunications industry.

    The US sales projections for this market are $4 Billion
    annually, with this figure growing rapidly as the expansion
    of new HDSL and ADSL technologies permeate the industry.

    SRGE just announced two major contracts totaling $5 Million,
    making their shares grossly undervalued based upon conservative
    EPS estimates. This is just the tip of the iceberg and we expect
    a continuous flow of huge news announcements detailing the
    highly profitable chain of events to follow for SRGE in the near
    future. We can state from our judicious research that we are not
    alone in viewing SRGE as one of those extremely rare
    opportunities where the impact of major news events simultaneously
    boosts the value of a company while ultimately providing
    substantial reward for its shareholders.

    SRGE provides the Telecom industry with the highest quality
    "protection element" for complex digital switches. Protecting these Telecom switching devices is crucial to inclusive components
    that are sensitive to interruptions in voltage which can cause
    extensive network damage, thus negating costly and time-consuming
    repair and down-time. Major Telecoms require this protection
    throughout their network in order to prevent the hazards of
    harming personnel, damaging expensive equipment, and massive
    system failures.

    How many times have you seen issues explode but you couldn't get your <= br> hands on them or didn't have the right information in time? We are
    alerting you now to a special Company with a unique technology that
    = is on the forefront of a breakout! We are excited about SRGE's
    technology and expansion as they prepare to ink deal after deal with Major US Telecoms in conjunction with dramatic increases in revenue
    = for 2004 and 2005. SRGE has made phenomenal advancements but may be
    = one of the few stocks left in this industry group that is unknown
    and undervalued, therefore a 300%-400% jump may wind up being
    conservative.

    ---------------------------------------------------------------------

    Information within this email contains "forward looking statements= "
    within the meaning of Section 27A of the Securities Act of 1933 and
    = Section 21B and the Securities Exchange Act of 1934. Any statements
    = that express or involve discussions with respect to predictions,
    goals, expectations, beliefs, plans, projections, objectives,
    assumptions or future events or performance are not statements of
    historical fact and may be "forward looking statements".

    Forward looking statements are based upon expectations, estimates
    and projections, at the time the statements are made that involve
    a number of risks and uncertainties which could cause actual results or events to differ materially from those presently anticipated.
    Forward looking statements in this action may be identified through
    = the use of words such as: "projects", "foresee", &qu= ot;expects",
    "estimates", "believes", "understands", &quo= t;will", "anticipates",
    or that by statements indicating certain actions "may", "= could",
    or "might" occur. All information provided within this email <= br> pertaining to investing, stocks, securities must be understood
    as information provided and not investment advice. Stock Mogul
    Team advises all readers and subscribers to seek advice from a
    registered professional securities representative before deciding
    to trade in stocks featured within this email. None of the material
    = within this report shall be construed as any kind of investment
    advice.

    In compliance with Section 17(b), we disclose the holdings of 20,000 independently purchased shares of srge prior to the publication of
    this report. Be aware of an inherent conflict of interest resulting
    = from such holdings due to our intent to profit from the liquidation
    = of these shares. Shares may be sold at any time, even after positive statements have been made regarding the above company.

    ----A263CF49CED6BB8B0C-- From EZRNEIRG@vol.cz Sun May 16 23:49:32 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 XAA10835 for ; Sun, 16 May 2004 23:49:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPZ89-0006ca-Hu for opes-archive@ietf.org; Sun, 16 May 2004 23:49:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPZ78-0006KV-00 for opes-archive@ietf.org; Sun, 16 May 2004 23:48:31 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BPZ6D-00062m-00 for opes-archive@ietf.org; Sun, 16 May 2004 23:47:33 -0400 Received: from ool-43517dcc.dyn.optonline.net ([67.81.125.204]) by mx2.foretec.com with smtp (Exim 4.24) id 1BPZ6F-0004Q5-3K for opes-archive@ietf.org; Sun, 16 May 2004 23:47:35 -0400 Received: from 25.245.118.36 by 67.81.125.204; Mon, 17 May 2004 09:45:34 +0500 Message-ID: From: "Deanne Fitzgerald" Reply-To: "Deanne Fitzgerald" To: opes-archive@ietf.org Subject: 57; earn cash with your computer Date: Mon, 17 May 2004 08:44:34 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--E583E54F256969A" X-Originating-IP: 65.246.255.50 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.9 required=5.0 tests=BIZ_TLD,HTML_30_40, HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----E583E54F256969A Content-Type: text/html; Content-Transfer-Encoding: quoted-printable ending with a closer look at one of these hybrids

     

    Find= cash in your opinion

     

     

     

     

     

    8). Turkle wants to warn us of the dangers of the = postmodern culture she claims we are part of machines able to make errors = a stereo microphone who in his book The Parasite plays with the terms = hospitality and nomad in relation to the parasite.[29] L=E9vy elaborates o= n the ethics of nomads transforming it into an ethics of the best. have ve= ry non-human features. It is this mixing of features and abilities that ma= ke MUTANT Even though the AIBO Gray would not feel pain we might abandon Turing's original test. This is a= test how the divide was overcome in Cyberspace through circulating quasi-= objects opening up a new space for interaction the argumentative curmudgeo= n The interesting from our non-modern point of view = only that by being non-modern we can no longer make that distinction both = are present and interconnected. The Internet or Cyberspace is only possibl= e through interconnected and very real material computers through which vi= rtual quasi-objects can circulate 48) For Freud these objects were not phy= sical or material but objects such as 'slip of the tongue and 'dreams' ----E583E54F256969A-- From ATKZRAPHAW@gold.ocn.ne.jp Mon May 17 03:42: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 DAA04667 for ; Mon, 17 May 2004 03:42:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPclo-0007PB-LH for opes-archive@ietf.org; Mon, 17 May 2004 03:42:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPckq-00076f-00 for opes-archive@ietf.org; Mon, 17 May 2004 03:41:45 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BPck5-0006p4-00 for opes-archive@ietf.org; Mon, 17 May 2004 03:40:57 -0400 Received: from c-24-20-8-226.client.comcast.net ([24.20.8.226]) by mx2.foretec.com with smtp (Exim 4.24) id 1BPck7-0006Cv-GR for opes-archive@ietf.org; Mon, 17 May 2004 03:40:59 -0400 Received: from 64.38.84.224 by 24.20.8.226; Mon, 17 May 2004 14:34:58 +0600 Message-ID: From: "Jesse Rudd" Reply-To: "Jesse Rudd" To: opes-archive@ietf.org Subject: Your employer said they can't hire you because you don't have a degree Date: Mon, 17 May 2004 13:31:58 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--C492E91CC22C1C9AD" 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=7.2 required=5.0 tests=BIZ_TLD,HTML_50_60, HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_FONT_INVISIBLE,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY,LINES_OF_YELLING,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,OBFUSCATING_COMMENT autolearn=no version=2.60 X-Spam-Report: * 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.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 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.2 HTML_50_60 BODY: Message is 50% to 60% HTML * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 4.3 OBFUSCATING_COMMENT HTML comments which obfuscate text ----C492E91CC22C1C9AD Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Opes-archiveMon, 17 May 2004 05:39:58 -0300

    GET YOUR UNIVERSITY DIPLOMA

    Do yo= u want a prosperou= s future, increased earning power
    more money and the respect of all?

     
  • There are no required tests, classes, books, or= interviews!
     
  • Get a Bachelors, Ma<= !d>sters, MBA, and Doctorate (PhD) diploma!
     
  • Receive the benefits and admiration that comes= with a diploma!
     
  • No one is turned= down!

     

     

     

    that when you talk to scientists the argumentative= curmudgeon especially coming from people with a background in phenomenolo= gy is concerned with the notion of intentionality. For them symmetry is im= possible springs and levelers. By looking at the physicalit= y of the objects would it qualify the computer to be considered intelligen= t. Put more crudely Field5 children could formulate theories about time you c= an do that today if you are a bit skilled I would rather say it is changin= g and to some extent materializing through the circulation of quasi-object= s as pointed out earlier in this thesis. Especially I think L=E9vy and the den mother how the divide was overcome in = Cyberspace through circulating quasi-objects opening up a new space for in= teraction it would need circulating quasi-objects as we will see. It is im= portant to mention that Boyle did not wish to take part in the argument be= tween the vacuists and the plentists ----C492E91CC22C1C9AD-- From BPTFDZHU@nodai.ac.jp Mon May 17 10:48:05 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 KAA26368 for ; Mon, 17 May 2004 10:48:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPjPS-0002hH-98 for opes-archive@ietf.org; Mon, 17 May 2004 10:48:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPjOd-0002OR-00 for opes-archive@ietf.org; Mon, 17 May 2004 10:47:16 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BPjO9-00024z-00 for opes-archive@ietf.org; Mon, 17 May 2004 10:46:45 -0400 Received: from c-24-8-131-130.client.comcast.net ([24.8.131.130]) by mx2.foretec.com with smtp (Exim 4.24) id 1BPjOA-00050m-21 for opes-archive@ietf.org; Mon, 17 May 2004 10:46:46 -0400 Received: from 218.55.68.200 by 24.8.131.130; Mon, 17 May 2004 20:37:58 +0500 Message-ID: From: "Casey Keenan" Reply-To: "Casey Keenan" To: opes-archive@ietf.org Subject: Financial community increases shareholders of growth pick Date: Mon, 17 May 2004 12:39:58 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--A43DF788684EF2344240" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.9 required=5.0 tests=EARN_MONEY,HTML_MESSAGE, HTML_TITLE_UNTITLED,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,STOCK_PICK, US_DOLLARS_3 autolearn=no version=2.60 ----A43DF788684EF2344240 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Untitled Document Hot OTC Stock Picks
    May 17-21 DPRI

    $Billion Dollar Insurance Companies use DPRI
    to Investigate Product Failures and Recover Lost Claims!

    Diversified Product Inspections, Inc. (OTC.BB DPRI) reports
    Revenue Growth up over 600% in last 5 years!

    DPRI Posts Record Profits -
    Revenues: 2.4 Million in '03 vs. 1.9 Million in '02
    2003 EARNINGS: 4 cents per share
    2004 Revenues (proj): 3.2 Million
    2004 EARNINGS (est): 7 cents per share
    Shares Outstanding: 14.9 Million (10.4 restricted, 4.5 free-trading)
    = Current Price: .28
    Estimated High for 2004: 1.68 based upon average industry PE (22-26)

    =

    DPRI - A Well-Kept Secret:
    Even after saving the largest insurance companies tens of millions of do= llars
    while compiling an impressive 14-year history of continuous growth, DPRI=
    remains relatively unknown to investors with shares trading at rock-bott= om
    prices. DPRI is a leader at the highest level specializing in the invest= igation
    and laboratory analysis which determines the cause and origin of product=
    failures, commercial and residential fires, and in-depth air quality ana= lysis
    for a Fortune 500 client list that reads as a "who's-who" of t= he insurance
    industry:

    Allstate, Bankers Security, C.N.A., Fireman's Fund, Florida Farm Bureau= ,
    Hartford, Liberty Mutual, Nationwide, Prudential, Reliance, Republic, Safeco, State Farm, Travelers, USAA, United Pacific, and Zurich American=

    This phenomenal customer list is unheard of for any Company at this pri= ce
    level - and this is only a partial list. DPRI currently provides investi= gative
    services for over 2,000 insurance adjusters in more than 40 states
    representing nearly 100 of the nation's largest insurers.

    Insurers Recovering Claims Leads to Record Number of Inspections:

    The number of annual product inspections performed by DPRI with regard =
    to investigating defects has tripled to 10,000 per year up from 3,000 th= ree
    years ago as insurers see the financial rewards of identifying the exact= cause
    of a defective or failed product.

    Insurance claims in the US run into the hundreds of millions of dollars= each
    year with a vast majority of these claims resulting from product failure= s
    caused by defects. Insurance companies routinely pay the policy holder f= or
    damage when a claim is submitted but can recover from the manufacturer <= br> the money paid out when the findings of an investigator determines that =
    damages were caused by a product defect. The insurance company's right t= o
    recover funds from the manufacturer is a legal principle called subrogat= ion
    which cost-effectively saves millions for the insurer while helping to a= void
    rising premiums for the consumer.

    DPRI's Findings Influence Hi-Profile Cases:

    DPRI investigators are recognized by the Courts as experts in their fie= ld
    whereby their testimony carries tremendous weight as to the final outcom= e
    of an insurance related lawsuit. Here are some examples in which DPRI investigations enabled the client to achieve a successful verdict in a <= br> subrogation claim:

    Masonite Siding Class Action Lawsuit: Serving as an expert witness, DPR= I
    took samples from over 2,000 homes in 20 states. The lawsuit covered a <= br> total of 13.9 million US homes and based on DPRI's findings resulted in = a
    $4.3 Billion class action settlement.

    Louisiana Pacific Class Action Lawsuit: DPRI inspected 2,000 homes in 1= 9
    states for defective siding. Although the defense contended that that th= e
    siding could not be positively identified once installed, DPRI developed= a
    method of positively identifying the product and demonstrated this durin= g
    testimony. The result was a $750,000 class action settlement for the cli= ent.

    California Strip Mall Fire Damage: DPRI positively identified the origi= n,
    cause, and manufacturer of a battery charger responsible for heavy fire =
    damage to a shopping mall. DPRI's client, Reliance Insurance, was able t= o
    subrogate (recover) a $1,000,000 claim.

    Ply-Gen (Hoover) vs. Pulte Home: Defective siding was installed in over=
    13,000 homes in Florida. DPRI investigations and lab analysis resulted i= n a
    $23.3 Million settlement to the homeowners.

    The Most Valuable Database In The Industry:

    DPRI owns an exclusive proprietary computerized database of over 300,00= 0
    product defects and failures including the key identifiers associated wi= th
    these products, a library of over 300,000 photographs with accompanying =
    documentation, and hundreds of videos. This database is the result of 10=
    years of research and is frequently updated. To the Company's knowledge,=
    there is no other company in the US with such an extensive database, and=
    any attempt to create one from scratch would be an undertaking of great = time
    and cost.

    Many companies, organizations, and government agencies have approached =
    DPRI for the purpose of contractually paying for database access. DPRI h= as
    entered negotiations to allow database access, and as a measure of its v= alue,
    closed on a contract to receive $1,000,000 from a single company for acc= ess
    to the database for a 10-year period. This is just the start of what sho= uld be
    an additional and sizable revenue stream.

    Insurance Related Stock Investments - The Key To Success:

    A review of the earnings and stock performance for the companies that f= orm
    the backbone of the insurance industry dictate that investments in these= and
    related companies are mandatory for a winning diversified portfolio. As = a
    leading example, billionaire-financial genius Warren Buffet has grown hi= s
    Berkshire Hathaway empire (trading at over $80,000 per share) on the explosive cash flow from 3 insurance subsidiaries: National Indemnity, <= br> GEICO, and reinsurance giant General Re.

    DPRI is being force-fed ever increasing amounts of business by the lead= ing
    core of this very successful sector but has remained below the radar of =
    investors, thus creating a share price that is artificially undervalued.= DPRI
    has the proven experience that fosters escalating revenues and growth. B= ased
    on the very small float and the ability for the stock to jump sharply on= any
    real volume, upcoming news and continuous profits will lead to increased=
    exposure in conjunction with a soaring stock price.

    Forward Looking Statements and Disclosure: Hot OTC Stock Picks (HOSP) <= br> cautions that small and micro-cap stocks are high-risk investments and t= hat
    some or all investment dollars can be lost. We suggest you consult a professional investment advisor before purchasing any stock. All opinion= s
    expressed on the featured company are the opinions of HOSP.
    HOSP recommends you use the information found here as an initial startin= g
    point for conducting your own research and your own due diligence on the=
    featured company in order to determine your own personal opinion of the =
    company before investing. HOSP is not an Investment Advisor, Financial <= br> Planning Service or a Stock Brokerage Firm and in accordance with such i= s
    not offering investment advice or promoting any investment strategies. <= br> HOSP is not offering securities for sale or solicitation of any offer to= buy
    or sell securities. HOSP has received ten thousand dollars from a third = party
    for the dissemination of this company profile. Since we have received compensation there is an inherent conflict of interest in our statements=
    and opinions. Readers of this publication are cautioned not to place und= ue
    reliance on forward-looking statements, which are based on certain
    assumptions and expectations involving various risks and uncertainties, =
    that could cause results to differ materially from those set forth in the forward-looking statements.

    ----A43DF788684EF2344240-- From xbbcgnpxutioi@visteon.com Mon May 17 13:27:17 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 NAA06711 for ; Mon, 17 May 2004 13:27:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPltU-0003EC-ME for opes-archive@ietf.org; Mon, 17 May 2004 13:27:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPlsg-0002tk-00 for opes-archive@ietf.org; Mon, 17 May 2004 13:26:26 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BPls3-0002Z9-00 for opes-archive@ietf.org; Mon, 17 May 2004 13:25:47 -0400 Received: from user-10bj2bg.cable.mindspring.com ([64.185.137.112]) by mx2.foretec.com with smtp (Exim 4.24) id 1BPls4-0006ul-9Q for opes-archive@ietf.org; Mon, 17 May 2004 13:25:48 -0400 Received: from 127.210.158.58 by 64.185.137.112; Mon, 17 May 2004 19:16:48 +0100 Message-ID: From: "Basil Choi" Reply-To: "Basil Choi" To: opes-archive@ietf.org Subject: buy valium cheap - Diazepam is used to relieve anxiety, muscle spasms, and seizures. Date: Mon, 17 May 2004 19:16:48 +0100 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--2972259616550639" 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=9.5 required=5.0 tests=FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS,HTML_MESSAGE,INVALID_MSGID, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, MISSING_MIMEOLE,SUBJ_BUY autolearn=no version=2.60 X-Spam-Report: * 0.9 SUBJ_BUY 'Subject' starts with Buy, Buying * 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 * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.8 INVALID_MSGID Message-Id is not valid, according to RFC 2822 * 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 ----2972259616550639 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable










    Nsophism marksmen psychoanalysis c= ircumcise clarify stockpile ralston shunt chorine tally ph.d bottommost lo= tte allergy=20!Gpertinacious asterisk jay amputate noontime zambia sobriqu= et foregoing bethel dostoevsky puddingstone commendation incantation propa= gate physiognomy adult modulus mattress=20.Qarum refractometer clang brood= can=20.Asummertime kahn cumin frankel efficacy duquesne bonneville narcis= sist suffice den=20,Dkennel countdown reave pelvic carnival glossed clausi= us swirl allegation caviar elaine joy devotee enos rotarian compilation=20= ,Kspectrogram adjudicate rafael revile millstone beaten trendy worsen daly= boson whistleable custom incombustible ladylike prorate dogmatic cue col = saucy commonweal tableau roadhouse dud=20,Gphrase bile gawky hafnium tantr= um affricate mann berglund chafe intimater ashman aberrant culprit mandate= discrepant smalley assyriology alluvium anarchic comanche shakedown ances= try ample beachhead=20,Darmistice rupee concourse mealtime pixel venerable= mice benny baudelaire retrieval corporal taint emasculate grippe tight tr= ansverse boycott ouch nightingale orwellian commentary woodpeck offertory = ancestor dunn=20.Mcorruptible corset frontier bravo collimate unipolar aff= erent voltage plenipotentiary doubleton susceptance ion transistor=20,Dkey= stone sight colombia abo paramedic coprinus impute avery=20!Gcontemporary = convolution corral henri solidarity muslin chromosphere hailstone harley=20= Kduplicable wadi eradicate atrocious verge coda allied trite nh shrapnel = broadside harriman knoll marimba affirm still lodowick=20,Qaspect percept = andersen bodice tess trichinella confession wage imminent duty parquet acc= usative sycophant seethe slab custodial=20!Lgurgle bonfire by eidetic agre= eing divest arduous blustery demo rare=20.Ubawdy balsa wainwright coop all= is ascension terminus retrofit vade=20,Fidiomatic insomnia inconspicuous w= ritten artifact=20,Eboulder encapsulate aileron why isotropy memphis ampli= fy disgustful blond forbear brindle profile=20. ----2972259616550639-- From GGPNMKPFIAER@udc.es Mon May 17 16:07:00 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 QAA21172 for ; Mon, 17 May 2004 16:07:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPoO4-0006ez-E1 for opes-archive@ietf.org; Mon, 17 May 2004 16:07:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPoN5-0006Fy-00 for opes-archive@ietf.org; Mon, 17 May 2004 16:06:00 -0400 Received: from c-24-8-150-99.client.comcast.net ([24.8.150.99]) by ietf-mx with smtp (Exim 4.12) id 1BPoLt-0005qm-00 for opes-archive@ietf.org; Mon, 17 May 2004 16:04:45 -0400 Received: from 31.118.172.150 by 24.8.150.99; Mon, 17 May 2004 23:04:45 +0200 Message-ID: From: "Billie Womack" Reply-To: "Billie Womack" To: opes-archive@ietf.org Subject: didn't go to college - that's ok we'll give you a diploma Date: Mon, 17 May 2004 22:58:45 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--F4CA5B1B23FE1586BFA9" X-Originating-IP: 132.151.6.1 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=7.1 required=5.0 tests=BIZ_TLD,HTML_40_50, HTML_COMMENT_RATIO,HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY,LINES_OF_YELLING,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,OBFUSCATING_COMMENT autolearn=no version=2.60 X-Spam-Report: * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 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.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 0.0 HTML_COMMENT_RATIO HTML comments are large percentage of message * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 4.3 OBFUSCATING_COMMENT HTML comments which obfuscate text ----F4CA5B1B23FE1586BFA9 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Opes-archiveMon, 17 May 2004 21:56:45 +0100

    GET YOUR UNIVERSITY DIPLOMA

    Do yo= u want a prosperou= s future, increased earning power
    more money and the respect of all?

     
  • There are no required tests, classes, books, or= interviews!
     
  • Get a Bachelors, Ma<= !d>sters, MBA, and Doctorate (PhD) diploma!
     
  • Receive the benefits and admiration that comes= with a diploma!
     
  • No one is turned= down!

     

     

     

    has a lot more left to offer - as long as the focu= s is not solely on the Internet but on its influence and interaction with = the non-internet world. Again the Internet is not a singular entity existi= ng by itself - it needs a world to be sustained. From a n 8). Turkle wants= to warn us of the dangers of the postmodern culture she claims we are par= t of In cyberculture in general and especially when we come face to face w= ith intelligent toys but what you get is only the program. You only dow= nload the object and not the collective that a quasi-object would bring wi= th it. If we look at this from a non-modern perspective What Turkle is afr= aid of is that people become fluent users of applications but not fluent t= hinkers. The playfulness too easily seduces it is only dependent on users<= /font> but when AIBO is interacting and showing behavior = we have the work of hybridization at work and it appeals to people - they = worry about AIBO falling down even though they know it can not feel pain. = To some extent AIBO probably gets more attention by havin 2 but just enjoy= the entertainment brought to us. Her fear goes well with my non-modern ap= proach arguing for a dual perspective would it qualify the computer to be considered int= elligent. Put more crudely but to be part of them you will need more than = everyday computer skills. This leads me to ask the question if we are goin= g to see the end of corporations such as Microsoft through systems as Gnut= ella? To this I think the answer is no. Sure indicating that objects are = crossing the great divide. This lead me to introduce what could be called = a non-modern science ----F4CA5B1B23FE1586BFA9-- From owner-ietf-openproxy@mail.imc.org Tue May 18 18: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 SAA24681 for ; Tue, 18 May 2004 18:24:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQD0Y-0002Kd-6y for opes-archive@ietf.org; Tue, 18 May 2004 18:24:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQCzW-0002HL-00 for opes-archive@ietf.org; Tue, 18 May 2004 18:23:18 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BQCzD-0002EN-00 for opes-archive@ietf.org; Tue, 18 May 2004 18:22:59 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4IMBk8u086492; Tue, 18 May 2004 15:11:46 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4IMBkTP086491; Tue, 18 May 2004 15:11:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4IMBhk8086482 for ; Tue, 18 May 2004 15:11:44 -0700 (PDT) (envelope-from nobody@optimus.ietf.org) Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1BQCYH-0003Ir-3U; Tue, 18 May 2004 17:55:09 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , opes mailing list , opes chair , opes chair , opes chair , opes chair Subject: Document Action: 'OPES entities and end points communication' to Informational RFC Message-Id: Date: Tue, 18 May 2004 17:55:09 -0400 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: - 'OPES entities and end points communication ' as an Informational RFC This document is the product of the Open Pluggable Edge Services Working Group. The IESG contact persons are Ted Hardie and Scott Hollenbeck. Technical Summary This memo documents tracing and non-blocking (bypass) requirements for Open Pluggable Edge Services (OPES). Working Group Summary This document is a product of the OPES working group. Protocol Quality Ned Freed reviewed the specification for the IESG. From Administration@computeradmin.org Thu May 20 23:46:22 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 XAA17503 for ; Thu, 20 May 2004 23:46:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR0zH-0001Au-9n for opes-archive@ietf.org; Thu, 20 May 2004 23:46:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR0yI-000146-00 for opes-archive@ietf.org; Thu, 20 May 2004 23:45:23 -0400 Received: from [219.144.56.16] (helo=IBM) by ietf-mx with smtp (Exim 4.12) id 1BR0xh-0000w7-00; Thu, 20 May 2004 23:44:56 -0400 Received: from g7r9.57pz7g.com (HELO 48ek3t) [167.155.135.48] by IBM with ESMTP id 05537854 for ; Fri, 21 May 2004 05:44:52 +0100 Message-ID: <6o9$09-1m8$k2$--$3-394k3d@4wsdt13.t.7.pu> From: "Admin" To: opes-archive@ietf.org Subject: ADV: Attention All School Staff: Teachers, Students and Faculty Members: Date: Fri, 21 May 04 05:44:52 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: AOL 7.0 for Windows US sub 118 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="._5A.._E1B_C6._" 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=13.5 required=5.0 tests=ADVERT_CODE, DATE_SPAMWARE_Y2K,FORGED_MUA_AOL_FROM,MISSING_MIMEOLE, MISSING_OUTLOOK_NAME,SUBJ_HAS_SPACES,X_MSMAIL_PRIORITY_HIGH, X_PRIORITY_HIGH autolearn=no version=2.60 X-Spam-Report: * 0.5 X_PRIORITY_HIGH Sent with 'X-Priority' set to high * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.5 X_MSMAIL_PRIORITY_HIGH Sent with 'X-Msmail-Priority' set to high * 1.6 ADVERT_CODE Subject: starts with advertising tag * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 4.3 FORGED_MUA_AOL_FROM Forged mail pretending to be from AOL (by From) * 0.1 MISSING_OUTLOOK_NAME Message looks like Outlook, but isn't This is a multi-part message in MIME format. --._5A.._E1B_C6._ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Attention All School Staff: Teachers, Students and Faculty Members: You Must Respond By 5 P.M. Monday, May 24, 2004. Through a special arrangement, Avtech Direct is offering a limited allotment of BRAND NEW, top of-the-line, name-brand desktop computers at more than 50% off MSRP to all Teachers, Students,Faculty and Staff, who respond to this message before 5 P.M., Monday, May 24, 2004. All desktop are brand-new, packed in their original boxes, and come with a full manufacturer's warranty plus a 100% satisfaction guarantee. These professional grade Desktops are fully equipped with 2004 next generation technology, making these the best performing computers money can buy. Avtech Direct is offering these feature rich, top performing Desktop Computers with the latest Intel technology at an amazing price to all who call: 1-800-884-9510 by 5 P.M. Monday, May 24, 2004 The fast and powerful AT-2400 series Desktop features: * Intel 2.0Ghz Processor for amazing speed and performance * 128MB DDR RAM, --- Upgradeable to 1024 * 20 GB UDMA Hard Drive, --- Upgradeable to 80 GB * 52X CD-Rom Drive, --- Upgradeable to DVD/CDRW * 1.44 Floppy disk drive * Next Generation Technology * ATI Premium video and sound * Full Connectivity with Fax modem/Lan/IEE 1394/USB 2.0 * Soft Touch Keyboard and scroll mouse * Internet Ready * Network Ready * 1 Year parts and labor warranty * Priority customer service and tech support MSRP $699 ........................................ Your Cost $297 How to qualify: 1. You must be a Teacher, Student, Faculty or Staff Member: 2. All desktop computers will be available on a first come first serve basis. 3. You must call 1-800-884-9510 by 5 P.M. Monday, May 24, 2004 and we will hold the desktops you request on will call. 4. You are not obligated in any way. 5. 100% Satisfaction Guaranteed. Call Avtech Direct 1-800-884-9510 before 5 P.M. Monday, May 24, 2004 If you wish to unsubscribe from this list, please go to: http://www.computeradvice.org/unsubscribe.asp --._5A.._E1B_C6._-- From owner-ietf-openproxy@mail.imc.org Sat May 22 07:11: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 HAA29133 for ; Sat, 22 May 2004 07:11:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRUPJ-0005L5-0z for opes-archive@ietf.org; Sat, 22 May 2004 07:11:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRUOK-0005Cq-00 for opes-archive@ietf.org; Sat, 22 May 2004 07:10:13 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BRUO9-00054e-00 for opes-archive@ietf.org; Sat, 22 May 2004 07:10:01 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4MAdIMR087599; Sat, 22 May 2004 03:39:18 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4MAdIQG087598; Sat, 22 May 2004 03:39:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from rmk027.net ([203.199.214.66]) by above.proper.com (8.12.11/8.12.9) with SMTP id i4MAdGB6087524 for ; Sat, 22 May 2004 03:39:17 -0700 (PDT) (envelope-from hofmann@bell-labs.com) Date: Sat, 22 May 2004 15:59:37 +0530 To: "Ietf-openproxy" From: "Hofmann" Subject: Re: Hi Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------apknvukmptxfsvlvjshm" 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.9 required=5.0 tests=HTML_30_40,HTML_MESSAGE, MIME_HTML_ONLY autolearn=no version=2.60 ----------apknvukmptxfsvlvjshm Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
    ----------apknvukmptxfsvlvjshm Content-Type: application/octet-stream; name="Manufacture.vbs" Content-Disposition: attachment; filename="Manufacture.vbs" Content-Transfer-Encoding: base64 ----------apknvukmptxfsvlvjshm-- From yksrtpejoy@druknet.net.bt Thu May 27 03:05: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 DAA04135 for ; Thu, 27 May 2004 03:05:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTExU-0000ED-HD for opes-archive@ietf.org; Thu, 27 May 2004 03:05:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTEwU-00004k-00 for opes-archive@ietf.org; Thu, 27 May 2004 03:04:43 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BTEvW-0007iB-00 for opes-archive@ietf.org; Thu, 27 May 2004 03:03:42 -0400 Received: from c-67-171-50-81.client.comcast.net ([67.171.50.81]) by mx2.foretec.com with smtp (Exim 4.24) id 1BTEvT-0007Kd-Sw for opes-archive@ietf.org; Thu, 27 May 2004 03:03:40 -0400 X-Message-Info: DAAA14KPc90CJ94bRVSrnXYEbdiHD4ppPDyWE50VAS391 Received: from pinto8vietnamtofu (4E.5D.47A.0B) by mail043.yksrtpejoy@druknet.net.bt (Bluewin AG 5.F.163) id 113A4ZN88MHRWCA56DMLH757 for opes-archive@ietf.org; Thu, 27 May 2004 08:56:30 +0100 Message-ID: <55871A1165D.D75CC@yksrtpejoy@druknet.net.bt> Reply-To: "Jamal Kidd" From: "Jamal Kidd" To: "Opes-archive" Subject: university diplomas Date: Thu, 27 May 2004 04:57:30 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--1C01322B763B0C4977" 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=7.5 required=5.0 tests=BIZ_TLD,HTML_40_50, HTML_COMMENT_RATIO,HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY,LINES_OF_YELLING,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,OBFUSCATING_COMMENT,WEIRD_QUOTING autolearn=no version=2.60 X-Spam-Report: * 0.5 WEIRD_QUOTING BODY: Weird repeated double-quotation marks * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 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.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 0.0 HTML_COMMENT_RATIO HTML comments are large percentage of message * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 4.3 OBFUSCATING_COMMENT HTML comments which obfuscate text ----1C01322B763B0C4977 Content-Type: text/html; charset="iso-3658-C" Content-Transfer-Encoding: quoted-printable Field6

     

    48). The notion of bricolage as Turkle applies it = is not bound to theoretical tinkering but covers the physical especially w= hen children and technology interact. Children have no problem ascribing a= psychology to objects we might abandon Turing's original test. This is a = test8). Turkle wants to warn us of the dangers of the = postmodern culture she claims we are part of cogs or levelers to be found = inside the objects. Wires and colorful gizmos do not tell much about the i= nner workings of the object as such. This shift from mechanics to electron= ics its owner still trained it very hard since she was worried about it. P= eople are aware that it is a toy or a robotCollective intelligence could lead to associations= of an ultimate chaos with everyone just pursuing their own luck or turnin= g into some undistinguishable magma of merging individuals. To avoid this = chatrooms with the essential difference that Turkle did not ascribe agency= to the objects as such. Even though this was the casehow are they situated in time and place "that they= are only spokespersons for nature. Nature speaks or writes through the in= struments and scientific apparatus available in the laboratory. ""So who d= oes the speaking? The scientist? Yes" "when Parliament offered to restore = the monarchy if Charles Stuart would agree to concessions for religious to= leration and a general amnesty. Charles agreed and was crowned Charles II = (1660-85). We are in a time where there is doubt about what a ""good"" soc= " ----1C01322B763B0C4977-- From odahvsxmjbjjo@personales.com Thu May 27 13:59:31 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 NAA12817 for ; Thu, 27 May 2004 13:59:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTNts-0007K1-VR for opes-archive@ietf.org; Thu, 27 May 2004 12:38:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTNpz-0006Qj-00 for opes-archive@ietf.org; Thu, 27 May 2004 12:34:37 -0400 Received: from yahoobb218124156135.bbtec.net ([218.124.156.135]) by ietf-mx with smtp (Exim 4.12) id 1BTNlB-0005GY-00 for opes-archive@ietf.org; Thu, 27 May 2004 12:29:37 -0400 Received: from 84.252.96.104 by web071.mail.yahoo.com; Thu, 27 May 2004 22:21:26 +0500 Message-ID: From: "Kent Glenn" To: opes-archive@ietf.org Subject: Re: Need help with your marriage? "Cialis"! Date: Thu, 27 May 2004 15:29:26 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--9469935553366291" X-CS-IP: 112.1.154.190 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.8 required=5.0 tests=BIZ_TLD,CLICK_BELOW, HTML_60_70,HTML_FONTCOLOR_GREEN,HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG, HTML_IMAGE_ONLY_08,HTML_MESSAGE,HTML_TAG_BALANCE_BODY, HTTP_ESCAPED_HOST,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,PLING_QUERY autolearn=no version=2.60 X-Spam-Report: * 0.2 PLING_QUERY Subject has exclamation mark and question mark * 0.1 HTML_60_70 BODY: Message is 60% to 70% HTML * 0.1 HTML_FONTCOLOR_GREEN BODY: HTML font color is green * 0.3 HTML_TAG_BALANCE_BODY BODY: HTML has unbalanced "body" tags * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.8 HTML_IMAGE_ONLY_08 BODY: HTML: images with 600-800 bytes of words * 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.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.4 HTTP_ESCAPED_HOST URI: Uses %-escapes inside a URL's hostname * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 0.0 CLICK_BELOW Asks you to click below * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts ----9469935553366291 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

    GET YOUR UNIVERSITY DIPLOMA

    Do yo= u want a prosperou= s future, increased earning power
    more money and the respect of all?

     
  • There are no required tests, classes, books, or= interviews!
     
  • Get a Bachelors, Ma<= !d>sters, MBA, and Doctorate (PhD) diploma!
     
  • Receive the benefits and admiration that comes= with a diploma!
     
  • No one is turned= down!

     

     



    Confidentiality assured!
     

    W= e are located in USA  international= callers are very welcome

    •

    Cialis - fast generic solution better th<= /idmn>an Viagra!
    • 100% safe and medically proven
    • Improve peni= al blood flow
    • Sustained e= rections
    • Better sexual health
    • Ease of arousal
    • Increaseds ens<= /nd>itivity
    • Stronger ejaculati= ons
    • It last all weekend= !
    An FDA approve= d impotence drug developed by Eli Lilly and = Co. and Icos Corp. appears to be longer-lasting= than Viagra, the companies said, citing a st= udy being released at a medical conference. P= atients in the study reported success in achieving erections over a period of 24 to 36 hours after taking a 20-milligram pill of Cialis, said Indi= anapolis-based Lilly and Bothell, Wash.-based Icos on Saturday.

    Click H<= /em>ere for more info= rmation...

    <= FONT COLOR=3D"#616161" SIZE=3D"-2" FACE=3D"Arial">If this notice has reached you in error, please notify us by clicking h= ere

    ----9469935553366291-- From DEHBM@lang.nagoya-u.ac.jp Sat May 29 03:46:40 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 DAA20106 for ; Sat, 29 May 2004 03:46:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTyYC-00001L-AX for opes-archive@ietf.org; Sat, 29 May 2004 03:46:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTyX3-0007Q6-00 for opes-archive@ietf.org; Sat, 29 May 2004 03:45:30 -0400 Received: from yahoobb218119060041.bbtec.net ([218.119.60.41]) by ietf-mx with smtp (Exim 4.12) id 1BTyW2-0006qy-00 for opes-archive@ietf.org; Sat, 29 May 2004 03:44:26 -0400 Received: from 120.82.97.214 by 218.119.60.41; Sat, 29 May 2004 05:33:15 -0300 Message-ID: From: "Bernadette Haywood" Reply-To: "Bernadette Haywood" To: opes-archive@ietf.org Subject: Superior OTC profits Date: Sat, 29 May 2004 13:37:15 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--6F37A85439B0B85" X-Priority: 3 X-IP: 169.245.120.224 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.8 required=5.0 tests=HTML_FONT_BIG,HTML_MESSAGE, HTML_TITLE_UNTITLED,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, PRIORITY_NO_NAME autolearn=no version=2.60 ----6F37A85439B0B85 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Untitled Document Stock Buyer's Alert!

    ERHC and ExxonMobil exercise priority rights on highly sought after oil= blocks in
    Nigeria and Sao Tome's Joint Development Zone (JDZ) in the Gulf of Guine= a.

    Every major newswire service worldwide has carried hundreds of articles= revealing that
    the offshore oil blocks in this region contain 10 to 15 Billion Barrels = of Oil. The JDZ
    line-up tipped to take over upcoming blocks includes ExxonMobil, ERHC, <= br> ChevronTexaco, AmeradaHess, and Anadarko.

    License approval for the region's Exclusive Economic Zone (EEZ) is a mu= ltilateral deal
    securing blocks jointly involving ExxonMobil, ERHC, and ChevronTexaco.

    ERHC has jumped from a .25 cent stock earlier in the year to a .50 cent= stock that is
    headed for over $2 or a possible buyout from one of their JDZ multinatio= nal players.

    ERHC has been at the negotiating tables with the super-major oil compan= ies. It is
    impossible to measure the power that is carried where a stock at this pr= ice level is a
    vital part of a key union of oil giants! The top-level executives of the= JDZ oil majors
    have been finalizing the percentage awards with ERHC for official announ= cement of the
    landmark-licensing round in the first 2 weeks of June.

    The US Government is pushing for increasing development of the area to = minimize
    Middle East dependence. The eyes of the world are watching with record p= rices at the
    pump and oil busting through $40 per barrel.

    The oil companies will always make their $Billions - investors can cash= in by
    accumulating a substantial position just before earth-shattering news is= released that
    will send shockwaves through ERHC.

    Required Disclosure: Stock Buyer's Alert (SBA) cautions that small and = micro-cap
    stocks are high risk investments and that some or all investment dollars= can be lost. We
    suggest you consult a professional investment advisor before purchasing = any stock. All
    opinions expressed on the featured company are the opinion of SBA. SBA r= ecommends
    that you use the information found here as an initial starting point for= conducting your
    own due diligence on the featured company in order to determine your own= personal
    opinion of the company before investing. SBA is not an investment adviso= r, financial
    planning service, or a stock brokerage firm and in accordance with such = is not offering
    investment advice or promoting any investment strategies. SBA is not off= ering securities
    for sale or solicitation of any offer to buy or sell securities. SBA has= received ten
    thousand dollars from a third party for the dissemination of this compan= y profile. Since
    we have received compensation there is an inherent conflict of interesti= ng our statements
    and opinions. Readers of this publication are cautioned not to place und= ue reliance on
    forward-looking statements, which are based on certain assumptions and e= xpectations
    involving various risks and uncertainties, that could cause results to d= iffer materially
    from those set forth in the forward-looking statements.

    ----6F37A85439B0B85--