From gonzalo.camarillo@ericsson.com Wed Apr 3 03:25:42 2013 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2886221F86AF for ; Wed, 3 Apr 2013 03:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.065 X-Spam-Level: X-Spam-Status: No, score=-106.065 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9+kn7oR1QPR for ; Wed, 3 Apr 2013 03:25:41 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD9721F87D5 for ; Wed, 3 Apr 2013 03:25:40 -0700 (PDT) X-AuditID: c1b4fb30-b7f0d6d000007e61-15-515c039edb68 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 74.F7.32353.E930C515; Wed, 3 Apr 2013 12:25:34 +0200 (CEST) Received: from [131.160.36.146] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Apr 2013 12:25:34 +0200 Message-ID: <515C039E.1040605@ericsson.com> Date: Wed, 3 Apr 2013 13:25:34 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Robert Sparks References: <20130224160353.A2FB2B1E002@rfc-editor.org> <514C7604.9000903@nostrum.com> In-Reply-To: <514C7604.9000903@nostrum.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+Jvre485phAg1d7bCya5/9jtHh9eCWT xef9+5ktPm95xmpxbU4jm8XUPlsHNo8ftwM9nizaweixc9Zddo8lS34yeUzeOIvFY9bOJywB bFFcNimpOZllqUX6dglcGUv7r7MXnJOt2LrlEWsD43TxLkZODgkBE4n/ry8xQthiEhfurWfr YuTiEBI4xSjxf9FsRghnNaPEyf2zmLsYOTh4BbQljhzzBDFZBFQk7jzPBOllE7CQ2HLrPguI LSoQJbF3w2VmEJtXQFDi5MwnYHERAQ2Ja0uWsIPYzAJVEg9ebwLbKyxgLnFv/X5WEFtIIEyi +3sTWJwTaNP+q0eYIG6TlFg0rZMFoldPYsrVFkYIW15i+9s5zBC92hLLn7WwTGAUmoVk9Swk LbOQtCxgZF7FyJ6bmJmTXm6+iREY9Ae3/DbYwbjpvtghRmkOFiVx3nDXCwFCAumJJanZqakF qUXxRaU5qcWHGJk4OKUaGIUffmXibDmlK/Oo2KdRU/DM8gVtv9xZfBJ/F/gZPDpisr/o3wrL S3cqzzxUPFi8STuvfMlGoTtsbM3Hjgrtqj5QVr/u/A2FmAXWKwVbnbe0tFxXOyT0/9W/f5Pa 71hc2t1+NP/eqhNvrR5qsjSW2Suwb5cPu2EbOr3CNjDf1Tjmrb/UlCubTimxFGckGmoxFxUn AgD++rTGSAIAAA== Cc: jdrosen@dynamicsoft.com, rai@ietf.org Subject: Re: [RAI] [Technical Errata Reported] RFC3680 (3494) X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 10:25:42 -0000 Hi, I have just verified (i.e., approved) this one. Cheers, Gonzalo On 22/03/2013 5:17 PM, Robert Sparks wrote: > (I'm doing a sweep of the outstanding reported RAI errata to help > Richard and Gonzalo process them) > > This is on the border between Hold For Document Update and Approve for me, > (This falls into the errors in examples that won't introduce substantive > confusion), but > I recommend Approval. > > RjS > > On 2/24/13 10:03 AM, RFC Errata System wrote: >> The following errata report has been submitted for RFC3680, >> "A Session Initiation Protocol (SIP) Event Package for Registrations". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3680&eid=3494 >> >> -------------------------------------- >> Type: Technical >> Reported by: Brett Tate >> >> Section: 6 >> >> Original Text >> ------------- >> NOTIFY sip:app.example.com SIP/2.0 >> Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaii >> From: sip:joe@example.com;tag=xyzygg >> To: sip:app.example.com;tag=123aa9 >> Call-ID: 9987@app.example.com >> CSeq: 1288 NOTIFY >> Contact: sip:server19.example.com >> Event: reg >> Max-Forwards: 70 >> Content-Type: application/reginfo+xml >> Content-Length: ... >> >> NOTIFY sip:app.example.com SIP/2.0 >> Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaij >> From: sip:joe@example.com;tag=xyzygg >> To: sip:app.example.com;tag=123aa9 >> Call-ID: 9987@app.example.com >> CSeq: 1289 NOTIFY >> Contact: sip:server19.example.com >> Event: reg >> Max-Forwards: 70 >> Content-Type: application/reginfo+xml >> Content-Length: ... >> >> >> Corrected Text >> -------------- >> NOTIFY sip:app.example.com SIP/2.0 >> Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaii >> From: sip:joe@example.com;tag=xyzygg >> To: sip:app.example.com;tag=123aa9 >> Call-ID: 9987@app.example.com >> CSeq: 1288 NOTIFY >> Contact: sip:server19.example.com >> Event: reg >> Subscription-State:active;expires=3600 >> Max-Forwards: 70 >> Content-Type: application/reginfo+xml >> Content-Length: ... >> >> NOTIFY sip:app.example.com SIP/2.0 >> Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaij >> From: sip:joe@example.com;tag=xyzygg >> To: sip:app.example.com;tag=123aa9 >> Call-ID: 9987@app.example.com >> CSeq: 1289 NOTIFY >> Contact: sip:server19.example.com >> Event: reg >> Subscription-State:active;expires=3000 >> Max-Forwards: 70 >> Content-Type: application/reginfo+xml >> Content-Length: ... >> >> >> Notes >> ----- >> The two NOTIFY examples are missing mandatory Subscription-State header. >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC3680 (draft-ietf-sipping-reg-event-00) >> -------------------------------------- >> Title : A Session Initiation Protocol (SIP) Event >> Package for Registrations >> Publication Date : March 2004 >> Author(s) : J. Rosenberg >> Category : PROPOSED STANDARD >> Source : Session Initiation Proposal Investigation >> Area : Real-time Applications and Infrastructure >> Stream : IETF >> Verifying Party : IESG > > From gonzalo.camarillo@ericsson.com Thu Apr 4 00:03:26 2013 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6F321F866E for ; Thu, 4 Apr 2013 00:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.232 X-Spam-Level: X-Spam-Status: No, score=-106.232 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7iBBknPGYc7 for ; Thu, 4 Apr 2013 00:03:25 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC8021F8540 for ; Thu, 4 Apr 2013 00:03:25 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-6a-515d25bc8adb Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id B0.00.10459.CB52D515; Thu, 4 Apr 2013 09:03:24 +0200 (CEST) Received: from [131.160.36.146] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Apr 2013 09:03:24 +0200 Message-ID: <515D25BC.8060502@ericsson.com> Date: Thu, 4 Apr 2013 10:03:24 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: rai@ietf.org X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKJMWRmVeSWpSXmKPExsUyM+Jvre4e1dhAg7PbtSw+b3nGajG1z9aB yWPJkp9MHpM3zmIJYIrisklJzcksSy3St0vgyli4wqZgAmvFk8O+DYxNLF2MnBwSAiYSaw+8 YoawxSQu3FvP1sXIxSEkcIpR4sXjfYwgCSGB1YwSJ+Z6gti8AtoSUx42sYLYLAIqEvNbHzKB 2GwCFhJbbt0HGyoqECWxd8NlZoh6QYmTM5+AxUUEBCQWPFsBFmcWkJe4+mUv2BxhAU2JLVen Qh0kKbFoWicLRI2exJSrLYww9dvfzmGGuEdbYvmzFpYJjAKzkKyYhaRlFpKWBYzMqxjZcxMz c9LLDTcxAoPu4JbfujsYT50TOcQozcGiJM4b5nohQEggPbEkNTs1tSC1KL6oNCe1+BAjEwen VAOjpXFzon2Vda7B/TPecuFXVsemWD1ztP0YdzT7oM/5TAen/4qTJgX93LLUPHcT21ynjhm3 Nxjefnsi5VIh74RPM0KYPizX7ls1JUTBt1H9fCCn8AZ2bQ2nWs3mRdJpi2zPz/+/OUOjVC7S 6vgLrQ6P988Yj1iJ+ohLLTzHpO4olfM+a/WR90VKLMUZiYZazEXFiQCjXQA4CAIAAA== Subject: [RAI] Call for volunteers to chair WGs X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 07:03:26 -0000 Folks, as you know, every now and then we need to fill chair positions in both new and existing WGs. If you could be interested in chairing a WG in the RAI area at some point, please send us and email. We understand people are typically interested in a specific WG. It is also typical to get management approval to chair a particular WG. Nevertheless, knowing that you may be interested in a chair position and which areas you are mostly working on would be useful to us. Additionally, every time we agree to charter a new WG (in DISPATCH or in a BOF) you are interested in chairing, you should let us know as well. Thanks, Gonzalo From rifatyu@avaya.com Wed Apr 10 10:50:57 2013 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B341F21F8ED4 for ; Wed, 10 Apr 2013 10:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s62OMyHxvXm9 for ; Wed, 10 Apr 2013 10:50:54 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id A4D7421F8EB9 for ; Wed, 10 Apr 2013 10:50:53 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFANBuZVHGmAcF/2dsb2JhbABQgmUhNsEogRAWdIIfAQEBAQIBEiguBgsFBwQCAQgNAQMEAQEBChQJBzIUCQgBAQQOBQgMDodsBgELoTecaBMEjVKBESYLBwaCWmEDnR+KaYMLgXM1 X-IronPort-AV: E=Sophos;i="4.84,766,1355115600"; d="scan'208";a="6444438" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 10 Apr 2013 13:50:52 -0400 Received: from unknown (HELO AZ-US1EXHC02.global.avaya.com) ([135.11.85.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 10 Apr 2013 13:48:03 -0400 Received: from AZ-US1EXMB01.global.avaya.com ([fe80::54fa:ed52:888e:7ca8]) by AZ-US1EXHC02.global.avaya.com ([::1]) with mapi id 14.02.0328.009; Wed, 10 Apr 2013 13:50:51 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Robert Sparks Thread-Topic: Conference Focus Indicating CCMP Support draft Thread-Index: Ac41UqOwQn61izg0SJyesqCVCdwaeQAkIBsAAA26cIAABtgOsP//+foAgABAFUA= Date: Wed, 10 Apr 2013 17:50:50 +0000 Message-ID: References: <51651C5C.1020104@ericsson.com> <5165787D.8010501@nostrum.com> <5165A15E.20401@nostrum.com> In-Reply-To: <5165A15E.20401@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.48] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rai@ietf.org" Subject: Re: [RAI] Conference Focus Indicating CCMP Support draft X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 17:50:57 -0000 Adding the RAI distribution to this discussion per Robert's request. Thanks Robert, > That _redefines_ Call-Info even if it leaves the syntax the same. > The definition for the header would be in _this_ document, not in 3261 > if you leave the ABNF like this. I now understand your concern. I would like to go with the option of removing the ABNF and just define the= new value. Do others see value with the second option: > But if you do mess with the ABNF, make this change: >=20 > info-param =3D ( "purpose" EQUAL ( info-purpose-choices) ) / generic-para= m > info-purpose-choices =3D "icon" / "info" / "card" / "ccmp " / token >=20 > so that the _next_ draft that comes along that wants to add a purpose > choice can simply say > info-purpose-choices =3D/ "foo" >=20 > If you go down this path, you should also check with the community > whether we should > create an IANA registry for these choices. I don't think it's worth it, > but there have been > similar conversations where the rough consensus was to create one. Thanks, Rifaat > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@nostrum.com] > Sent: Wednesday, April 10, 2013 1:29 PM > To: Shekh-Yusef, Rifaat (Rifaat) > Cc: Gonzalo Camarillo; rlb@ipv.sx; Mary Barnes; Alan Johnston > Subject: Re: Conference Focus Indicating CCMP Support draft >=20 > On 4/10/13 12:08 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > Hi Robert, > > > > Thanks for your feedback. > > > >> The one thing that sticks out is the complete redefinition of the > >> Call-Info header syntax just to add a parameter > >> to info-param. > > The draft is not changing the syntax of the Call-Info header; the > absoluteURI will be an XCON-URI and we are defining a new "ccmp" token > to indicate that the URI supports ccmp. > > Where do you see that we are redefining the syntax? > The draft contains this: >=20 > The following is the updated ABNF for the Call-Info header: >=20 > Call-Info =3D "Call-Info" HCOLON info *(COMMA info) > info =3D LAQUOT absoluteURI RAQUOT *( SEMI info-param) > info-param =3D ( "purpose" EQUAL ( "icon" / "info" > / "card" / "ccmp" / token ) ) / generic-param >=20 > That _redefines_ Call-Info even if it leaves the syntax the same. > The definition for the header would be in _this_ document, not in 3261 > if you leave the ABNF like this. >=20 > At the very least, don't restate Call-Info and info. Redefine only > info-param. >=20 > You could just define the value and not mess with the ABNF. That is the > avenue I would recommend. >=20 > But if you do mess with the ABNF, make this change: >=20 > info-param =3D ( "purpose" EQUAL ( info-purpose-choices) ) / generic-para= m > info-purpose-choices =3D "icon" / "info" / "card" / "ccmp " / token >=20 > so that the _next_ draft that comes along that wants to add a purpose > choice can simply say > info-purpose-choices =3D/ "foo" >=20 > If you go down this path, you should also check with the community > whether we should > create an IANA registry for these choices. I don't think it's worth it, > but there have been > similar conversations where the rough consensus was to create one. >=20 > Also, it's unfortunate that this conversation isn't on a list. If we > continue, please add a list to the distribution. > I suggest rai@ietf.org. >=20 > RjS >=20 >=20 >=20 > > > > Regards, > > Rifaat > > > > > >> -----Original Message----- > >> From: Robert Sparks [mailto:rjsparks@nostrum.com] > >> Sent: Wednesday, April 10, 2013 10:35 AM > >> To: Gonzalo Camarillo > >> Cc: Shekh-Yusef, Rifaat (Rifaat); rlb@ipv.sx; Mary Barnes; Alan > Johnston > >> Subject: Re: Conference Focus Indicating CCMP Support draft > >> > >> We had not yet started. The next step is for the authors to request > >> publication (when they believe it is ready), > >> and you or Richard can start fresh with an initial AD review. > >> > >> I skimmed the version of the draft linked to below - I still don't > >> expect controversy or much in the way of changes. > >> The one thing that sticks out is the complete redefinition of the > >> Call-Info header syntax just to add a parameter > >> to info-param. It would be much better to find a way to use the > >> Incremental Alternative (=3D/) production rule. > >> If that's not possible the way Call-Info is currently defined, we > should > >> redefine it _once_ to make it possible. > >> IIRC there are other things in flight that are touching Call-Info - > you > >> should make sure they're aligned. > >> > >> RjS > >> > >> On 4/10/13 3:01 AM, Gonzalo Camarillo wrote: > >>> Hi Robert, > >>> > >>> the authors of the draft below just sent us the email below. They > >>> mention you had agreed to AD sponsor it. What is the next step here > so > >>> that Richard or I can take this over? > >>> > >>> Thanks, > >>> > >>> Gonzalo > >>> > >>> On 09/04/2013 9:47 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > >>>> Gonzalo, Richard, > >>>> > >>>> > >>>> > >>>> Mary and I have been working on the following "Conference Focus > >>>> Indicating CCMP Support" draft, which Robert agreed to AD sponsor a > >>>> while back. > >>>> > >>>> https://datatracker.ietf.org/doc/draft-yusef-dispatch-ccmp- > >> indication/?include_text=3D1 > >>>> > >>>> > >>>> The draft is simple and straightforward which was discussed on the > >>>> DISPATCH mailing list. > >>>> > >>>> Robert Sparks, Alan Johnston, Cullen Jennings, and Adam Roach all > >>>> reviewed it and provided feedback which was incorporated into the > >> latest > >>>> version of the draft. > >>>> > >>>> Alan Johnston is the document shepherd and he worked on the writeup > >> for > >>>> this draft. > >>>> > >>>> > >>>> > >>>> Now that Robert is no longer an AD, can one of you please sponsor > >> this > >>>> draft instead? > >>>> > >>>> > >>>> > >>>> Thanks, > >>>> > >>>> Rifaat > >>>> > >>>> > >>>> > >>>> > >>>> From keith.drage@alcatel-lucent.com Wed Apr 10 18:26:47 2013 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6844421F8A91 for ; Wed, 10 Apr 2013 18:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKelV8O3rGHR for ; Wed, 10 Apr 2013 18:26:46 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 8B64A21F8A7E for ; Wed, 10 Apr 2013 18:26:46 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r3B1QgMj021768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 10 Apr 2013 20:26:42 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id r3B1QerH007595 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Apr 2013 21:26:41 -0400 Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 10 Apr 2013 21:26:40 -0400 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.201]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Thu, 11 Apr 2013 03:26:37 +0200 From: "DRAGE, Keith (Keith)" To: "Shekh-Yusef, Rifaat (Rifaat)" , Robert Sparks Thread-Topic: Conference Focus Indicating CCMP Support draft Thread-Index: Ac41UqOwQn61izg0SJyesqCVCdwaeQAkIBsAAA26cIAABtgOsP//+foAgABAFUD///4KoA== Date: Thu, 11 Apr 2013 01:26:36 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0260CD@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <51651C5C.1020104@ericsson.com> <5165787D.8010501@nostrum.com> <5165A15E.20401@nostrum.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "rai@ietf.org" Subject: Re: [RAI] Conference Focus Indicating CCMP Support draft X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 01:26:47 -0000 I prefer the approach to that defines the ABNF in a way that allows it to b= e extended with=20 info-purpose-choices =3D/ "foo" in a future specification or other document. Keith > -----Original Message----- > From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On Behalf Of > Shekh-Yusef, Rifaat (Rifaat) > Sent: 10 April 2013 18:51 > To: Robert Sparks > Cc: rai@ietf.org > Subject: Re: [RAI] Conference Focus Indicating CCMP Support draft >=20 > Adding the RAI distribution to this discussion per Robert's request. >=20 >=20 > Thanks Robert, >=20 > > That _redefines_ Call-Info even if it leaves the syntax the same. > > The definition for the header would be in _this_ document, not in 3261 > > if you leave the ABNF like this. >=20 > I now understand your concern. > I would like to go with the option of removing the ABNF and just define > the new value. >=20 >=20 > Do others see value with the second option: >=20 > > But if you do mess with the ABNF, make this change: > > > > info-param =3D ( "purpose" EQUAL ( info-purpose-choices) ) / generic-pa= ram > > info-purpose-choices =3D "icon" / "info" / "card" / "ccmp " / token > > > > so that the _next_ draft that comes along that wants to add a purpose > > choice can simply say > > info-purpose-choices =3D/ "foo" > > > > If you go down this path, you should also check with the community > > whether we should > > create an IANA registry for these choices. I don't think it's worth it, > > but there have been > > similar conversations where the rough consensus was to create one. >=20 >=20 > Thanks, > Rifaat >=20 >=20 > > -----Original Message----- > > From: Robert Sparks [mailto:rjsparks@nostrum.com] > > Sent: Wednesday, April 10, 2013 1:29 PM > > To: Shekh-Yusef, Rifaat (Rifaat) > > Cc: Gonzalo Camarillo; rlb@ipv.sx; Mary Barnes; Alan Johnston > > Subject: Re: Conference Focus Indicating CCMP Support draft > > > > On 4/10/13 12:08 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > > Hi Robert, > > > > > > Thanks for your feedback. > > > > > >> The one thing that sticks out is the complete redefinition of the > > >> Call-Info header syntax just to add a parameter > > >> to info-param. > > > The draft is not changing the syntax of the Call-Info header; the > > absoluteURI will be an XCON-URI and we are defining a new "ccmp" token > > to indicate that the URI supports ccmp. > > > Where do you see that we are redefining the syntax? > > The draft contains this: > > > > The following is the updated ABNF for the Call-Info header: > > > > Call-Info =3D "Call-Info" HCOLON info *(COMMA info) > > info =3D LAQUOT absoluteURI RAQUOT *( SEMI info-param) > > info-param =3D ( "purpose" EQUAL ( "icon" / "info" > > / "card" / "ccmp" / token ) ) / generic-param > > > > That _redefines_ Call-Info even if it leaves the syntax the same. > > The definition for the header would be in _this_ document, not in 3261 > > if you leave the ABNF like this. > > > > At the very least, don't restate Call-Info and info. Redefine only > > info-param. > > > > You could just define the value and not mess with the ABNF. That is the > > avenue I would recommend. > > > > But if you do mess with the ABNF, make this change: > > > > info-param =3D ( "purpose" EQUAL ( info-purpose-choices) ) / generic-pa= ram > > info-purpose-choices =3D "icon" / "info" / "card" / "ccmp " / token > > > > so that the _next_ draft that comes along that wants to add a purpose > > choice can simply say > > info-purpose-choices =3D/ "foo" > > > > If you go down this path, you should also check with the community > > whether we should > > create an IANA registry for these choices. I don't think it's worth it, > > but there have been > > similar conversations where the rough consensus was to create one. > > > > Also, it's unfortunate that this conversation isn't on a list. If we > > continue, please add a list to the distribution. > > I suggest rai@ietf.org. > > > > RjS > > > > > > > > > > > > Regards, > > > Rifaat > > > > > > > > >> -----Original Message----- > > >> From: Robert Sparks [mailto:rjsparks@nostrum.com] > > >> Sent: Wednesday, April 10, 2013 10:35 AM > > >> To: Gonzalo Camarillo > > >> Cc: Shekh-Yusef, Rifaat (Rifaat); rlb@ipv.sx; Mary Barnes; Alan > > Johnston > > >> Subject: Re: Conference Focus Indicating CCMP Support draft > > >> > > >> We had not yet started. The next step is for the authors to request > > >> publication (when they believe it is ready), > > >> and you or Richard can start fresh with an initial AD review. > > >> > > >> I skimmed the version of the draft linked to below - I still don't > > >> expect controversy or much in the way of changes. > > >> The one thing that sticks out is the complete redefinition of the > > >> Call-Info header syntax just to add a parameter > > >> to info-param. It would be much better to find a way to use the > > >> Incremental Alternative (=3D/) production rule. > > >> If that's not possible the way Call-Info is currently defined, we > > should > > >> redefine it _once_ to make it possible. > > >> IIRC there are other things in flight that are touching Call-Info - > > you > > >> should make sure they're aligned. > > >> > > >> RjS > > >> > > >> On 4/10/13 3:01 AM, Gonzalo Camarillo wrote: > > >>> Hi Robert, > > >>> > > >>> the authors of the draft below just sent us the email below. They > > >>> mention you had agreed to AD sponsor it. What is the next step here > > so > > >>> that Richard or I can take this over? > > >>> > > >>> Thanks, > > >>> > > >>> Gonzalo > > >>> > > >>> On 09/04/2013 9:47 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > >>>> Gonzalo, Richard, > > >>>> > > >>>> > > >>>> > > >>>> Mary and I have been working on the following "Conference Focus > > >>>> Indicating CCMP Support" draft, which Robert agreed to AD sponsor = a > > >>>> while back. > > >>>> > > >>>> https://datatracker.ietf.org/doc/draft-yusef-dispatch-ccmp- > > >> indication/?include_text=3D1 > > >>>> > > >>>> > > >>>> The draft is simple and straightforward which was discussed on the > > >>>> DISPATCH mailing list. > > >>>> > > >>>> Robert Sparks, Alan Johnston, Cullen Jennings, and Adam Roach all > > >>>> reviewed it and provided feedback which was incorporated into the > > >> latest > > >>>> version of the draft. > > >>>> > > >>>> Alan Johnston is the document shepherd and he worked on the writeu= p > > >> for > > >>>> this draft. > > >>>> > > >>>> > > >>>> > > >>>> Now that Robert is no longer an AD, can one of you please sponsor > > >> this > > >>>> draft instead? > > >>>> > > >>>> > > >>>> > > >>>> Thanks, > > >>>> > > >>>> Rifaat > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> >=20 > _______________________________________________ > RAI mailing list > RAI@ietf.org > https://www.ietf.org/mailman/listinfo/rai From pkyzivat@alum.mit.edu Thu Apr 11 08:52:28 2013 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 865DC21F8462 for ; Thu, 11 Apr 2013 08:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.177 X-Spam-Level: X-Spam-Status: No, score=-0.177 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4F+rrtZYGDP for ; Thu, 11 Apr 2013 08:52:27 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id E79F621F8B27 for ; Thu, 11 Apr 2013 08:52:26 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta05.westchester.pa.mail.comcast.net with comcast id Nbwy1l00927AodY55fsD1S; Thu, 11 Apr 2013 15:52:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id NfsD1l00B3ZTu2S3ffsDXV; Thu, 11 Apr 2013 15:52:13 +0000 Message-ID: <5166DC2D.8090905@alum.mit.edu> Date: Thu, 11 Apr 2013 23:52:13 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: rai@ietf.org References: <51651C5C.1020104@ericsson.com> <5165787D.8010501@nostrum.com> <5165A15E.20401@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1365695533; bh=9z4l54WEmzgTlyV6B0BAbTqb6YJ3AJcawtwhIJdXrvU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=jqC5UloeJp2RQvgJufXbvgNt8eDDDl22rDzyTLWhq0xeUtz1y/p1FtAxcvzboeYsf kAW3ee/Flgwa36F+xVEnySvrqnIwaNXMpeghSOhPzTF4R/BIgCkP12DSxVf5PGTmfw BN0LmExzfEtzJ6+p+8AsdN75d/qrZ7DVQY7hNQbfBpjtDDvgPAQggkxEnfH6eOE2GM 6/nPNbEo2CZPTcVaI+e9+ExXFUf1DSC7rO1CSKIsQBzI3AW3wijotPaiih51W/nZLD MjQFagPu2kcANVOWxxXWeau9NZ0VnijEnREGuldUZQfZ0qLfZy1Y/9KsL2A+p3gqIb MVOevItI4kmqg== Subject: Re: [RAI] Conference Focus Indicating CCMP Support draft X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 15:52:28 -0000 On 4/11/13 1:50 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: > Adding the RAI distribution to this discussion per Robert's request. IMO RAI isn't the best place for this discussion. I fear that some people who care won't see this. The right place to have the discussion of restructuring the ABNF for the info-param is sipcore. But I don't want to cross post, so lets reach some conclusion to this thread, and then if it becomes a sipcore concern we can post the conclusion there for confirmation. I see three ways to handle this, two of which have already been mentioned: 1) revise the ABNF so in the future it can be extended without further redefinition: info-param = info-purpose-param / generic-param info-purpose-param = "purpose" EQUAL info-purpose-choices info-purpose-choices = "icon" / "info" / "card" / token info-purpose-choices =/ "ccmp" 2) revise the ANBF to just have the choices be just "token" and add an IANA registry for values. 3) just work around the existing ABNF in a cleaner way: info-param =/ "purpose" EQUAL "ccmp" Which to do depends on how much work we want to go through now and how many new values we anticipate in the future. In this case, where the syntax isn't too complex and the number of new values is likely to be small I think (3) may be the simplest. The choice between (1) and (2) depends on whether we want to spend cycles deciding what the criteria ought to be for adding new values in the future. Thanks, Paul > Thanks Robert, > >> That _redefines_ Call-Info even if it leaves the syntax the same. >> The definition for the header would be in _this_ document, not in 3261 >> if you leave the ABNF like this. > > I now understand your concern. > I would like to go with the option of removing the ABNF and just define the new value. > > > Do others see value with the second option: > >> But if you do mess with the ABNF, make this change: >> >> info-param = ( "purpose" EQUAL ( info-purpose-choices) ) / generic-param >> info-purpose-choices = "icon" / "info" / "card" / "ccmp " / token >> >> so that the _next_ draft that comes along that wants to add a purpose >> choice can simply say >> info-purpose-choices =/ "foo" >> >> If you go down this path, you should also check with the community >> whether we should >> create an IANA registry for these choices. I don't think it's worth it, >> but there have been >> similar conversations where the rough consensus was to create one. > > > Thanks, > Rifaat > > >> -----Original Message----- >> From: Robert Sparks [mailto:rjsparks@nostrum.com] >> Sent: Wednesday, April 10, 2013 1:29 PM >> To: Shekh-Yusef, Rifaat (Rifaat) >> Cc: Gonzalo Camarillo; rlb@ipv.sx; Mary Barnes; Alan Johnston >> Subject: Re: Conference Focus Indicating CCMP Support draft >> >> On 4/10/13 12:08 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: >>> Hi Robert, >>> >>> Thanks for your feedback. >>> >>>> The one thing that sticks out is the complete redefinition of the >>>> Call-Info header syntax just to add a parameter >>>> to info-param. >>> The draft is not changing the syntax of the Call-Info header; the >> absoluteURI will be an XCON-URI and we are defining a new "ccmp" token >> to indicate that the URI supports ccmp. >>> Where do you see that we are redefining the syntax? >> The draft contains this: >> >> The following is the updated ABNF for the Call-Info header: >> >> Call-Info = "Call-Info" HCOLON info *(COMMA info) >> info = LAQUOT absoluteURI RAQUOT *( SEMI info-param) >> info-param = ( "purpose" EQUAL ( "icon" / "info" >> / "card" / "ccmp" / token ) ) / generic-param >> >> That _redefines_ Call-Info even if it leaves the syntax the same. >> The definition for the header would be in _this_ document, not in 3261 >> if you leave the ABNF like this. >> >> At the very least, don't restate Call-Info and info. Redefine only >> info-param. >> >> You could just define the value and not mess with the ABNF. That is the >> avenue I would recommend. >> >> But if you do mess with the ABNF, make this change: >> >> info-param = ( "purpose" EQUAL ( info-purpose-choices) ) / generic-param >> info-purpose-choices = "icon" / "info" / "card" / "ccmp " / token >> >> so that the _next_ draft that comes along that wants to add a purpose >> choice can simply say >> info-purpose-choices =/ "foo" >> >> If you go down this path, you should also check with the community >> whether we should >> create an IANA registry for these choices. I don't think it's worth it, >> but there have been >> similar conversations where the rough consensus was to create one. >> >> Also, it's unfortunate that this conversation isn't on a list. If we >> continue, please add a list to the distribution. >> I suggest rai@ietf.org. >> >> RjS >> >> >> >>> >>> Regards, >>> Rifaat >>> >>> >>>> -----Original Message----- >>>> From: Robert Sparks [mailto:rjsparks@nostrum.com] >>>> Sent: Wednesday, April 10, 2013 10:35 AM >>>> To: Gonzalo Camarillo >>>> Cc: Shekh-Yusef, Rifaat (Rifaat); rlb@ipv.sx; Mary Barnes; Alan >> Johnston >>>> Subject: Re: Conference Focus Indicating CCMP Support draft >>>> >>>> We had not yet started. The next step is for the authors to request >>>> publication (when they believe it is ready), >>>> and you or Richard can start fresh with an initial AD review. >>>> >>>> I skimmed the version of the draft linked to below - I still don't >>>> expect controversy or much in the way of changes. >>>> The one thing that sticks out is the complete redefinition of the >>>> Call-Info header syntax just to add a parameter >>>> to info-param. It would be much better to find a way to use the >>>> Incremental Alternative (=/) production rule. >>>> If that's not possible the way Call-Info is currently defined, we >> should >>>> redefine it _once_ to make it possible. >>>> IIRC there are other things in flight that are touching Call-Info - >> you >>>> should make sure they're aligned. >>>> >>>> RjS >>>> >>>> On 4/10/13 3:01 AM, Gonzalo Camarillo wrote: >>>>> Hi Robert, >>>>> >>>>> the authors of the draft below just sent us the email below. They >>>>> mention you had agreed to AD sponsor it. What is the next step here >> so >>>>> that Richard or I can take this over? >>>>> >>>>> Thanks, >>>>> >>>>> Gonzalo >>>>> >>>>> On 09/04/2013 9:47 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: >>>>>> Gonzalo, Richard, >>>>>> >>>>>> >>>>>> >>>>>> Mary and I have been working on the following "Conference Focus >>>>>> Indicating CCMP Support" draft, which Robert agreed to AD sponsor a >>>>>> while back. >>>>>> >>>>>> https://datatracker.ietf.org/doc/draft-yusef-dispatch-ccmp- >>>> indication/?include_text=1 >>>>>> >>>>>> >>>>>> The draft is simple and straightforward which was discussed on the >>>>>> DISPATCH mailing list. >>>>>> >>>>>> Robert Sparks, Alan Johnston, Cullen Jennings, and Adam Roach all >>>>>> reviewed it and provided feedback which was incorporated into the >>>> latest >>>>>> version of the draft. >>>>>> >>>>>> Alan Johnston is the document shepherd and he worked on the writeup >>>> for >>>>>> this draft. >>>>>> >>>>>> >>>>>> >>>>>> Now that Robert is no longer an AD, can one of you please sponsor >>>> this >>>>>> draft instead? >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Rifaat >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> > > _______________________________________________ > RAI mailing list > RAI@ietf.org > https://www.ietf.org/mailman/listinfo/rai > From rifatyu@avaya.com Thu Apr 11 11:38:20 2013 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E91821F8F6D for ; Thu, 11 Apr 2013 11:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sN4oyGhkNCUf for ; Thu, 11 Apr 2013 11:38:19 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id E6E8E21F8F5D for ; Thu, 11 Apr 2013 11:38:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAAH/ZlHGmAcF/2dsb2JhbABQDoJXITbBSIEHFnSCHwEBAQEDAQEBDyguBhcEAgEIDQEDBAEBAQoUCQcnCxQJCAIEARIIAQsOh3IBC6A8nQwXjVQQgQEmDQUGglphA50pimiCTD+BczU X-IronPort-AV: E=Sophos;i="4.87,456,1363147200"; d="scan'208";a="5110381" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 11 Apr 2013 14:38:16 -0400 Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 11 Apr 2013 14:35:24 -0400 Received: from AZ-US1EXMB01.global.avaya.com ([fe80::54fa:ed52:888e:7ca8]) by AZ-US1EXHC01.global.avaya.com ([135.11.85.12]) with mapi id 14.02.0328.009; Thu, 11 Apr 2013 14:38:15 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Paul Kyzivat , "rai@ietf.org" Thread-Topic: [RAI] Conference Focus Indicating CCMP Support draft Thread-Index: Ac41UqOwQn61izg0SJyesqCVCdwaeQAkIBsAAA26cIAABtgOsP//+foAgABAFUCAATczgIAAGNHw Date: Thu, 11 Apr 2013 18:38:14 +0000 Message-ID: References: <51651C5C.1020104@ericsson.com> <5165787D.8010501@nostrum.com> <5165A15E.20401@nostrum.com> <5166DC2D.8090905@alum.mit.edu> In-Reply-To: <5166DC2D.8090905@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [RAI] Conference Focus Indicating CCMP Support draft X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 18:38:20 -0000 I think that if we are to revise the ABNF, then we need a separate document= for that. If there is enough interest, I would be willing to work on that = document. For this document, I prefer to go with option 3. Regarding the IANA registry, we had a similar discussion on the DISPATCH ma= iling list in the context of the XMPP work, and the conclusion was that we = did not need a registry: http://www.ietf.org/mail-archive/web/dispatch/current/msg04628.html Are you saying that we need a registry *if* we revise the ABNF? Regards, Rifaat > -----Original Message----- > From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Thursday, April 11, 2013 11:52 AM > To: rai@ietf.org > Subject: Re: [RAI] Conference Focus Indicating CCMP Support draft >=20 > On 4/11/13 1:50 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > Adding the RAI distribution to this discussion per Robert's request. >=20 > IMO RAI isn't the best place for this discussion. > I fear that some people who care won't see this. > The right place to have the discussion of restructuring the ABNF for the > info-param is sipcore. But I don't want to cross post, so lets reach > some conclusion to this thread, and then if it becomes a sipcore concern > we can post the conclusion there for confirmation. >=20 > I see three ways to handle this, two of which have already been > mentioned: >=20 > 1) revise the ABNF so in the future it can be extended without > further redefinition: >=20 > info-param =3D info-purpose-param / generic-param > info-purpose-param =3D "purpose" EQUAL info-purpose-choices > info-purpose-choices =3D "icon" / "info" / "card" / token > info-purpose-choices =3D/ "ccmp" >=20 > 2) revise the ANBF to just have the choices be just "token" > and add an IANA registry for values. >=20 > 3) just work around the existing ABNF in a cleaner way: >=20 > info-param =3D/ "purpose" EQUAL "ccmp" >=20 > Which to do depends on how much work we want to go through now and how > many new values we anticipate in the future. In this case, where the > syntax isn't too complex and the number of new values is likely to be > small I think (3) may be the simplest. >=20 > The choice between (1) and (2) depends on whether we want to spend > cycles deciding what the criteria ought to be for adding new values in > the future. >=20 > Thanks, > Paul >=20 > > Thanks Robert, > > > >> That _redefines_ Call-Info even if it leaves the syntax the same. > >> The definition for the header would be in _this_ document, not in > 3261 > >> if you leave the ABNF like this. > > > > I now understand your concern. > > I would like to go with the option of removing the ABNF and just > define the new value. > > > > > > Do others see value with the second option: > > > >> But if you do mess with the ABNF, make this change: > >> > >> info-param =3D ( "purpose" EQUAL ( info-purpose-choices) ) / generic- > param > >> info-purpose-choices =3D "icon" / "info" / "card" / "ccmp " / token > >> > >> so that the _next_ draft that comes along that wants to add a > purpose > >> choice can simply say > >> info-purpose-choices =3D/ "foo" > >> > >> If you go down this path, you should also check with the community > >> whether we should > >> create an IANA registry for these choices. I don't think it's worth > it, > >> but there have been > >> similar conversations where the rough consensus was to create one. > > > > > > Thanks, > > Rifaat > > > > > >> -----Original Message----- > >> From: Robert Sparks [mailto:rjsparks@nostrum.com] > >> Sent: Wednesday, April 10, 2013 1:29 PM > >> To: Shekh-Yusef, Rifaat (Rifaat) > >> Cc: Gonzalo Camarillo; rlb@ipv.sx; Mary Barnes; Alan Johnston > >> Subject: Re: Conference Focus Indicating CCMP Support draft > >> > >> On 4/10/13 12:08 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > >>> Hi Robert, > >>> > >>> Thanks for your feedback. > >>> > >>>> The one thing that sticks out is the complete redefinition of the > >>>> Call-Info header syntax just to add a parameter > >>>> to info-param. > >>> The draft is not changing the syntax of the Call-Info header; the > >> absoluteURI will be an XCON-URI and we are defining a new "ccmp" > token > >> to indicate that the URI supports ccmp. > >>> Where do you see that we are redefining the syntax? > >> The draft contains this: > >> > >> The following is the updated ABNF for the Call-Info header: > >> > >> Call-Info =3D "Call-Info" HCOLON info *(COMMA info) > >> info =3D LAQUOT absoluteURI RAQUOT *( SEMI info-param) > >> info-param =3D ( "purpose" EQUAL ( "icon" / "info" > >> / "card" / "ccmp" / token ) ) / generic-param > >> > >> That _redefines_ Call-Info even if it leaves the syntax the same. > >> The definition for the header would be in _this_ document, not in > 3261 > >> if you leave the ABNF like this. > >> > >> At the very least, don't restate Call-Info and info. Redefine only > >> info-param. > >> > >> You could just define the value and not mess with the ABNF. That is > the > >> avenue I would recommend. > >> > >> But if you do mess with the ABNF, make this change: > >> > >> info-param =3D ( "purpose" EQUAL ( info-purpose-choices) ) / generic- > param > >> info-purpose-choices =3D "icon" / "info" / "card" / "ccmp " / token > >> > >> so that the _next_ draft that comes along that wants to add a > purpose > >> choice can simply say > >> info-purpose-choices =3D/ "foo" > >> > >> If you go down this path, you should also check with the community > >> whether we should > >> create an IANA registry for these choices. I don't think it's worth > it, > >> but there have been > >> similar conversations where the rough consensus was to create one. > >> > >> Also, it's unfortunate that this conversation isn't on a list. If we > >> continue, please add a list to the distribution. > >> I suggest rai@ietf.org. > >> > >> RjS > >> > >> > >> > >>> > >>> Regards, > >>> Rifaat > >>> > >>> > >>>> -----Original Message----- > >>>> From: Robert Sparks [mailto:rjsparks@nostrum.com] > >>>> Sent: Wednesday, April 10, 2013 10:35 AM > >>>> To: Gonzalo Camarillo > >>>> Cc: Shekh-Yusef, Rifaat (Rifaat); rlb@ipv.sx; Mary Barnes; Alan > >> Johnston > >>>> Subject: Re: Conference Focus Indicating CCMP Support draft > >>>> > >>>> We had not yet started. The next step is for the authors to request > >>>> publication (when they believe it is ready), > >>>> and you or Richard can start fresh with an initial AD review. > >>>> > >>>> I skimmed the version of the draft linked to below - I still don't > >>>> expect controversy or much in the way of changes. > >>>> The one thing that sticks out is the complete redefinition of the > >>>> Call-Info header syntax just to add a parameter > >>>> to info-param. It would be much better to find a way to use the > >>>> Incremental Alternative (=3D/) production rule. > >>>> If that's not possible the way Call-Info is currently defined, we > >> should > >>>> redefine it _once_ to make it possible. > >>>> IIRC there are other things in flight that are touching Call-Info - > >> you > >>>> should make sure they're aligned. > >>>> > >>>> RjS > >>>> > >>>> On 4/10/13 3:01 AM, Gonzalo Camarillo wrote: > >>>>> Hi Robert, > >>>>> > >>>>> the authors of the draft below just sent us the email below. They > >>>>> mention you had agreed to AD sponsor it. What is the next step > here > >> so > >>>>> that Richard or I can take this over? > >>>>> > >>>>> Thanks, > >>>>> > >>>>> Gonzalo > >>>>> > >>>>> On 09/04/2013 9:47 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > >>>>>> Gonzalo, Richard, > >>>>>> > >>>>>> > >>>>>> > >>>>>> Mary and I have been working on the following "Conference Focus > >>>>>> Indicating CCMP Support" draft, which Robert agreed to AD sponsor > a > >>>>>> while back. > >>>>>> > >>>>>> https://datatracker.ietf.org/doc/draft-yusef-dispatch-ccmp- > >>>> indication/?include_text=3D1 > >>>>>> > >>>>>> > >>>>>> The draft is simple and straightforward which was discussed on > the > >>>>>> DISPATCH mailing list. > >>>>>> > >>>>>> Robert Sparks, Alan Johnston, Cullen Jennings, and Adam Roach all > >>>>>> reviewed it and provided feedback which was incorporated into the > >>>> latest > >>>>>> version of the draft. > >>>>>> > >>>>>> Alan Johnston is the document shepherd and he worked on the > writeup > >>>> for > >>>>>> this draft. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Now that Robert is no longer an AD, can one of you please sponsor > >>>> this > >>>>>> draft instead? > >>>>>> > >>>>>> > >>>>>> > >>>>>> Thanks, > >>>>>> > >>>>>> Rifaat > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > > > > _______________________________________________ > > RAI mailing list > > RAI@ietf.org > > https://www.ietf.org/mailman/listinfo/rai > > >=20 > _______________________________________________ > RAI mailing list > RAI@ietf.org > https://www.ietf.org/mailman/listinfo/rai From pkyzivat@alum.mit.edu Thu Apr 11 13:44:46 2013 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4DF321F8F76 for ; Thu, 11 Apr 2013 13:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.251 X-Spam-Level: X-Spam-Status: No, score=-0.251 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kIxmuvCz12Y for ; Thu, 11 Apr 2013 13:44:45 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 44B9C21F8F6F for ; Thu, 11 Apr 2013 13:44:45 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta02.westchester.pa.mail.comcast.net with comcast id Nadi1l0081HzFnQ51kkkUP; Thu, 11 Apr 2013 20:44:44 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id Nkkk1l00Z3ZTu2S3akkkdQ; Thu, 11 Apr 2013 20:44:44 +0000 Message-ID: <516720BB.2030304@alum.mit.edu> Date: Thu, 11 Apr 2013 16:44:43 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Shekh-Yusef, Rifaat (Rifaat)" References: <51651C5C.1020104@ericsson.com> <5165787D.8010501@nostrum.com> <5165A15E.20401@nostrum.com> <5166DC2D.8090905@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1365713084; bh=qy8BQhYeEmxuZmxH9vmJs0OFwuQMV64PNTjEaEgZGjY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=PzdTuH7CmjCH/N9wxQFyNyGEQWENEJzkAydqZKU0nt8irHjlQmcIMVb1KjpC90t2t KXjv626ni9gq12o8MQn8cJjO+kcRkQ94Fmg377p1o4jjtSPBcAbj46JwhW4QrpWaK6 kLDSQLjgbuzXcbeLKYtgdwQU1iNes9lROZSuwGO+H7BJfq4cR8zDznf4Yw7o5HHG9i xiX5t93JaLmRYnr23NSKOzpB1DgaReFU6JnEO/3rjUfKHYkaiM6iNR3Y6bq6+FhKcR xDvZhJ3Y+L2DEAzn7iFnXFMXfoi7HayyDEhxsxXI/aYy/Jzg5yRxCQaCSvKwyBpLAH vdTI+fpnnZgag== Cc: "rai@ietf.org" Subject: Re: [RAI] Conference Focus Indicating CCMP Support draft X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 20:44:46 -0000 On 4/11/13 2:38 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > I think that if we are to revise the ABNF, then we need a separate document for that. If there is enough interest, I would be willing to work on that document. > For this document, I prefer to go with option 3. > > Regarding the IANA registry, we had a similar discussion on the DISPATCH mailing list in the context of the XMPP work, and the conclusion was that we did not need a registry: > http://www.ietf.org/mail-archive/web/dispatch/current/msg04628.html You are right - we have been down this path before, several times, including recently. The sip parameters registry, introduced with RFC3968, already lists parameters and the header fields they may be used with, and cross references the documents that define the values of the parameter. That registry already references two additional specs that define new values for 'purpose', and we know there is another one in the pipeline that will define another. As a result, the ABNF in 3261 is no longer an exhaustive source for the values of the purpose parameter. RFC3968 says that new parameter values must be defined in an RFC. It does not say that they must extend the syntax of 3261 to to so. The things that have been added to the table since 3968 have not provided ABNF definitions for the new values they define. Using ABNF =/ to define new values as an extension to the 3261 ABNF is certainly *possible*, but it might just be confusing. Doing that would at least imply that the RFC doing so should be marked as revising 3261. But one purpose of creating the registry is to avoid having to update 3261 each time a new parameter value is defined. So, I take back all of (1)-(3). Instead, I think you must do as draft-ietf-bliss-call-completion-19 does: Define the specific value, and its meaning, in text in your draft, and add an IANA considerations section that adds a reference to your draft to the "Header Field Parameters and Parameter Values" sub-table of the IANA "Session Initiation Protocol (SIP) Parameters" registry. > Are you saying that we need a registry *if* we revise the ABNF? No. Thanks, Paul > Regards, > Rifaat > > > >> -----Original Message----- >> From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: Thursday, April 11, 2013 11:52 AM >> To: rai@ietf.org >> Subject: Re: [RAI] Conference Focus Indicating CCMP Support draft >> >> On 4/11/13 1:50 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: >>> Adding the RAI distribution to this discussion per Robert's request. >> >> IMO RAI isn't the best place for this discussion. >> I fear that some people who care won't see this. >> The right place to have the discussion of restructuring the ABNF for the >> info-param is sipcore. But I don't want to cross post, so lets reach >> some conclusion to this thread, and then if it becomes a sipcore concern >> we can post the conclusion there for confirmation. >> >> I see three ways to handle this, two of which have already been >> mentioned: >> >> 1) revise the ABNF so in the future it can be extended without >> further redefinition: >> >> info-param = info-purpose-param / generic-param >> info-purpose-param = "purpose" EQUAL info-purpose-choices >> info-purpose-choices = "icon" / "info" / "card" / token >> info-purpose-choices =/ "ccmp" >> >> 2) revise the ANBF to just have the choices be just "token" >> and add an IANA registry for values. >> >> 3) just work around the existing ABNF in a cleaner way: >> >> info-param =/ "purpose" EQUAL "ccmp" >> >> Which to do depends on how much work we want to go through now and how >> many new values we anticipate in the future. In this case, where the >> syntax isn't too complex and the number of new values is likely to be >> small I think (3) may be the simplest. >> >> The choice between (1) and (2) depends on whether we want to spend >> cycles deciding what the criteria ought to be for adding new values in >> the future. >> >> Thanks, >> Paul >> >>> Thanks Robert, >>> >>>> That _redefines_ Call-Info even if it leaves the syntax the same. >>>> The definition for the header would be in _this_ document, not in >> 3261 >>>> if you leave the ABNF like this. >>> >>> I now understand your concern. >>> I would like to go with the option of removing the ABNF and just >> define the new value. >>> >>> >>> Do others see value with the second option: >>> >>>> But if you do mess with the ABNF, make this change: >>>> >>>> info-param = ( "purpose" EQUAL ( info-purpose-choices) ) / generic- >> param >>>> info-purpose-choices = "icon" / "info" / "card" / "ccmp " / token >>>> >>>> so that the _next_ draft that comes along that wants to add a >> purpose >>>> choice can simply say >>>> info-purpose-choices =/ "foo" >>>> >>>> If you go down this path, you should also check with the community >>>> whether we should >>>> create an IANA registry for these choices. I don't think it's worth >> it, >>>> but there have been >>>> similar conversations where the rough consensus was to create one. >>> >>> >>> Thanks, >>> Rifaat >>> >>> >>>> -----Original Message----- >>>> From: Robert Sparks [mailto:rjsparks@nostrum.com] >>>> Sent: Wednesday, April 10, 2013 1:29 PM >>>> To: Shekh-Yusef, Rifaat (Rifaat) >>>> Cc: Gonzalo Camarillo; rlb@ipv.sx; Mary Barnes; Alan Johnston >>>> Subject: Re: Conference Focus Indicating CCMP Support draft >>>> >>>> On 4/10/13 12:08 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: >>>>> Hi Robert, >>>>> >>>>> Thanks for your feedback. >>>>> >>>>>> The one thing that sticks out is the complete redefinition of the >>>>>> Call-Info header syntax just to add a parameter >>>>>> to info-param. >>>>> The draft is not changing the syntax of the Call-Info header; the >>>> absoluteURI will be an XCON-URI and we are defining a new "ccmp" >> token >>>> to indicate that the URI supports ccmp. >>>>> Where do you see that we are redefining the syntax? >>>> The draft contains this: >>>> >>>> The following is the updated ABNF for the Call-Info header: >>>> >>>> Call-Info = "Call-Info" HCOLON info *(COMMA info) >>>> info = LAQUOT absoluteURI RAQUOT *( SEMI info-param) >>>> info-param = ( "purpose" EQUAL ( "icon" / "info" >>>> / "card" / "ccmp" / token ) ) / generic-param >>>> >>>> That _redefines_ Call-Info even if it leaves the syntax the same. >>>> The definition for the header would be in _this_ document, not in >> 3261 >>>> if you leave the ABNF like this. >>>> >>>> At the very least, don't restate Call-Info and info. Redefine only >>>> info-param. >>>> >>>> You could just define the value and not mess with the ABNF. That is >> the >>>> avenue I would recommend. >>>> >>>> But if you do mess with the ABNF, make this change: >>>> >>>> info-param = ( "purpose" EQUAL ( info-purpose-choices) ) / generic- >> param >>>> info-purpose-choices = "icon" / "info" / "card" / "ccmp " / token >>>> >>>> so that the _next_ draft that comes along that wants to add a >> purpose >>>> choice can simply say >>>> info-purpose-choices =/ "foo" >>>> >>>> If you go down this path, you should also check with the community >>>> whether we should >>>> create an IANA registry for these choices. I don't think it's worth >> it, >>>> but there have been >>>> similar conversations where the rough consensus was to create one. >>>> >>>> Also, it's unfortunate that this conversation isn't on a list. If we >>>> continue, please add a list to the distribution. >>>> I suggest rai@ietf.org. >>>> >>>> RjS >>>> >>>> >>>> >>>>> >>>>> Regards, >>>>> Rifaat >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Robert Sparks [mailto:rjsparks@nostrum.com] >>>>>> Sent: Wednesday, April 10, 2013 10:35 AM >>>>>> To: Gonzalo Camarillo >>>>>> Cc: Shekh-Yusef, Rifaat (Rifaat); rlb@ipv.sx; Mary Barnes; Alan >>>> Johnston >>>>>> Subject: Re: Conference Focus Indicating CCMP Support draft >>>>>> >>>>>> We had not yet started. The next step is for the authors to request >>>>>> publication (when they believe it is ready), >>>>>> and you or Richard can start fresh with an initial AD review. >>>>>> >>>>>> I skimmed the version of the draft linked to below - I still don't >>>>>> expect controversy or much in the way of changes. >>>>>> The one thing that sticks out is the complete redefinition of the >>>>>> Call-Info header syntax just to add a parameter >>>>>> to info-param. It would be much better to find a way to use the >>>>>> Incremental Alternative (=/) production rule. >>>>>> If that's not possible the way Call-Info is currently defined, we >>>> should >>>>>> redefine it _once_ to make it possible. >>>>>> IIRC there are other things in flight that are touching Call-Info - >>>> you >>>>>> should make sure they're aligned. >>>>>> >>>>>> RjS >>>>>> >>>>>> On 4/10/13 3:01 AM, Gonzalo Camarillo wrote: >>>>>>> Hi Robert, >>>>>>> >>>>>>> the authors of the draft below just sent us the email below. They >>>>>>> mention you had agreed to AD sponsor it. What is the next step >> here >>>> so >>>>>>> that Richard or I can take this over? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Gonzalo >>>>>>> >>>>>>> On 09/04/2013 9:47 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: >>>>>>>> Gonzalo, Richard, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Mary and I have been working on the following "Conference Focus >>>>>>>> Indicating CCMP Support" draft, which Robert agreed to AD sponsor >> a >>>>>>>> while back. >>>>>>>> >>>>>>>> https://datatracker.ietf.org/doc/draft-yusef-dispatch-ccmp- >>>>>> indication/?include_text=1 >>>>>>>> >>>>>>>> >>>>>>>> The draft is simple and straightforward which was discussed on >> the >>>>>>>> DISPATCH mailing list. >>>>>>>> >>>>>>>> Robert Sparks, Alan Johnston, Cullen Jennings, and Adam Roach all >>>>>>>> reviewed it and provided feedback which was incorporated into the >>>>>> latest >>>>>>>> version of the draft. >>>>>>>> >>>>>>>> Alan Johnston is the document shepherd and he worked on the >> writeup >>>>>> for >>>>>>>> this draft. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Now that Robert is no longer an AD, can one of you please sponsor >>>>>> this >>>>>>>> draft instead? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Rifaat >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>> >>> _______________________________________________ >>> RAI mailing list >>> RAI@ietf.org >>> https://www.ietf.org/mailman/listinfo/rai >>> >> >> _______________________________________________ >> RAI mailing list >> RAI@ietf.org >> https://www.ietf.org/mailman/listinfo/rai > From worley@shell01.TheWorld.com Thu Apr 11 16:08:07 2013 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE5421F899E for ; Thu, 11 Apr 2013 16:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XeEdEQVURZH6 for ; Thu, 11 Apr 2013 16:08:04 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id C436D21F89D3 for ; Thu, 11 Apr 2013 16:08:02 -0700 (PDT) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r3BN7XfU007340; Thu, 11 Apr 2013 19:07:35 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r3BN7WDU2404098; Thu, 11 Apr 2013 19:07:33 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r3BN7Wj52395441; Thu, 11 Apr 2013 19:07:32 -0400 (EDT) Date: Thu, 11 Apr 2013 19:07:32 -0400 (EDT) Message-Id: <201304112307.r3BN7Wj52395441@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: "Shekh-Yusef, Rifaat (Rifaat)" In-reply-to: (rifatyu@avaya.com) References: <51651C5C.1020104@ericsson.com> <5165787D.8010501@nostrum.com> <5165A15E.20401@nostrum.com> Cc: rai@ietf.org Subject: Re: [RAI] Conference Focus Indicating CCMP Support draft X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 23:08:07 -0000 > From: "Shekh-Yusef, Rifaat (Rifaat)" > > Do others see value with the second option: > > > But if you do mess with the ABNF, make this change: > > > > info-param = ( "purpose" EQUAL ( info-purpose-choices) ) / generic-param > > info-purpose-choices = "icon" / "info" / "card" / "ccmp " / token > > > > so that the _next_ draft that comes along that wants to add a purpose > > choice can simply say > > info-purpose-choices =/ "foo" In abstract, I think I prefer the "second option". But it would take more bureaucratic work to implement it. However, draft-yusef-dispatch-ccmp-indication-02, proposes creating a registry for the predefined values of the purpose parameter of Call-Info. I'm not sure it's needed, as there are currently only 4 RFCs/drafts that are relevant. But if a new registry is defined, the document that defines it must initialize the registry with all of the currently defined values, and the current section 4.2 only lists the value "ccmp". And it would need to update the row for "Call-Info" in "Header Field Parameters and Parameter Values" to reference the new registry, rather than the collection of RFCs. Dale From rifatyu@avaya.com Fri Apr 12 06:01:37 2013 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6C2521F8BE4 for ; Fri, 12 Apr 2013 06:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bI55Hnnq4ikj for ; Fri, 12 Apr 2013 06:01:37 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 2E02A21F8BAE for ; Fri, 12 Apr 2013 06:01:37 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAAH/ZlHGmAcF/2dsb2JhbABQgmUhwX6BBxZ0gh8BAQEBAxIoLhEMBAIBCA0EBAEBCxQJBzIUCQgCBA4FCBqHcgGgR50MF41UgREmCwcGglphA50pimiDC4FzNQ X-IronPort-AV: E=Sophos;i="4.87,456,1363147200"; d="scan'208";a="6710103" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 12 Apr 2013 09:01:28 -0400 Received: from unknown (HELO AZ-US1EXHC02.global.avaya.com) ([135.11.85.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 12 Apr 2013 08:58:33 -0400 Received: from AZ-US1EXMB01.global.avaya.com ([fe80::54fa:ed52:888e:7ca8]) by AZ-US1EXHC02.global.avaya.com ([::1]) with mapi id 14.02.0328.009; Fri, 12 Apr 2013 09:01:28 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: "Dale R. Worley" Thread-Topic: [RAI] Conference Focus Indicating CCMP Support draft Thread-Index: Ac41UqOwQn61izg0SJyesqCVCdwaeQAkIBsAAA26cIAABtgOsP//+foAgABAFUCAAW3/Ev//GIzA Date: Fri, 12 Apr 2013 13:01:27 +0000 Message-ID: References: <51651C5C.1020104@ericsson.com> <5165787D.8010501@nostrum.com> <5165A15E.20401@nostrum.com> <201304112307.r3BN7Wj52395441@shell01.TheWorld.com> In-Reply-To: <201304112307.r3BN7Wj52395441@shell01.TheWorld.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.48] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rai@ietf.org" Subject: Re: [RAI] Conference Focus Indicating CCMP Support draft X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 13:01:37 -0000 Hi Dale, As Paul suggested in a previous email, I will follow what you did with your= draft-ietf-bliss-call-completion. Regards, Rifaat > -----Original Message----- > From: Dale R. Worley [mailto:worley@ariadne.com] > Sent: Thursday, April 11, 2013 7:08 PM > To: Shekh-Yusef, Rifaat (Rifaat) > Cc: rjsparks@nostrum.com; rai@ietf.org > Subject: Re: [RAI] Conference Focus Indicating CCMP Support draft >=20 > > From: "Shekh-Yusef, Rifaat (Rifaat)" > > > > Do others see value with the second option: > > > > > But if you do mess with the ABNF, make this change: > > > > > > info-param =3D ( "purpose" EQUAL ( info-purpose-choices) ) / generic- > param > > > info-purpose-choices =3D "icon" / "info" / "card" / "ccmp " / token > > > > > > so that the _next_ draft that comes along that wants to add a > purpose > > > choice can simply say > > > info-purpose-choices =3D/ "foo" >=20 > In abstract, I think I prefer the "second option". But it would take > more bureaucratic work to implement it. >=20 > However, draft-yusef-dispatch-ccmp-indication-02, proposes creating a > registry for the predefined values of the purpose parameter of > Call-Info. I'm not sure it's needed, as there are currently only 4 > RFCs/drafts that are relevant. But if a new registry is defined, the > document that defines it must initialize the registry with all of the > currently defined values, and the current section 4.2 only lists the > value "ccmp". And it would need to update the row for "Call-Info" in > "Header Field Parameters and Parameter Values" to reference the new > registry, rather than the collection of RFCs. >=20 > Dale From rifatyu@avaya.com Sun Apr 14 06:51:48 2013 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C53E721F90C1 for ; Sun, 14 Apr 2013 06:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBdteEJKUq5F for ; Sun, 14 Apr 2013 06:51:48 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB5D21F90B1 for ; Sun, 14 Apr 2013 06:51:48 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAAH/ZlHGmAcF/2dsb2JhbABQgmUhNsFIgQcWdIIfAQEBAQMBAQEPKC4GCwwEAgEIDQQEAQELFAkHJwsUCQgCBA4FCBqHcgELoDydDBeNVIERJgsHBoJaYQOYI4UGimiDC4FzNQ X-IronPort-AV: E=Sophos;i="4.87,456,1363147200"; d="scan'208";a="6899793" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 14 Apr 2013 09:51:47 -0400 Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 14 Apr 2013 09:48:45 -0400 Received: from AZ-US1EXMB01.global.avaya.com ([fe80::54fa:ed52:888e:7ca8]) by AZ-US1EXHC01.global.avaya.com ([135.11.85.12]) with mapi id 14.02.0328.009; Sun, 14 Apr 2013 09:51:46 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: "rai@ietf.org" Thread-Topic: [RAI] Conference Focus Indicating CCMP Support draft Thread-Index: Ac41UqOwQn61izg0SJyesqCVCdwaeQAkIBsAAA26cIAABtgOsP//+foAgABAFUCAAW3/Ev//GIzA//r+MPA= Date: Sun, 14 Apr 2013 13:51:45 +0000 Message-ID: References: <51651C5C.1020104@ericsson.com> <5165787D.8010501@nostrum.com> <5165A15E.20401@nostrum.com> <201304112307.r3BN7Wj52395441@shell01.TheWorld.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [RAI] Conference Focus Indicating CCMP Support draft X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 13:51:48 -0000 I have submitted a new version that removed the ABNF and changed the IANA s= ection to address both the Call-Info and the URI registration. http://tools.ietf.org/html/draft-yusef-dispatch-ccmp-indication-03 Please, take a look and let me know if you have any comments. Thanks, Rifaat > -----Original Message----- > From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On Behalf Of > Shekh-Yusef, Rifaat (Rifaat) > Sent: Friday, April 12, 2013 9:01 AM > To: Dale R. Worley > Cc: rai@ietf.org > Subject: Re: [RAI] Conference Focus Indicating CCMP Support draft >=20 > Hi Dale, >=20 > As Paul suggested in a previous email, I will follow what you did with > your draft-ietf-bliss-call-completion. >=20 > Regards, > Rifaat >=20 >=20 > > -----Original Message----- > > From: Dale R. Worley [mailto:worley@ariadne.com] > > Sent: Thursday, April 11, 2013 7:08 PM > > To: Shekh-Yusef, Rifaat (Rifaat) > > Cc: rjsparks@nostrum.com; rai@ietf.org > > Subject: Re: [RAI] Conference Focus Indicating CCMP Support draft > > > > > From: "Shekh-Yusef, Rifaat (Rifaat)" > > > > > > Do others see value with the second option: > > > > > > > But if you do mess with the ABNF, make this change: > > > > > > > > info-param =3D ( "purpose" EQUAL ( info-purpose-choices) ) / > generic- > > param > > > > info-purpose-choices =3D "icon" / "info" / "card" / "ccmp " / token > > > > > > > > so that the _next_ draft that comes along that wants to add a > > purpose > > > > choice can simply say > > > > info-purpose-choices =3D/ "foo" > > > > In abstract, I think I prefer the "second option". But it would take > > more bureaucratic work to implement it. > > > > However, draft-yusef-dispatch-ccmp-indication-02, proposes creating a > > registry for the predefined values of the purpose parameter of > > Call-Info. I'm not sure it's needed, as there are currently only 4 > > RFCs/drafts that are relevant. But if a new registry is defined, the > > document that defines it must initialize the registry with all of the > > currently defined values, and the current section 4.2 only lists the > > value "ccmp". And it would need to update the row for "Call-Info" in > > "Header Field Parameters and Parameter Values" to reference the new > > registry, rather than the collection of RFCs. > > > > Dale > _______________________________________________ > RAI mailing list > RAI@ietf.org > https://www.ietf.org/mailman/listinfo/rai From pkyzivat@alum.mit.edu Tue Apr 16 08:56:27 2013 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 177FD21F971A for ; Tue, 16 Apr 2013 08:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+ewrQrI0J75 for ; Tue, 16 Apr 2013 08:56:26 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 1CEA721F9738 for ; Tue, 16 Apr 2013 08:56:25 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta13.westchester.pa.mail.comcast.net with comcast id Qd4c1l0031wpRvQ5DfwRcC; Tue, 16 Apr 2013 15:56:25 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id QfwR1l00r3ZTu2S3efwRxM; Tue, 16 Apr 2013 15:56:25 +0000 Message-ID: <516D74A8.5050708@alum.mit.edu> Date: Tue, 16 Apr 2013 11:56:24 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: rai@ietf.org References: <51651C5C.1020104@ericsson.com> <5165787D.8010501@nostrum.com> <5165A15E.20401@nostrum.com> <201304112307.r3BN7Wj52395441@shell01.TheWorld.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1366127785; bh=p0Au26vt9+AIsKO9oRhOIOW/7Pnr8RLjsSqnWvrxz1Y=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=RLwE7sJFnUxL7c7WCVJxo/uB5hUpXowp1nGPkSeqxR5tDTejvBkrTp3t08QOblSxm 8HtronVrgchESlNbKrx0/izsZpsA7+12SJa0ciDuGTLhhv+8qNGTQFxQGdCuv2jez7 17NNzi9Wbv8cS6OeYok3kfATBmRozO50pflOPKLX3RzSNhs2FYv29lpqq+fziPq5bZ My2mISljkOijTTM6tdBN6zaj/O6wTenBXQP79TcyjOwgp52gsughKrA5WVYmvOfxQ7 kRegprOImqlLgBlhIB6af/t6c0M2eDYvaolvNFqz+1NOpRMSQPA1poPBOhvN9I+8l/ Do4s2BmivXZIQ== Subject: Re: [RAI] Conference Focus Indicating CCMP Support draft X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 15:56:27 -0000 WFM On 4/14/13 9:51 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: > I have submitted a new version that removed the ABNF and changed the IANA section to address both the Call-Info and the URI registration. > http://tools.ietf.org/html/draft-yusef-dispatch-ccmp-indication-03 > > Please, take a look and let me know if you have any comments. > > Thanks, > Rifaat > > > >> -----Original Message----- >> From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On Behalf Of >> Shekh-Yusef, Rifaat (Rifaat) >> Sent: Friday, April 12, 2013 9:01 AM >> To: Dale R. Worley >> Cc: rai@ietf.org >> Subject: Re: [RAI] Conference Focus Indicating CCMP Support draft >> >> Hi Dale, >> >> As Paul suggested in a previous email, I will follow what you did with >> your draft-ietf-bliss-call-completion. >> >> Regards, >> Rifaat >> >> >>> -----Original Message----- >>> From: Dale R. Worley [mailto:worley@ariadne.com] >>> Sent: Thursday, April 11, 2013 7:08 PM >>> To: Shekh-Yusef, Rifaat (Rifaat) >>> Cc: rjsparks@nostrum.com; rai@ietf.org >>> Subject: Re: [RAI] Conference Focus Indicating CCMP Support draft >>> >>>> From: "Shekh-Yusef, Rifaat (Rifaat)" >>>> >>>> Do others see value with the second option: >>>> >>>>> But if you do mess with the ABNF, make this change: >>>>> >>>>> info-param = ( "purpose" EQUAL ( info-purpose-choices) ) / >> generic- >>> param >>>>> info-purpose-choices = "icon" / "info" / "card" / "ccmp " / token >>>>> >>>>> so that the _next_ draft that comes along that wants to add a >>> purpose >>>>> choice can simply say >>>>> info-purpose-choices =/ "foo" >>> >>> In abstract, I think I prefer the "second option". But it would take >>> more bureaucratic work to implement it. >>> >>> However, draft-yusef-dispatch-ccmp-indication-02, proposes creating a >>> registry for the predefined values of the purpose parameter of >>> Call-Info. I'm not sure it's needed, as there are currently only 4 >>> RFCs/drafts that are relevant. But if a new registry is defined, the >>> document that defines it must initialize the registry with all of the >>> currently defined values, and the current section 4.2 only lists the >>> value "ccmp". And it would need to update the row for "Call-Info" in >>> "Header Field Parameters and Parameter Values" to reference the new >>> registry, rather than the collection of RFCs. >>> >>> Dale >> _______________________________________________ >> RAI mailing list >> RAI@ietf.org >> https://www.ietf.org/mailman/listinfo/rai > _______________________________________________ > RAI mailing list > RAI@ietf.org > https://www.ietf.org/mailman/listinfo/rai > From johnsonhammond1@hushmail.com Sat Apr 27 10:27:57 2013 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2045321F982B for ; Sat, 27 Apr 2013 10:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qa0P9eszRDe4 for ; Sat, 27 Apr 2013 10:27:57 -0700 (PDT) Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) by ietfa.amsl.com (Postfix) with ESMTP id E762621F96CD for ; Sat, 27 Apr 2013 10:27:56 -0700 (PDT) Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) by smtp2.hushmail.com (Postfix) with SMTP id 8FA6BE7C5F for ; Sat, 27 Apr 2013 17:26:38 +0000 (UTC) Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp2.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:26:38 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 50F6CE6736; Sat, 27 Apr 2013 17:26:38 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:26:38 -0400 To: rai@ietf.org From: johnsonhammond1@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427172638.50F6CE6736@smtp.hushmail.com> Subject: [RAI] Biggest Fake Conference in Computer Science X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 18:32:27 -0000 Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links.