From rob.glidden@sbcglobal.net Mon Dec 7 19:59:09 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23AF93A681E for ; Mon, 7 Dec 2009 19:59:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[AWL=-0.635, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2GzuMSdlbTx for ; Mon, 7 Dec 2009 19:59:08 -0800 (PST) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 66DDD3A6806 for ; Mon, 7 Dec 2009 19:59:08 -0800 (PST) Received: (qmail 38967 invoked from network); 8 Dec 2009 03:58:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=zN8h8uI7oEu+cnw0RJjS6mD00MOXP9audGViGH/tCwuSvy5P+2V1U175GZMQ1A8Ofrga1JExaVwLwbAhQTGIqDHJmts9p7ny+Yd59WC1t6EHKSUc5dgAP20nJB8J2yWH8XdcgEGXRS+r0cXlWgPMyhLI1iSr0qPqXWf3QPZL888= ; Received: from adsl-69-105-1-31.dsl.pltn13.pacbell.net (rob.glidden@69.105.1.31 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 07 Dec 2009 19:58:54 -0800 PST X-Yahoo-SMTP: xflwSnaswBCuS46GvTyhPI4RUJpgPG5UXouB5Vxqo4t9fsHeH0I- X-YMail-OSG: 16lLK3EVM1m3LL4nRBNFYyAvkbnZr1LdcgZFC0Dh_ctCr6CwLMw9ia_b2D49pX2Ht0G0xOXlrCHIwLbI4yRvyQNUDFDTeIOprF_gQRLUvrlkYM8jipu7YhOk09.PzJrxxJFqDXaRtDn82fYoODXXdZM5QiWQNpInS0y0Aa2w6QCyxv2HHeKhhzzqTspbamnilKxnDWb9a2RiBrUnbocruJ86bo2kcof3C.hgHILi1satDVkRuFBsQVFkKGM2hhPW3FxGruJ_cIidsUyKdwEMLta5GrKnpRa5usMZ9pPBXt.S.iN1qP2Z6YCjbQBe2iZQhH1zISYzzUNxeeGzm.bPxv3VlS3BC0MXcOjP7cwuVDOSxUpc6YWfm1kHBHn.N4LaFiTAUBVwB16CP21SK.4kmHoMCS9gFx_ZTOp8gAUDWdgkxGO3STk7Ot9cYGrl0LxGymOwWnd2sWGVKgc8dLZyq7dHeKGNbzkdH.S2yhwLvC5AkNMmqxjrCYXoJxeE1ELPjPzYliZ0lKx0CMUYHhcHBrDSelz8gZk62SUDlSxyJL45ig-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B1DCEFB.6090608@sbcglobal.net> Date: Mon, 07 Dec 2009 19:58:51 -0800 From: Rob Glidden User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: David Singer References: <4B0288C5.6000300@sbcglobal.net> <6e9223710911170339r2e31db0t33e22b57943ee15@mail.gmail.com> <6F5D33FA-0575-4024-8C30-7AADBD9948DE@apple.com> <4B03CFE6.4000607@sbcglobal.net> In-Reply-To: <4B03CFE6.4000607@sbcglobal.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] I wonder what is going on at MPEG, Re: DRAFT Minutes Posted X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 03:59:09 -0000 List quiet, but if interested I've summarized a pro royalty-free codec standards viewpoint at http://www.mpegrf.com/ Rob Rob Glidden wrote: > David: > > Yes there is a mention of this at > > http://multimediacommunication.blogspot.com/2009/10/mpeg-news-report-from-90th-meeting-in.html > > > Here is a simple and fair test of whether there is "sincere and > sustained" support for royalty free goal/profile/baseline/standard etc > -- is it included in new work by ITU, ISO/MPEG (and ITEF). Bonus > points for addressing lessons learned and evolving process/approach. > > Rob > > David Singer wrote: >> On Nov 17, 2009, at 3:28 , Rob Glidden wrote: >> >> >>> So I'd suggest a different interpretation, one that does not assume >>> there was a sincere or sustained political consensus. Accepting >>> this, a more realistic forward look is possible. >>> >> >> You are entitled to your opinions, but the effort was sincere and >> sustained on the part of large numbers of participants. This is not >> the place to go into where things went wrong, but it is worth noting >> that MPEG is looking again into the question of royalty-free >> standards, and what was learned from that process. >> >> >> David Singer >> Multimedia and Software Standards, Apple Inc. >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> >> > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > From singer@apple.com Tue Dec 8 08:59:47 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 871B728C209 for ; Tue, 8 Dec 2009 08:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.599 X-Spam-Level: X-Spam-Status: No, score=-108.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TN2T+W00TQVX for ; Tue, 8 Dec 2009 08:59:46 -0800 (PST) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 9417128C1C6 for ; Tue, 8 Dec 2009 08:59:46 -0800 (PST) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out3.apple.com (Postfix) with ESMTP id 3D5A27C374EF; Tue, 8 Dec 2009 08:59:36 -0800 (PST) X-AuditID: 11807130-b7b0aae00000102c-f0-4b1e85f82b60 Received: from [17.151.91.123] (Unknown_Domain [17.151.91.123]) by relay11.apple.com (Apple SCV relay) with SMTP id 22.F3.04140.8F58E1B4; Tue, 8 Dec 2009 08:59:36 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: David Singer In-Reply-To: <4B1DCEFB.6090608@sbcglobal.net> Date: Tue, 8 Dec 2009 08:59:36 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <38A130E8-54C0-4512-9AA9-13CF4FD77D63@apple.com> References: <4B0288C5.6000300@sbcglobal.net> <6e9223710911170339r2e31db0t33e22b57943ee15@mail.gmail.com> <6F5D33FA-0575-4024-8C30-7AADBD9948DE@apple.com> <4B03CFE6.4000607@sbcglobal.net> <4B1DCEFB.6090608@sbcglobal.net> To: Rob Glidden X-Mailer: Apple Mail (2.1077) X-Brightmail-Tracker: AAAAAQAAAZE= Cc: codec@ietf.org Subject: Re: [codec] I wonder what is going on at MPEG, Re: DRAFT Minutes Posted X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 16:59:47 -0000 You seem to be implying an official connection with the motion pictures = expert group (MPEG) by using those letters in your site name, and unless = you have that connection, I think it is a mistake. =20 This despite the face that there are some at MPEG who support developing = RF standards, or even trying to establish RF for parts of existing = standards. On Dec 7, 2009, at 19:58 , Rob Glidden wrote: > List quiet, but if interested I've summarized a pro royalty-free codec = standards viewpoint at >=20 > http://www.mpegrf.com/ >=20 > Rob >=20 > Rob Glidden wrote: >> David: >>=20 >> Yes there is a mention of this at >>=20 >> = http://multimediacommunication.blogspot.com/2009/10/mpeg-news-report-from-= 90th-meeting-in.html=20 >>=20 >> Here is a simple and fair test of whether there is "sincere and = sustained" support for royalty free goal/profile/baseline/standard etc = -- is it included in new work by ITU, ISO/MPEG (and ITEF). Bonus points = for addressing lessons learned and evolving process/approach. >>=20 >> Rob >>=20 >> David Singer wrote: >>> On Nov 17, 2009, at 3:28 , Rob Glidden wrote: >>>=20 >>>=20 >>>> So I'd suggest a different interpretation, one that does not assume = there was a sincere or sustained political consensus. Accepting this, a = more realistic forward look is possible. >>>> =20 >>>=20 >>> You are entitled to your opinions, but the effort was sincere and = sustained on the part of large numbers of participants. This is not the = place to go into where things went wrong, but it is worth noting that = MPEG is looking again into the question of royalty-free standards, and = what was learned from that process. >>>=20 >>>=20 >>> David Singer >>> Multimedia and Software Standards, Apple Inc. >>>=20 >>> _______________________________________________ >>> codec mailing list >>> codec@ietf.org >>> https://www.ietf.org/mailman/listinfo/codec >>>=20 >>> =20 >>=20 >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >>=20 >=20 David Singer Multimedia and Software Standards, Apple Inc. From rob.glidden@sbcglobal.net Tue Dec 8 11:29:44 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A48D83A68C2 for ; Tue, 8 Dec 2009 11:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.743 X-Spam-Level: X-Spam-Status: No, score=-1.743 tagged_above=-999 required=5 tests=[AWL=1.063, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_HTML_ONLY=1.457, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcjKO6SRwsb1 for ; Tue, 8 Dec 2009 11:29:43 -0800 (PST) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id 9A70A3A6848 for ; Tue, 8 Dec 2009 11:29:43 -0800 (PST) Received: (qmail 1554 invoked from network); 8 Dec 2009 19:29:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=C/SwFWd3XYU5x49pEI1VK1RcskVGTTy3WAO+EdHkZ5ih1n9cKLNdeqvrCEljHmzyr8jKuENgIEdzq+tKOsCPy3Ybh6LMVNaPLAA9QrqV1/NAbcafpzBw0vAQT4veLD70zEsRkRJQ3jIWHJXGQZ/+cbwR7CcdJ8SQLvvPeXcorVY= ; Received: from adsl-69-105-1-31.dsl.pltn13.pacbell.net (rob.glidden@69.105.1.31 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 08 Dec 2009 11:29:30 -0800 PST X-Yahoo-SMTP: xflwSnaswBCuS46GvTyhPI4RUJpgPG5UXouB5Vxqo4t9fsHeH0I- X-YMail-OSG: WegPT20VM1luIHmW44KDMwLlOj9sYA8TUEmIvX5fxp3bNo7panJlXsohI8NRUhFbetJC7cttKwHuMrtz8h9WgPvkRy3gz7tkQqOA1SqaD68mTn2MWvhoZmGa54BXFfYBVGJvyBrxrdUSaZkf5GdJamW1kUl_P_qBwXhKgjs6_efX8lbPlXMMyTAX7fblSsqCO57D49uPW7lQqJI0b9DHXIozcNP2IPOPuZ.buzf76E.DoC.e6ByiuyL7drQ2t0FxQxtiAzzGIdIVkLBkEtxqXXKWFNocGlf.CCSmRxEs_trTJS1uJR29H0spcmTTuk1jQhUmwPvmLDLytQZ.Gq91_Ld_AeW1Blx0UOIOMCeWPBovjvYHNaDcxJO5QwbUM7NvGnhHuPUcNSz65FMgH4a4ilUYZ.b1dcPgPEgKn_kelDTZfuzsZSzHkf0KR2n6jXW8osufXLWsDxlRRdVbnCs__EdCaDHJbwUn9zpTPcdPm.C0HsaniASqnLKZFmLR.bMY91h11oR6lTfKJHo8HaZC_TNV4PBZzW1XzK4Axkyblw2RXQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B1EA916.4010708@sbcglobal.net> Date: Tue, 08 Dec 2009 11:29:26 -0800 From: Rob Glidden User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: David Singer References: <4B0288C5.6000300@sbcglobal.net> <6e9223710911170339r2e31db0t33e22b57943ee15@mail.gmail.com> <6F5D33FA-0575-4024-8C30-7AADBD9948DE@apple.com> <4B03CFE6.4000607@sbcglobal.net> <4B1DCEFB.6090608@sbcglobal.net> <38A130E8-54C0-4512-9AA9-13CF4FD77D63@apple.com> In-Reply-To: <38A130E8-54C0-4512-9AA9-13CF4FD77D63@apple.com> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] I wonder what is going on at MPEG, Re: DRAFT Minutes Posted X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 19:29:44 -0000 Hi Dave:

I have no doubt there are participants in MPEG, ITU (and IETF) who support developing royalty free standards and encourage their continuing efforts.

But organizational action and result is needed.  In tangible form, this means proposals, work items, AHGs, calls, terms of reference, contributions, agenda items, processes, undertakings, and more.  The work products of constructive standards activity.

A quick search shows literally thousands of websites with letters MPEG, and several registered trademarks (some to major companies). 

I would assert "royalty free" does merit official recognition and action -- and the site describes official channels.

Rob

David Singer wrote: 
You seem to be implying an official connection with the motion pictures expert group (MPEG) by using those letters in your site name, and unless you have that connection, I think it is a mistake.  

This despite the face that there are some at MPEG who support developing RF standards, or even trying to establish RF for parts of existing standards.


On Dec 7, 2009, at 19:58 , Rob Glidden wrote:

  
List quiet, but if interested I've summarized a pro royalty-free codec standards viewpoint at

http://www.mpegrf.com/

Rob

Rob Glidden wrote:
    
David:

Yes there is a mention of this at

http://multimediacommunication.blogspot.com/2009/10/mpeg-news-report-from-90th-meeting-in.html 

Here is a simple and fair test of whether there is "sincere and sustained" support for royalty free goal/profile/baseline/standard etc -- is it included in new work by ITU, ISO/MPEG (and ITEF).  Bonus points for addressing lessons learned and evolving process/approach.

Rob

David Singer wrote:
      
On Nov 17, 2009, at 3:28 , Rob Glidden wrote:


        
So I'd suggest a different interpretation, one that does not assume there was a sincere or sustained political consensus. Accepting this, a more realistic forward look is possible.
   
          
You are entitled to your opinions, but the effort was sincere and sustained on the part of large numbers of participants.  This is not the place to go into where things went wrong, but it is worth noting that MPEG is looking again into the question of royalty-free standards, and what was learned from that process.


David Singer
Multimedia and Software Standards, Apple Inc.

_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org/mailman/listinfo/codec

 
        
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org/mailman/listinfo/codec

      

David Singer
Multimedia and Software Standards, Apple Inc.

From stpeter@stpeter.im Wed Dec 9 15:25:41 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A3333A68D8 for ; Wed, 9 Dec 2009 15:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.812 X-Spam-Level: X-Spam-Status: No, score=-1.812 tagged_above=-999 required=5 tests=[AWL=-0.702, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbHrCtz-x87l for ; Wed, 9 Dec 2009 15:25:40 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 7A9D83A67BD for ; Wed, 9 Dec 2009 15:25:40 -0800 (PST) Received: from dhcp-64-101-72-234.cisco.com (dhcp-64-101-72-234.cisco.com [64.101.72.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 28F8840332 for ; Wed, 9 Dec 2009 16:25:29 -0700 (MST) Message-ID: <4B2031E7.7050205@stpeter.im> Date: Wed, 09 Dec 2009 16:25:27 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "codec@ietf.org" X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090704090806030405090306" Subject: [codec] updated charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 23:25:41 -0000 This is a cryptographically signed message in MIME format. --------------ms090704090806030405090306 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I've tried to update the charter in accordance with my sense of the room in Hiroshima, specifically with regard to the goal of producing a single codec: http://trac.tools.ietf.org/bof/trac/attachment/wiki/BifIETF76/codec-charter.txt Feedback is welcome as always. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms090704090806030405090306 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTIwOTIzMjUyN1owIwYJKoZIhvcNAQkEMRYEFFWV98F0JiGWvdUwByNL x8tT+YwOMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAEKosljBjgVAlvSAPvtahk5Yc9Gjezm3IOgLFbg2l 2nqbwSHRk3OU4oC3kBq1hlX03TKTNkTWGnKB1/bBogleZ076d/MaOWgUllVJLVSpfu50mQbk IWC4yUTMUPyTjdti1Y8YVBEAWxXurp7HLt5zraJ9/V0jkc0YKj4Qf0HYIbqZ8/i1fBGAcnKH trb6+Y4zglHz2PQu0MWNvbS9cn2SJQwq1xsIGI5ry42G6Jn1jK7Yk/O6S2BW1qRL07FpLwbm oQsWlYjYmJ5hyQwlQBGbaa9RQz7y+nropskHoatODm2awkq8a3dgPCOz5u3kYKkVjGiJtP3E uH2hSvOhyFQ5pQAAAAAAAA== --------------ms090704090806030405090306-- From kpfleming@digium.com Thu Dec 10 15:24:11 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E39D3A67C0 for ; Thu, 10 Dec 2009 15:24:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.653 X-Spam-Level: X-Spam-Status: No, score=-104.653 tagged_above=-999 required=5 tests=[AWL=0.654, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duFZaQ1t8dgJ for ; Thu, 10 Dec 2009 15:24:10 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id 2AFAD3A67B0 for ; Thu, 10 Dec 2009 15:24:10 -0800 (PST) Received: from jupiler.digium.internal ([10.19.29.150] helo=jupiler.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1NIsMY-0007qf-3s for codec@ietf.org; Thu, 10 Dec 2009 17:23:58 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by jupiler.digium.com (Postfix) with ESMTP id 0E06E29E0002 for ; Thu, 10 Dec 2009 17:23:58 -0600 (CST) Received: from jupiler.digium.com ([127.0.0.1]) by localhost (jupiler.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tExzLzvkPj3 for ; Thu, 10 Dec 2009 17:23:57 -0600 (CST) Received: from [10.24.250.46] (unknown [10.24.250.46]) (Authenticated sender: kpfleming) by jupiler.digium.com (Postfix) with ESMTP id 4BE3229E0001 for ; Thu, 10 Dec 2009 17:23:57 -0600 (CST) Message-ID: <4B21830C.3040404@digium.com> Date: Thu, 10 Dec 2009 17:23:56 -0600 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 CC: "codec@ietf.org" References: <4B2031E7.7050205@stpeter.im> In-Reply-To: <4B2031E7.7050205@stpeter.im> X-Enigmail-Version: 0.95.7 OpenPGP: id=05FB8DB2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [codec] updated charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 23:24:11 -0000 Peter Saint-Andre wrote: > I've tried to update the charter in accordance with my sense of the room > in Hiroshima, specifically with regard to the goal of producing a single > codec: > > http://trac.tools.ietf.org/bof/trac/attachment/wiki/BifIETF76/codec-charter.txt > > Feedback is welcome as always. This looks good to me, and I do think you've captured the essence of the discussions in Hiroshima. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kpfleming@digium.com Check us out at www.digium.com & www.asterisk.org From stpeter@stpeter.im Thu Dec 10 15:45:25 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDED03A680F for ; Thu, 10 Dec 2009 15:45:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKqlYCZ1lHc4 for ; Thu, 10 Dec 2009 15:45:24 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id C9A7C3A67C1 for ; Thu, 10 Dec 2009 15:45:24 -0800 (PST) Received: from dhcp-64-101-72-234.cisco.com (dhcp-64-101-72-234.cisco.com [64.101.72.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B0AAE4033C; Thu, 10 Dec 2009 16:45:12 -0700 (MST) Message-ID: <4B218806.1030307@stpeter.im> Date: Thu, 10 Dec 2009 16:45:10 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Kevin P. Fleming" References: <4B2031E7.7050205@stpeter.im> <4B21830C.3040404@digium.com> In-Reply-To: <4B21830C.3040404@digium.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020008040307030800080803" Cc: "codec@ietf.org" Subject: Re: [codec] updated charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 23:45:25 -0000 This is a cryptographically signed message in MIME format. --------------ms020008040307030800080803 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12/10/09 4:23 PM, Kevin P. Fleming wrote: > Peter Saint-Andre wrote: >> I've tried to update the charter in accordance with my sense of the room >> in Hiroshima, specifically with regard to the goal of producing a single >> codec: >> >> http://trac.tools.ietf.org/bof/trac/attachment/wiki/BifIETF76/codec-charter.txt >> >> Feedback is welcome as always. > > This looks good to me, and I do think you've captured the essence of the > discussions in Hiroshima. Super, thanks. I see that formation of the Codec WG is on the agenda for the next IESG telechat, so perhaps there will be an IETF Last Call about this in the near future. :) https://datatracker.ietf.org/iesg/agenda/ Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms020008040307030800080803 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTIxMDIzNDUxMFowIwYJKoZIhvcNAQkEMRYEFGX/pNtnpherkBEUzmaS pHqK8RalMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEATsbis5nYehsjYD6gQ8JmNDGLIZSrWVK3a3v7sA0B 9HgLERvzg2XDmUbUQY6x3egR0yXGTXTo0rYFL1wGbsgwVKvlIE/tFc14PancvmtSeyCsy1Q0 g5sIor/JHjZlVtVtsa7OT9dwaleG6BCJlZUv+6fqDkXsRD0tb7xeQcdkfTsS0km23ho1cjxK v2KFDg7G3QUL5IhfQbjQkULzgkX9gpL9tAo5pF1y08cZFv9WyKKZc3CqOURe9ayt6A9vFjXW EXZDGQ4nOEnd5At7GYnGdNs2hd5t8+Lh3xOmNMKfeBINbJLIjGZ0c1AalZ3alJoNvr5Amtd1 EbdGFarhp4qahAAAAAAAAA== --------------ms020008040307030800080803-- From ron.even.tlv@gmail.com Fri Dec 11 00:12:54 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 910CF3A6A0E for ; Fri, 11 Dec 2009 00:12:54 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJ6giLLtb1LA for ; Fri, 11 Dec 2009 00:12:53 -0800 (PST) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 22C6C3A68D4 for ; Fri, 11 Dec 2009 00:12:52 -0800 (PST) Received: by fxm10 with SMTP id 10so754988fxm.14 for ; Fri, 11 Dec 2009 00:12:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=Q+rBHa0A/YAvNsUYkmDAufZjSqYOvkzqWjJ763cBtpQ=; b=rpVxczAiSaKzV1YYRs1HRjsO2rptW5lUcLACFrC6pnOc0avTI1K5ia8WBrhspDA6/3 pB3GWRoMXF8zSmz8tsyGcFcmecqTX5ZIa9Z74aLNFLKtyq386ieXNFy5qfVC/CR3vCk/ 6pgcKVtr85DIcVYmj32T+mUFyb3MUuYbnfSmk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; b=Fdqnud1DvJsQ7EpxXZpW+A3RjlX54Wgx7aCWouOmE3EypzCtRSX9MElfcRKVpwSPUJ EudNRv+tlm+xL/P6IDdBlI/iCtJG0fSf77JIVKSB2lrNtAYm5q1MseJYvwZOllNjoAS0 cW8ZJgH2liIBLygE0WAslnsQysPNAvRd1HtFU= Received: by 10.223.95.72 with SMTP id c8mr1014094fan.73.1260519156109; Fri, 11 Dec 2009 00:12:36 -0800 (PST) Received: from windows8d787f9 (bzq-79-181-106-108.red.bezeqint.net [79.181.106.108]) by mx.google.com with ESMTPS id 28sm2351893fkx.28.2009.12.11.00.12.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 11 Dec 2009 00:12:33 -0800 (PST) From: "Roni Even" To: "'Peter Saint-Andre'" , References: <4B2031E7.7050205@stpeter.im> In-Reply-To: <4B2031E7.7050205@stpeter.im> Date: Fri, 11 Dec 2009 10:09:34 +0200 Message-ID: <4b21fef1.1c185e0a.3649.5124@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-index: Acp5JvFyGbAAsFo2T76moM+Sf/FUVwBEYS7g Content-language: en-us Subject: Re: [codec] updated charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2009 08:12:54 -0000 Hi Peter, In general it looks OK. I have one question. The requirement document is defined to be informational yet I believe it = will provide values for codec quality requirements that will need to be = passed by the proposed codec. In this case should this document be informational or have more = normative value. I assume that an informational document can be a = normative reference. Roni Even > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Peter Saint-Andre > Sent: Thursday, December 10, 2009 1:25 AM > To: codec@ietf.org > Subject: [codec] updated charter >=20 > I've tried to update the charter in accordance with my sense of the > room in Hiroshima, specifically with regard to the goal of producing a > single > codec: >=20 > http://trac.tools.ietf.org/bof/trac/attachment/wiki/BifIETF76/codec- > charter.txt >=20 > Feedback is welcome as always. >=20 > Peter >=20 > -- > Peter Saint-Andre > https://stpeter.im/ >=20 From stpeter@stpeter.im Mon Dec 14 14:49:04 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D4A93A6850 for ; Mon, 14 Dec 2009 14:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VnaK3EgP0mYx for ; Mon, 14 Dec 2009 14:49:03 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 57FBA3A67B5 for ; Mon, 14 Dec 2009 14:49:03 -0800 (PST) Received: from dhcp-64-101-72-234.cisco.com (dhcp-64-101-72-234.cisco.com [64.101.72.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B9F0D40337; Mon, 14 Dec 2009 15:48:49 -0700 (MST) Message-ID: <4B26C0D0.3080009@stpeter.im> Date: Mon, 14 Dec 2009 15:48:48 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Roni Even References: <4B2031E7.7050205@stpeter.im> <4b21fef1.1c185e0a.3649.5124@mx.google.com> In-Reply-To: <4b21fef1.1c185e0a.3649.5124@mx.google.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030904070304020508070201" Cc: codec@ietf.org Subject: Re: [codec] updated charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 22:49:04 -0000 This is a cryptographically signed message in MIME format. --------------ms030904070304020508070201 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12/11/09 1:09 AM, Roni Even wrote: > Hi Peter, In general it looks OK. I have one question. The > requirement document is defined to be informational yet I believe it > will provide values for codec quality requirements that will need to > be passed by the proposed codec. In this case should this document be > informational or have more normative value. I assume that an > informational document can be a normative reference. Yes, a standards-track document can have a normative reference to an informational document -- as I understand it, "normative" means "you must understand the referenced document in order to understand this document", and that relationship often applies to referenced documents that contain requirements. However, it's a bit of a judgement call as to whether the requirements document should be a normative reference or an informative reference (and there is some controversy about whether the distinction between normative and informative references is all that useful anyway...). Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms030904070304020508070201 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTIxNDIyNDg0OFowIwYJKoZIhvcNAQkEMRYEFJwFyTGnly0IOWBje1EO DG2ax8awMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAl1qTlKIBwhtdjGNmeABKBktjTe5ELRWpPHrzS+Tr sk+SDE9bjMutewTEKmiXQeaPvLff8xOJ2VWhhxxtnJa21eZtsf00m8ZM0LaZAWfDc/z1D8VQ xOPIHIdYWWvqh94KOEnI5UdCTAULfAKNRU23cQ97rv2oevbqdMoRVWnSYpQrgDWwCGb6QRKx e70AJZ/hyd9tfLAcCjocCV67RBOdhYQonk6F5WihbMOQI/18C8XRBXaoUcyVRBq5deeR/IJA uEefMKtvEdluChtTopikP/w1597nquhw6gcdqMlNf+kgzlCnuIuBds4H0z0TQ19VocYEeUAG 9kQtSOuoSFKRHwAAAAAAAA== --------------ms030904070304020508070201-- From stephen.botzko@gmail.com Mon Dec 14 16:30:46 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D7F83A63D3 for ; Mon, 14 Dec 2009 16:30:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.869 X-Spam-Level: X-Spam-Status: No, score=-1.869 tagged_above=-999 required=5 tests=[AWL=0.729, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCU80e6EndsD for ; Mon, 14 Dec 2009 16:30:45 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 3BFA13A687C for ; Mon, 14 Dec 2009 16:30:45 -0800 (PST) Received: by fxm7 with SMTP id 7so3716744fxm.29 for ; Mon, 14 Dec 2009 16:30:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=M6SCKCK9+IOkU5tudUF168VOTlDQcU5OC81qoJHgE4Q=; b=piGMC7J5Ze1oNpLoT1pH8OPJxRlOvw3Mpz1+0Yk/iel3eMp9L6saZPZYPS5eMhlCfR SF5Pshdt7cHk7tvCUhDBqh6qe2v9bTi26D7Yh0UKU/07ZV9Di+dLtGBEgmByEXf3MGpz WjDdtxUymCa0pVmtJrI6EHMwCnuzTvsJKShDg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QVQBo1yMaLeLP6kWCf2pAOAEDL/YtCcoDksVJyY0Ejwwz2EzlPVyFE+FSMkZR32BES hmcBQwkuOkLjus+g4B5bViT9XemrGVcwttZ+4G3Flh1KGjbloOvUuikkJG+S38KEMZyr DD16JnfjaviiwXDoG3Ie6cInOYMf2ef6wrLHA= MIME-Version: 1.0 Received: by 10.223.14.22 with SMTP id e22mr6680799faa.42.1260837027709; Mon, 14 Dec 2009 16:30:27 -0800 (PST) In-Reply-To: <4B26C0D0.3080009@stpeter.im> References: <4B2031E7.7050205@stpeter.im> <4b21fef1.1c185e0a.3649.5124@mx.google.com> <4B26C0D0.3080009@stpeter.im> Date: Mon, 14 Dec 2009 19:30:27 -0500 Message-ID: <6e9223710912141630l5e8f3109qe6848b11e0df9050@mail.gmail.com> From: stephen botzko To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=0015173fe52a2804fd047ab97f87 Cc: codec@ietf.org Subject: Re: [codec] updated charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 00:30:46 -0000 --0015173fe52a2804fd047ab97f87 Content-Type: text/plain; charset=ISO-8859-1 Though normative references made by other SDOs (in their standards) have to be made to a standards track document in the IETF. So perhaps that is a consideration here. Regards, Stephen Botzko Polycom On Mon, Dec 14, 2009 at 5:48 PM, Peter Saint-Andre wrote: > On 12/11/09 1:09 AM, Roni Even wrote: > > Hi Peter, In general it looks OK. I have one question. The > > requirement document is defined to be informational yet I believe it > > will provide values for codec quality requirements that will need to > > be passed by the proposed codec. In this case should this document be > > informational or have more normative value. I assume that an > > informational document can be a normative reference. > > Yes, a standards-track document can have a normative reference to an > informational document -- as I understand it, "normative" means "you > must understand the referenced document in order to understand this > document", and that relationship often applies to referenced documents > that contain requirements. However, it's a bit of a judgement call as to > whether the requirements document should be a normative reference or an > informative reference (and there is some controversy about whether the > distinction between normative and informative references is all that > useful anyway...). > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > --0015173fe52a2804fd047ab97f87 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Though normative references made by other SDOs (in their standards)=A0= have to be made to a standards track document in the IETF.=A0 So perhaps th= at is a consideration here.
=A0
Regards,
Stephen Botzko
Polycom

On Mon, Dec 14, 2009 at 5:48 PM, Peter Saint-And= re <stpeter@stpe= ter.im> wrote:
On 12/11/09 1:09 AM, Roni Even wrote:
> Hi Peter, I= n general it looks OK. I have one question. The
> requirement documen= t is defined to be informational yet I believe it
> will provide valu= es for codec quality requirements that will need to
> be passed by the proposed codec. In this case should this document be<= br>> informational or have more normative value. I assume that an
>= ; informational document can be a normative reference.

Yes, a = standards-track document can have a normative reference to an
informational document -- as I understand it, "normative" means &= quot;you
must understand the referenced document in order to understand = this
document", and that relationship often applies to referenced d= ocuments
that contain requirements. However, it's a bit of a judgement call as t= o
whether the requirements document should be a normative reference or a= n
informative reference (and there is some controversy about whether the=
distinction between normative and informative references is all that
use= ful anyway...).

Peter

--
Peter Saint-Andre
https://stpeter.im/



_______________________________________________
codec maili= ng list
codec@ietf.org
https://www.ietf.org= /mailman/listinfo/codec


--0015173fe52a2804fd047ab97f87-- From stewe@stewe.org Mon Dec 14 18:04:38 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3B643A6941 for ; Mon, 14 Dec 2009 18:04:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.038 X-Spam-Level: X-Spam-Status: No, score=-1.038 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jr+WwPbvklBs for ; Mon, 14 Dec 2009 18:04:33 -0800 (PST) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 5AE4B3A6934 for ; Mon, 14 Dec 2009 18:04:33 -0800 (PST) Received: from [192.168.1.107] (unverified [71.202.146.15]) by stewe.org (SurgeMail 3.9e) with ESMTP id 523070-1743317 for multiple; Tue, 15 Dec 2009 03:04:19 +0100 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Mon, 14 Dec 2009 18:04:07 -0800 From: Stephan Wenger To: stephen botzko , Peter Saint-Andre Message-ID: Thread-Topic: [codec] updated charter Thread-Index: Acp9KuIq1+QP8lUFp0KZe2PBi3KkXQ== In-Reply-To: <6e9223710912141630l5e8f3109qe6848b11e0df9050@mail.gmail.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3343658657_7745156" X-Originating-IP: 71.202.146.15 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (71.202.146.15) was found in the spamhaus database. http://www.spamhaus.net Cc: codec@ietf.org Subject: Re: [codec] updated charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 02:04:39 -0000 > 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. --B_3343658657_7745156 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Huh? The only body that has been moderately picky about RFC status that I=B9= m aware of is the ITU. Moderately, because I do recall references to experimental RFCs in ITU Recs, and there are certainly normative references to obsolete/historic RFCs. In many other mainstream SDOs, e.g. ETSI or TIA, normative references to informational documents are perfectly fine. Stephan On 12/14/09 4:30 PM, "stephen botzko" wrote: > Though normative references made by other SDOs (in their standards)=A0have = to be > made to a standards track document in the IETF.=A0 So perhaps that is a > consideration here. > =A0 > Regards, > Stephen Botzko > Polycom >=20 > On Mon, Dec 14, 2009 at 5:48 PM, Peter Saint-Andre w= rote: >> On 12/11/09 1:09 AM, Roni Even wrote: >>> > Hi Peter, In general it looks OK. I have one question. The >>> > requirement document is defined to be informational yet I believe it >>> > will provide values for codec quality requirements that will need to >>> > be passed by the proposed codec. In this case should this document be >>> > informational or have more normative value. I assume that an >>> > informational document can be a normative reference. >>=20 >> Yes, a standards-track document can have a normative reference to an >> informational document -- as I understand it, "normative" means "you >> must understand the referenced document in order to understand this >> document", and that relationship often applies to referenced documents >> that contain requirements. However, it's a bit of a judgement call as to >> whether the requirements document should be a normative reference or an >> informative reference (and there is some controversy about whether the >> distinction between normative and informative references is all that >> useful anyway...). >>=20 >> Peter >>=20 >> -- >> Peter Saint-Andre >> https://stpeter.im/ >>=20 >>=20 >>=20 >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >>=20 >=20 >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec --B_3343658657_7745156 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [codec] updated charter Huh?  The only body that has been moderately picky about RFC status t= hat I’m aware of is the ITU.  Moderately, because I do recall ref= erences to experimental RFCs in ITU Recs, and there are certainly normative = references to obsolete/historic RFCs.
In many other mainstream SDOs, e.g. ETSI or TIA, normative references to in= formational documents are perfectly fine.
Stephan



On 12/14/09 4:30 PM, "stephen botzko" <stephen.botzko@gmail.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Though normative references made by other SDOs (= in their standards)=A0have to be made to a standards track document in the IET= F.=A0 So perhaps that is a consideration here.
=A0
Regards,
Stephen Botzko
Polycom

On Mon, Dec 14, 2009 at 5:48 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:
<= SPAN STYLE=3D'font-size:11pt'>On 12/11/09 1:09 AM, Roni Even wrote:
> Hi Peter, In general it looks OK. I have one question. The
> requirement document is defined to be informational yet I believe it > will provide values for codec quality requirements that will need to > be passed by the proposed codec. In this case should this document be<= BR> > informational or have more normative value. I assume that an
> informational document can be a normative reference.

Yes, a standards-track document can have a normative reference to an
informational document -- as I understand it, "normative" means &= quot;you
must understand the referenced document in order to understand this
document", and that relationship often applies to referenced documents=
that contain requirements. However, it's a bit of a judgement call as to whether the requirements document should be a normative reference or an
informative reference (and there is some controversy about whether the
distinction between normative and informative references is all that
useful anyway...).

Peter

--
Peter Saint-Andre
https://stpeter.im/



_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org/= mailman/listinfo/codec

=

___________= ____________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org/= mailman/listinfo/codec
--B_3343658657_7745156-- From stephen.botzko@gmail.com Mon Dec 14 19:39:54 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D8173A6870 for ; Mon, 14 Dec 2009 19:39:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.015 X-Spam-Level: X-Spam-Status: No, score=-2.015 tagged_above=-999 required=5 tests=[AWL=0.583, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VM96sI9ftbYM for ; Mon, 14 Dec 2009 19:39:53 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id A1A153A6866 for ; Mon, 14 Dec 2009 19:39:52 -0800 (PST) Received: by fxm7 with SMTP id 7so3795037fxm.29 for ; Mon, 14 Dec 2009 19:39:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=dYAKeaYiOVc5K4JfruUr10PlH30CiCvDJU/Z88L0qew=; b=IOATtWJ52ePqHvDQDu2hxbp7Ij+E6GUTtnlXYfBYPd44j5B/t//iKnA8Id9i92ai7Y dPX6e6VHycnI98fKcok8ZQGZv8mt25EFnDKDKUBnAnaeuhHYMkLilWoIYMVWCYXYSfw5 wWXVun122KCNuHANwGwTk52+cT4dwZZMvjZo0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=be6Ax9wEOPDMGclorPN4KoQpPAs+rUpFh4XYjOHaSp+2mo/o+AYoX66EqV/5F2O6Z9 PdBDp4gC3K5XXV2hYsb9+07trsgUYGG23fB07gcvDXa5ig/J+toMByvcncFCTF4zJSuN 0hFrBHgDCD+mTapF2Hk1XS5CpoNvaP9/luRv8= MIME-Version: 1.0 Received: by 10.223.92.141 with SMTP id r13mr994657fam.79.1260848375385; Mon, 14 Dec 2009 19:39:35 -0800 (PST) In-Reply-To: References: <6e9223710912141630l5e8f3109qe6848b11e0df9050@mail.gmail.com> Date: Mon, 14 Dec 2009 22:39:35 -0500 Message-ID: <6e9223710912141939l414f1398k931c6674daab0d52@mail.gmail.com> From: stephen botzko To: Stephan Wenger Content-Type: multipart/alternative; boundary=001517447a7487ce96047abc23d1 Cc: codec@ietf.org Subject: Re: [codec] updated charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 03:39:54 -0000 --001517447a7487ce96047abc23d1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The ITU-T was whati was thinking of. Currently the ITU-T does not allow normative references to informative or experimental RFCs. Existing references are not always caught, but they are supposed to be updated when the text is rerised. I'm the editor of H.323, I had to revise the text in order to remove several of these references In V7 (consented i= n Novemver). Added references *are* all checked, and you can't add references to obsolete/historic RFCS unless you can provide a justification for referring to something obsolete. Likewise, you cannot add a new normative reference to an informational RFC. Regards, Stephen Botzko Polycom On Mon, Dec 14, 2009 at 9:04 PM, Stephan Wenger wrote: > Huh? The only body that has been moderately picky about RFC status that > I=92m aware of is the ITU. Moderately, because I do recall references to > experimental RFCs in ITU Recs, and there are certainly normative referenc= es > to obsolete/historic RFCs. > In many other mainstream SDOs, e.g. ETSI or TIA, normative references to > informational documents are perfectly fine. > Stephan > > > > > On 12/14/09 4:30 PM, "stephen botzko" wrote: > > Though normative references made by other SDOs (in their standards) have = to > be made to a standards track document in the IETF. So perhaps that is a > consideration here. > > Regards, > Stephen Botzko > Polycom > > On Mon, Dec 14, 2009 at 5:48 PM, Peter Saint-Andre > wrote: > > On 12/11/09 1:09 AM, Roni Even wrote: > > Hi Peter, In general it looks OK. I have one question. The > > requirement document is defined to be informational yet I believe it > > will provide values for codec quality requirements that will need to > > be passed by the proposed codec. In this case should this document be > > informational or have more normative value. I assume that an > > informational document can be a normative reference. > > Yes, a standards-track document can have a normative reference to an > informational document -- as I understand it, "normative" means "you > must understand the referenced document in order to understand this > document", and that relationship often applies to referenced documents > that contain requirements. However, it's a bit of a judgement call as to > whether the requirements document should be a normative reference or an > informative reference (and there is some controversy about whether the > distinction between normative and informative references is all that > useful anyway...). > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > > > ------------------------------ > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > --001517447a7487ce96047abc23d1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The ITU-T was whati was thinking of.=A0 Currently the ITU-T does not allow = normative references to informative or experimental RFCs.=A0

Existi= ng references are not always caught, but they are supposed to be updated wh= en the text is rerised.=A0 I'm the editor of H.323, I had to revise the= text in order to remove several of these references In V7=A0 (consented in= Novemver).

Added references are all checked, and you can't add referenc= es to obsolete/historic RFCS unless you can provide a justification for ref= erring to something obsolete.=A0 Likewise, you cannot add a new normative r= eference to an informational RFC.

Regards,
Stephen Botzko
Polycom



On Mon, Dec 14, 2009 at 9:04 PM, Stephan Wenger = <stewe@stewe.org> wrote= :
Huh? =A0The only body that has been moderately picky about RFC stat= us that I=92m aware of is the ITU. =A0Moderately, because I do recall refer= ences to experimental RFCs in ITU Recs, and there are certainly normative r= eferences to obsolete/historic RFCs.
In many other mainstream SDOs, e.g. ETSI or TIA, normative references to in= formational documents are perfectly fine.
Stephan




On 12/14/09 4:30 PM, "stephen botzko" <stephen.botzko@gmail.com> wro= te:

Though normative references made by other SDOs (in their standards)=A0= have to be made to a standards track document in the IETF.=A0 So perhaps th= at is a consideration here.
=A0
Regards,
Stephen Botzko
Polycom

On Mon, Dec 14, 2009 at 5:48 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:
On 12/11/09 1:09 AM, Roni Even wrote:
> Hi Peter, In general it looks OK. I have one question. The
> requirement document is defined to be informational yet I believe it > will provide values for codec quality requirements that will need to > be passed by the proposed codec. In this case should this document be<= br> > informational or have more normative value. I assume that an
> informational document can be a normative reference.

Yes, a standards-track document can have a normative reference to an
informational document -- as I understand it, "normative" means &= quot;you
must understand the referenced document in order to understand this
document", and that relationship often applies to referenced documents=
that contain requirements. However, it's a bit of a judgement call as t= o
whether the requirements document should be a normative reference or an
informative reference (and there is some controversy about whether the
distinction between normative and informative references is all that
useful anyway...).

Peter

--
Peter Saint-Andre
https://stpeter.im/


_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec



_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

--001517447a7487ce96047abc23d1-- From root@core3.amsl.com Wed Dec 23 09:15:01 2009 Return-Path: X-Original-To: codec@ietf.org Delivered-To: codec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7BAE33A697D; Wed, 23 Dec 2009 09:15:01 -0800 (PST) From: IESG Secretary To: ietf-announce@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20091223171501.7BAE33A697D@core3.amsl.com> Date: Wed, 23 Dec 2009 09:15:01 -0800 (PST) Cc: codec@ietf.org Subject: [codec] WG Review: Internet Wideband Audio Codec (codec) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: iesg@ietf.org List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 17:15:01 -0000 A new IETF working group has been proposed in the Real-time Applications and Infrastructure Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by January 20, 2010. Internet Wideband Audio Codec (codec) ------------------------------------------------------------------------- Last Modified: 2009-12-17 Proposed Chair(s): * TBD Real-time Applications and Infrastructure Area Director(s): * Robert Sparks * Cullen Jennings Real-time Applications and Infrastructure Area Advisor: * Cullen Jennings Mailing Lists: General Discussion: codec@ietf.org To Subscribe: codec-request@ietf.org In Body: subscribe Archive: https://www.ietf.org/mailman/listinfo/codec Description of Working Group Problem Statement According to reports from developers of Internet audio applications and operators of Internet audio services, there are no standardized, high-quality audio codecs that meet all of the following three conditions: 1. Are optimized for use in interactive Internet applications. 2. Are published by a recognized standards development organization (SDO) and therefore subject to clear change control. 3. Can be widely implemented and easily distributed among application developers, service operators, and end users. There exist codecs that provide high quality encoding of audio information, but that are not optimized for the actual conditions of the Internet; according to reports, this mismatch between design and deployment has hindered adoption of such codecs in interactive Internet applications. There exist codecs that can be widely implemented and easily distributed, but that are not standardized through any SDO; according to reports, this lack of standardization and clear change control has hindered adoption of such codecs in interactive Internet applications. There exist codecs that are standardized, but that cannot be widely implemented and easily distributed; according to reports, the presence of various usage restrictions (e.g., in the form of requirements to pay royalty fees, obtain a license, enter into a business agreement, or meet other special conditions imposed by a patent holder) has hindered adoptions of such codecs in interactive Internet applications. According to application developers and service operators, an audio codec that meets all three of these would: (1) enable protocol designers to more easily specify a mandatory-to-implement codec in their protocols and thus improve interoperability; (2) enable developers to more easily easily build innovative, interactive applications for the Internet; (3) enable service operators to more easily deploy affordable, high-quality audio services on the Internet; and (4) enable end users of Internet applications and services to enjoy an improved user experience. Objectives The goal of this working group is to develop a single high-quality audio codec that is optimized for use over the Internet and that can be widely implemented and easily distributed among application developers, service operators, and end users. Core technical considerations include, but are not necessarily limited to, the following: 1. Designing for use in interactive applications (examples include, but are not limited to, point-to-point voice calls, multi-party voice conferencing, telepresence, teleoperation, in-game voice chat, and live music performance) 2. Addressing the real transport conditions of the Internet as identified and prioritized by the working group 3. Ensuring interoperability with the Real-time Transport Protocol (RTP), including secure transport via SRTP 4. Ensuring interoperability with Internet signaling technologies such as Session Initiation Protocol (SIP), Session Description Protocol (SDP), and Extensible Messaging and Presence Protocol (XMPP); however, the result should not depend on the details of any particular signaling technology Optimizing for very low bit rates (typically below 2.4 kbps) and for non-interactive audio is out of scope because such work might necessitate specialized optimizations. Although the codec produced by the working group might be used as a mandatory-to-implement technology by designers of particular Internet protocols, it is explicitly not a goal of the working group to produce a codec that will be mandated for use across the entire IETF or Internet community nor would their be any expectation that this would be the only mandatory-to-implement codec. The goal of the working group is to produce only one codec. Based on the working group's analysis of the design space, the working group might determine that it needs to produce more than one codec, or a codec with multiple modes; however, it is not the goal of working group to produce more than one codec, and to reduce confusion in the marketplace the working group shall endeavor to produce as few codecs as possible. In completing its work, the working group should collaborate with other IETF working groups to complete particular tasks. These might include, but would not be limited to, the following: - Within the AVT WG, define the codec's payload format for use with the Real-time Transport Protocol (RTP). - Collaborate with working groups in the Transport Area to identify important aspects of packet transmission over the Internet. - Collaborate with working groups in the Transport Area to understand the degree of rate adaptation desirable, and to reflect that understanding in the design of a codec that can adjust its transmission in a way that minimizes disruption to the audio. - Collaborate with working groups in the RAI Area to ensure that information about and negotiation of the codec can be easily represented at the signaling layer. The working group will inform the ITU-T (Study group 16) of each new revision of working group drafts, with the intent of submitting the completed codec RFC for co-publication by the ITU-T if the ITU-T finds that appropriate. The working group will communicate detailed description of the requirements and goals to other SDOs including the ITU-T, 3GPP, and MPEG to help determine if existing codecs meet the requirements and would therefore enable co-publication of an existing standard at the IETF. The working group will also continue to discuss with other standards bodies to determine if it becomes possible to satisfy the IETF requirements through a new or revised standard at other bodies. Suggested Codec Standardization Guidelines and Requirements for achieving the foregoing objectives are provisionally outlined in draft-valin-codec-guidelines and draft-valin-codec-requirements respectively; these documents will form the starting point for working toward consensus and, if accepted as work items of the working group, will be refined by the working group in accordance with the usual IETF procedures. A codec that can be widely implemented and easily distributed among application developers, service operators, and end users is preferred. Many existing codecs that might fulfill some or most of the technical attributes listed above are encumbered in various ways. For example, patent holders might require that those wishing to implement the codec in software, deploy the codec in a service, or distribute the codec in software or hardware need to request a license, enter into a business agreement, pay licensing fees or royalties, or attempt to adhere to other special conditions or restrictions. Because such encumbrances have made it difficult to widely implement and easily distribute high-quality audio codecs across the entire Internet community, the working group prefers unencumbered technologies in a way that is consistent with BCP 78 and BCP 79. In particular, the working group shall heed the preference stated in BCP 79: "In general, IETF working groups prefer technologies with no known IPR claims or, for technologies with claims against them, an offer of royalty-free licensing." Although this preference cannot guarantee that the working group will produce an unencumbered codec, the working group shall attempt to adhere to the spirit of BCP 79. This preference does not explicitly rule out the possibility of adapting encumbered technologies; such decisions will be made in accordance with the rough consensus of the working group. Deliverables 1. A set of Codec Standardization Guidelines that define the work processes of the working group. This document shall be Informational. 2. A set of technical Requirements. This document shall be Informational. 3. Specification of a codec that meets the agreed-upon requirements, in the form of an Internet-Draft that defines the codec algorithm along with source code for a reference implementation. The text description of the codec shall indicate which components of the encoder and decoder are mandatory, recommended, and optional. It is envisioned that this document shall be a Proposed Standard document. Milestones Mar-2010: WGLC on Codec Standardization Guidelines May-2010: Codec Standardization Guidelines to IESG (Informational) May-2010: WGLC on Requirements Jul-2010: Requirements to IESG (Informational) Dec-2010: Freeze codec structure Jun-2011: Finalize codec parameters Jul-2011: WGLC on codec specification Oct-2011: Submit codec specification to IESG (Standards Track) From fluffy@cisco.com Wed Dec 23 11:59:08 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20FA83A6A00 for ; Wed, 23 Dec 2009 11:59:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.559 X-Spam-Level: X-Spam-Status: No, score=-106.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0clNFnsrAsa1 for ; Wed, 23 Dec 2009 11:59:06 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id B682F3A6A03 for ; Wed, 23 Dec 2009 11:59:06 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAN8EMkurR7H+/2dsb2JhbADCJZcIgi4HgX4EgR6MPA X-IronPort-AV: E=Sophos;i="4.47,444,1257120000"; d="scan'208";a="230164861" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 23 Dec 2009 19:58:49 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nBNJwmdY007529 for ; Wed, 23 Dec 2009 19:58:48 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings Date: Wed, 23 Dec 2009 12:58:47 -0700 Content-Transfer-Encoding: 7bit Message-Id: <05EC20BC-A4C6-434A-A2A2-88EE3BEE4AA7@cisco.com> References: <20091223171501.7BAE33A697D@core3.amsl.com> To: codec@ietf.org X-Mailer: Apple Mail (2.1077) Subject: [codec] Fwd: WG Review: Internet Wideband Audio Codec (codec) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 19:59:08 -0000 Begin forwarded message: > From: IESG Secretary > Date: December 23, 2009 10:15:01 AM MST > To: ietf-announce@ietf.org > Cc: codec@ietf.org > Subject: [codec] WG Review: Internet Wideband Audio Codec (codec) > Reply-To: iesg@ietf.org > > A new IETF working group has been proposed in the Real-time Applications > and Infrastructure Area. The IESG has not made any determination as yet. > The following draft charter was submitted, and is provided for > informational purposes only. Please send your comments to the IESG > mailing list (iesg@ietf.org) by January 20, 2010. > > Internet Wideband Audio Codec (codec) > ------------------------------------------------------------------------- > Last Modified: 2009-12-17 > > Proposed Chair(s): > * TBD > > Real-time Applications and Infrastructure Area Director(s): > * Robert Sparks > * Cullen Jennings > > Real-time Applications and Infrastructure Area Advisor: > * Cullen Jennings > > Mailing Lists: > General Discussion: codec@ietf.org > To Subscribe: codec-request@ietf.org > In Body: subscribe > Archive: https://www.ietf.org/mailman/listinfo/codec > > Description of Working Group > Problem Statement > > According to reports from developers of Internet audio applications and > operators of Internet audio services, there are no standardized, > high-quality audio codecs that meet all of the following three > conditions: > > 1. Are optimized for use in interactive Internet applications. > > 2. Are published by a recognized standards development organization > (SDO) and therefore subject to clear change control. > > 3. Can be widely implemented and easily distributed among application > developers, service operators, and end users. > > There exist codecs that provide high quality encoding of audio > information, but that are not optimized for the actual conditions of the > Internet; according to reports, this mismatch between design and > deployment has hindered adoption of such codecs in interactive Internet > applications. > > There exist codecs that can be widely implemented and easily > distributed, but that are not standardized through any SDO; according to > reports, this lack of standardization and clear change control has > hindered adoption of such codecs in interactive Internet applications. > > There exist codecs that are standardized, but that cannot be widely > implemented and easily distributed; according to reports, the presence > of various usage restrictions (e.g., in the form of requirements to pay > royalty fees, obtain a license, enter into a business agreement, or meet > other special conditions imposed by a patent holder) has hindered > adoptions of such codecs in interactive Internet applications. > > According to application developers and service operators, an audio > codec that meets all three of these would: (1) enable protocol > designers to more easily specify a mandatory-to-implement codec in > their protocols and thus improve interoperability; (2) enable > developers to more easily easily build innovative, interactive > applications for the Internet; (3) enable service operators to more > easily deploy affordable, high-quality audio services on the Internet; > and (4) enable end users of Internet applications and services to enjoy > an improved user experience. > > Objectives > > The goal of this working group is to develop a single high-quality audio > codec that is optimized for use over the Internet and that can be widely > implemented and easily distributed among application developers, service > operators, and end users. Core technical considerations include, but > are not necessarily limited to, the following: > > 1. Designing for use in interactive applications (examples include, but > are not limited to, point-to-point voice calls, multi-party voice > conferencing, telepresence, teleoperation, in-game voice chat, and live > music performance) > > 2. Addressing the real transport conditions of the Internet as > identified and prioritized by the working group > > 3. Ensuring interoperability with the Real-time Transport Protocol > (RTP), including secure transport via SRTP > > 4. Ensuring interoperability with Internet signaling technologies such > as Session Initiation Protocol (SIP), Session Description Protocol > (SDP), and Extensible Messaging and Presence Protocol (XMPP); however, > the result should not depend on the details of any particular signaling > technology > > Optimizing for very low bit rates (typically below 2.4 kbps) and for > non-interactive audio is out of scope because such work might > necessitate specialized optimizations. > > Although the codec produced by the working group might be used as a > mandatory-to-implement technology by designers of particular Internet > protocols, it is explicitly not a goal of the working group to produce a > codec that will be mandated for use across the entire IETF or Internet > community nor would their be any expectation that this would be the only > mandatory-to-implement codec. > > The goal of the working group is to produce only one codec. Based on > the working group's analysis of the design space, the working group > might determine that it needs to produce more than one codec, or a codec > with multiple modes; however, it is not the goal of working group to > produce more than one codec, and to reduce confusion in the marketplace > the working group shall endeavor to produce as few codecs as possible. > > In completing its work, the working group should collaborate with other > IETF working groups to complete particular tasks. These might include, > but would not be limited to, the following: > > - Within the AVT WG, define the codec's payload format for use with the > Real-time Transport Protocol (RTP). > > - Collaborate with working groups in the Transport Area to identify > important aspects of packet transmission over the Internet. > > - Collaborate with working groups in the Transport Area to understand > the degree of rate adaptation desirable, and to reflect that > understanding in the design of a codec that can adjust its > transmission in a way that minimizes disruption to the audio. > > - Collaborate with working groups in the RAI Area to ensure that > information about and negotiation of the codec can be easily > represented at the signaling layer. > > The working group will inform the ITU-T (Study group 16) of each new > revision of working group drafts, with the intent of submitting the > completed codec RFC for co-publication by the ITU-T if the ITU-T finds > that appropriate. The working group will communicate detailed > description of the requirements and goals to other SDOs including the > ITU-T, 3GPP, and MPEG to help determine if existing codecs meet the > requirements and would therefore enable co-publication of an existing > standard at the IETF. The working group will also continue to discuss > with other standards bodies to determine if it becomes possible to > satisfy the IETF requirements through a new or revised standard at other > bodies. > > Suggested Codec Standardization Guidelines and Requirements for > achieving the foregoing objectives are provisionally outlined in > draft-valin-codec-guidelines and draft-valin-codec-requirements > respectively; these documents will form the starting point for working > toward consensus and, if accepted as work items of the working group, > will be refined by the working group in accordance with the usual IETF > procedures. > > A codec that can be widely implemented and easily distributed among > application developers, service operators, and end users is preferred. > Many existing codecs that might fulfill some or most of the technical > attributes listed above are encumbered in various ways. For example, > patent holders might require that those wishing to implement the codec > in software, deploy the codec in a service, or distribute the codec in > software or hardware need to request a license, enter into a business > agreement, pay licensing fees or royalties, or attempt to adhere to > other special conditions or restrictions. > > Because such encumbrances have made it difficult to widely implement and > easily distribute high-quality audio codecs across the entire Internet > community, the working group prefers unencumbered technologies in a way > that is consistent with BCP 78 and BCP 79. In particular, the working > group shall heed the preference stated in BCP 79: "In general, IETF > working groups prefer technologies with no known IPR claims or, for > technologies with claims against them, an offer of royalty-free > licensing." Although this preference cannot guarantee that the working > group will produce an unencumbered codec, the working group shall > attempt to adhere to the spirit of BCP 79. This preference does not > explicitly rule out the possibility of adapting encumbered technologies; > such decisions will be made in accordance with the rough consensus of > the working group. > > Deliverables > > 1. A set of Codec Standardization Guidelines that define the work > processes of the working group. This document shall be Informational. > > 2. A set of technical Requirements. This document shall be > Informational. > > 3. Specification of a codec that meets the agreed-upon requirements, in > the form of an Internet-Draft that defines the codec algorithm along > with source code for a reference implementation. The text description > of the codec shall indicate which components of the encoder and decoder > are mandatory, recommended, and optional. It is envisioned that this > document shall be a Proposed Standard document. > > Milestones > > Mar-2010: WGLC on Codec Standardization Guidelines > May-2010: Codec Standardization Guidelines to IESG (Informational) > May-2010: WGLC on Requirements > Jul-2010: Requirements to IESG (Informational) > Dec-2010: Freeze codec structure > Jun-2011: Finalize codec parameters > Jul-2011: WGLC on codec specification > Oct-2011: Submit codec specification to IESG (Standards Track) > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From ron.even.tlv@gmail.com Wed Dec 23 22:54:25 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7256B3A68C2; Wed, 23 Dec 2009 22:54:25 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aw+EqdPbByWp; Wed, 23 Dec 2009 22:54:25 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id B75B43A688C; Wed, 23 Dec 2009 22:54:24 -0800 (PST) Received: by fxm7 with SMTP id 7so7593836fxm.29 for ; Wed, 23 Dec 2009 22:54:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=f72bK9O2Weez2aKr4E3VEMvZbvvcpV+QxFGRLNUMDjI=; b=RUCqbktuDR7QKMzqg+S2OGAeBvp/ArO5jsPAc+u8U49CXVMBF44q2rkkwWZoB3fad8 WC0Tzp+xdv3HtTqt8Twf5hsMlK9wmTOZ1gHtq4NO6qVb/ViOaM46YpJ0l+TyRDWjEnku CHwEJX6/BuBrSyBVJcSr81qwRqG1KjqmCkv4M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=OwhCS7h84tLyxa1oyeAi6IxUM9ZJEJTBaP/UPwcBkc3sTFXBdGfNKX4zu+jYMxTKU3 QlWi44/spgY+STttery8IO+heaflJ4eB0mUt0Kj5/KbJFxvGas7eVRgnSRpEHzxXZqPI Qtmb6Bm7rdI3/R5zea0LJOayEVNl5VVCfGVDg= Received: by 10.223.110.32 with SMTP id l32mr4151715fap.90.1261637643523; Wed, 23 Dec 2009 22:54:03 -0800 (PST) Received: from windows8d787f9 (bzq-82-81-132-18.red.bezeqint.net [82.81.132.18]) by mx.google.com with ESMTPS id 1sm7139780fks.59.2009.12.23.22.54.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 23 Dec 2009 22:54:02 -0800 (PST) From: "Roni Even" To: "'Robert Elz'" , "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" References: <3D3C75174CB95F42AD6BCC56E5555B450204C143@FIESEXC015.nsn-intra.net> <20091223171501.7BAE33A697D@core3.amsl.com> <14093.1261593597@epsilon.noi.kre.to> <14853.1261600779@epsilon.noi.kre.to> In-Reply-To: <14853.1261600779@epsilon.noi.kre.to> Date: Thu, 24 Dec 2009 08:50:30 +0200 Message-ID: <4b33100a.01135e0a.2ab9.ffff8e9b@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcqEEF215VwqapPNTgSSar+KGaBFqgAU6BkA Content-language: en-us Cc: codec@ietf.org, iesg@ietf.org, ietf@ietf.org Subject: Re: [codec] WG Review: Internet Wideband Audio Codec (codec) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 06:54:25 -0000 Hi, I am not sure but are you suggesting that the IETF will define the requirements, metric and quality assessment requirements and all proposed codecs should provide the results and then the WG will choose the best codec bases without discussing the codec itself. This is what I would call a selection process (at least in ITU terms). The problem is that the IETF process allows anyone to contribute to existing work hopefully leading to a better the end result. What about the change control, does it stay with the original contributor or can the IETF modify the codec based on input from other parties, which means that the codec may change by the IETF anyhow. Thanks Roni Even > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of > Robert Elz > Sent: Wednesday, December 23, 2009 10:40 PM > To: Tschofenig, Hannes (NSN - FI/Espoo) > Cc: iesg@ietf.org; ietf@ietf.org > Subject: Re: WG Review: Internet Wideband Audio Codec (codec) > > Date: Wed, 23 Dec 2009 21:48:18 +0200 > From: "Tschofenig, Hannes (NSN - FI/Espoo)" > > Message-ID: > <3D3C75174CB95F42AD6BCC56E5555B450204C143@FIESEXC015.nsn-intra.net> > > | That's something for the working group to figure out. > | My experience: things are typically more complicated than they > initially > | look like. > > Yes, of course, but the proposed charter goes to great lengths to point > out why solutions from the first and third of the three categories of > existing codecs are no good, but it more or less ignored the middle > category - then, it seemed to me, more or less demanded that a new > codec > (or perhaps codecs) be developed. > > That's the wrong approach, the emphasis should be on adopting something > that exists, if at all possible, and only inventing something new if > there really is no other choice. > > That's why I'd prefer the charter to be revised with that in mind. > > | WG charters are also written for those who have not followed the > history > | of the work very closely. These folks typically need a bit more > | background information. > > Yes, but no-one needs that much ... (no need to delete all of that > stuff about encumbered technology, just most of it) > > kre > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From kre@munnari.OZ.AU Thu Dec 24 01:49:41 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 095BE3A67E1; Thu, 24 Dec 2009 01:49:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.332 X-Spam-Level: X-Spam-Status: No, score=-0.332 tagged_above=-999 required=5 tests=[AWL=0.716, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcQDQzb9+OnJ; Thu, 24 Dec 2009 01:49:40 -0800 (PST) Received: from jade.coe.psu.ac.th (unknown [202.29.151.3]) by core3.amsl.com (Postfix) with ESMTP id 779323A67AD; Thu, 24 Dec 2009 01:49:39 -0800 (PST) Received: from epsilon.noi.kre.to (jade.coe.psu.AC.TH [IPv6:2001:3c8:9009:181::2]) by jade.coe.psu.ac.th with ESMTP id nBO9lr79021633; Thu, 24 Dec 2009 16:47:55 +0700 (ICT) Received: from epsilon.noi.kre.to (localhost [127.0.0.1]) by epsilon.noi.kre.to (8.14.3/8.14.2) with ESMTP id nBO9lGg1027662; Thu, 24 Dec 2009 16:47:23 +0700 (ICT) From: Robert Elz To: "Roni Even" In-Reply-To: <4b33100a.01135e0a.2ab9.ffff8e9b@mx.google.com> References: <4b33100a.01135e0a.2ab9.ffff8e9b@mx.google.com> <3D3C75174CB95F42AD6BCC56E5555B450204C143@FIESEXC015.nsn-intra.net> <20091223171501.7BAE33A697D@core3.amsl.com> <14093.1261593597@epsilon.noi.kre.to> <14853.1261600779@epsilon.noi.kre.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 24 Dec 2009 16:47:16 +0700 Message-ID: <2401.1261648036@epsilon.noi.kre.to> Sender: kre@munnari.OZ.AU X-Mailman-Approved-At: Thu, 24 Dec 2009 04:53:43 -0800 Cc: codec@ietf.org, "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , iesg@ietf.org, ietf@ietf.org Subject: Re: [codec] WG Review: Internet Wideband Audio Codec (codec) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 09:49:41 -0000 Date: Thu, 24 Dec 2009 08:50:30 +0200 From: "Roni Even" Message-ID: <4b33100a.01135e0a.2ab9.ffff8e9b@mx.google.com> | I am not sure but are you suggesting that the IETF will define the | requirements, metric and quality assessment requirements and all proposed | codecs should provide the results and then the WG will choose the best codec | bases without discussing the codec itself. This is what I would call a | selection process (at least in ITU terms). The WG can decide how it wants to go about the process, I'd just prefer that the charter not (effectively) rule out selection of something that already exists with an assumption that something entirely new will be created. | The problem is that the IETF process allows anyone to contribute to existing | work hopefully leading to a better the end result. Of course, but also be aware that there's no one definition of "better". Something that can be defined quickly and used immediately might be much better than something it takes 5 years to create and more to implement, even if the invented one saves a little bandwidth or has better loss recovery characteristics. | What about the change control, does it stay with the original contributor or | can the IETF modify the codec based on input from other parties, which means | that the codec may change by the IETF anyhow. The IETF will have change control over its protocol, of course, which may cause it to diverge from that upon which it was originally based. And yes, everything changes with time. kre From ron.even.tlv@gmail.com Thu Dec 24 06:00:14 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC9D63A683D; Thu, 24 Dec 2009 06:00:14 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oem-8ikxAVe3; Thu, 24 Dec 2009 06:00:14 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 6CA9E3A6804; Thu, 24 Dec 2009 06:00:13 -0800 (PST) Received: by fxm7 with SMTP id 7so7827978fxm.29 for ; Thu, 24 Dec 2009 05:59:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=LiZR4BWPjILIOr7vRdH2eV0jv33hLhAf2sG4haNU6yY=; b=wIDxXfWqI0RNObml+HH/moUUJhBt3LiHkKsPrNgfYmDcgAYN7kMogSxsO8T3ojL8BD /OOk44Kmjb4dFWIF2yAgZtMDx8EALGoFZAOC3iVbHkgLIsXtYN88okQHztM+YnCAiFak 6WiE4DCx3mG5aXwDZ0kewBwjsi8LZzV6DW7Hs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=jQNoKMEACDuujpa8ADUoz7mxpB8fpRWYQrIRHejooFfvOjCwwaM3texmOP5+MRkozY m0aSg+wVLuFCLOfVXYeN9RHvzcaGPnhTdPb1BFDZ0Of20+UoswJU0l8vE6VaeNy/G1U2 yWdalVPYzFS5IUC7wK+iTiWhOhgcUIK3xUnjE= Received: by 10.223.76.137 with SMTP id c9mr12826942fak.76.1261663192638; Thu, 24 Dec 2009 05:59:52 -0800 (PST) Received: from windows8d787f9 (bzq-82-81-132-18.red.bezeqint.net [82.81.132.18]) by mx.google.com with ESMTPS id 2sm12742689fks.43.2009.12.24.05.59.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 24 Dec 2009 05:59:51 -0800 (PST) From: "Roni Even" To: References: <4b33100a.01135e0a.2ab9.ffff8e9b@mx.google.com> <3D3C75174CB95F42AD6BCC56E5555B450204C143@FIESEXC015.nsn-intra.net> <20091223171501.7BAE33A697D@core3.amsl.com> <14093.1261593597@epsilon.noi.kre.to> <14853.1261600779@epsilon.noi.kre.to> <2401.1261648036@epsilon.noi.kre.to> In-Reply-To: <2401.1261648036@epsilon.noi.kre.to> Date: Thu, 24 Dec 2009 15:56:17 +0200 Message-ID: <4b3373d7.02135e0a.241a.fffffb62@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcqEfi9uKAo2iezGQ1O9wdnnGXLqIgAIfBuA Content-language: en-us Cc: codec@ietf.org, "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , iesg@ietf.org, ietf@ietf.org Subject: Re: [codec] WG Review: Internet Wideband Audio Codec (codec) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 14:00:15 -0000 Hi, In line Roni Even > -----Original Message----- > From: kre@munnari.OZ.AU [mailto:kre@munnari.OZ.AU] > Sent: Thursday, December 24, 2009 11:47 AM > To: Roni Even > Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; iesg@ietf.org; > ietf@ietf.org; codec@ietf.org > Subject: Re: WG Review: Internet Wideband Audio Codec (codec) > > Date: Thu, 24 Dec 2009 08:50:30 +0200 > From: "Roni Even" > Message-ID: <4b33100a.01135e0a.2ab9.ffff8e9b@mx.google.com> > > | I am not sure but are you suggesting that the IETF will define the > | requirements, metric and quality assessment requirements and all > proposed > | codecs should provide the results and then the WG will choose the > best codec > | bases without discussing the codec itself. This is what I would > call a > | selection process (at least in ITU terms). > > The WG can decide how it wants to go about the process, I'd just prefer > that > the charter not (effectively) rule out selection of something that > already > exists with an assumption that something entirely new will be created. > > | The problem is that the IETF process allows anyone to contribute to > existing > | work hopefully leading to a better the end result. > > Of course, but also be aware that there's no one definition of > "better". > Something that can be defined quickly and used immediately might be > much > better than something it takes 5 years to create and more to implement, > even if the invented one saves a little bandwidth or has better loss > recovery characteristics. This is the IETF process for better or worse, I asked similar questions and the response is that the IETF decide what is better is based on rough consensus. BTW: my personal view is that your suggestion is in line with the process at the ITU when doing codec selection, but there are people who prefer doing it at the IETF using the IETF procedures for other reasons. > > | What about the change control, does it stay with the original > contributor or > | can the IETF modify the codec based on input from other parties, > which means > | that the codec may change by the IETF anyhow. > > The IETF will have change control over its protocol, of course, which > may > cause it to diverge from that upon which it was originally based. And > yes, > everything changes with time. > > kre From hallam@gmail.com Thu Dec 24 19:26:29 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D7EE3A67D3; Thu, 24 Dec 2009 19:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.792 X-Spam-Level: X-Spam-Status: No, score=-2.792 tagged_above=-999 required=5 tests=[AWL=-0.192, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHhcxWOQVuau; Thu, 24 Dec 2009 19:26:28 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id C3FA53A6784; Thu, 24 Dec 2009 19:26:27 -0800 (PST) Received: by yxe30 with SMTP id 30so9753469yxe.29 for ; Thu, 24 Dec 2009 19:26:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=WUsyIHvBEbpM6UgmDOpMKleebOE0MqhC2fBxMhR59Xs=; b=JL1BM/MXVvdXVPAEuZa5EyvfFB6U9RBE8URv8sBcKRfwcM8ks0csVBpwdDi3wnSW06 JUqfDCwEg+2TEq3t3M3mMPf+7Yy727A42WWQvNCdIhkM5UTBmDjItkIb1icnhNUfNZm4 /HsqQrDgCZVWmzQnFC3VXpaYc13eM6pRcrD8Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=akto6VYqx9b1ZAfOZUJNlRFIXrxAXKq0KQ8kvitQLsW0x/baciB01hFrKDYDWV5CQC be42CND2sIxqTDQyhJNh9jfMdsV2YjT9W+gvYz6rqqIXt5Pr1Dpq5/0gB989v8IMZnUr ppiYZ3KQLorPVGHlVxxKbUrXORIC7bFSYt/z4= MIME-Version: 1.0 Received: by 10.91.54.18 with SMTP id g18mr162781agk.92.1261711567577; Thu, 24 Dec 2009 19:26:07 -0800 (PST) In-Reply-To: <4b3373d7.02135e0a.241a.fffffb62@mx.google.com> References: <4b33100a.01135e0a.2ab9.ffff8e9b@mx.google.com> <3D3C75174CB95F42AD6BCC56E5555B450204C143@FIESEXC015.nsn-intra.net> <20091223171501.7BAE33A697D@core3.amsl.com> <14093.1261593597@epsilon.noi.kre.to> <14853.1261600779@epsilon.noi.kre.to> <2401.1261648036@epsilon.noi.kre.to> <4b3373d7.02135e0a.241a.fffffb62@mx.google.com> Date: Thu, 24 Dec 2009 22:26:07 -0500 Message-ID: From: Phillip Hallam-Baker To: Roni Even Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 24 Dec 2009 21:05:00 -0800 Cc: codec@ietf.org, iesg@ietf.org, kre@munnari.oz.au, ietf@ietf.org Subject: Re: [codec] WG Review: Internet Wideband Audio Codec (codec) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Dec 2009 03:26:29 -0000 I don't think it is a very good idea to attempt this type of work in the IETF. We have enough difficulty doing crypto algorithms and that is an area where we have tens of people with decades worth of expertise who pretty much mostly agree on the algorithms to use in any case. An unencumbered CODEC would be very useful, but any new CODEC that was developed would be subject to attack by patent trolls. So the group would be pretty much limited to reviewing existing technologies and attempting to select one that is out of patent. Looking at technologies that are out-of-patent or soon to be out of patent, well DVD came out in 1995 and the patent licensing terms are reasonably well defined. MP3 and AC3 are the existing industry standards. If we know when the patents drop dead, I can't see how IETF imprimatur is going to add or detract anything there. Its not as if the IETF can stand behind the spec and say that it is definitively unencumbered. So the most we are going to have is a document that brings together all the relevant information and allows people to quickly come to a degree of confidence that the technology will be inencumbered on a certain date. On Thu, Dec 24, 2009 at 8:56 AM, Roni Even wrote: > Hi, > In line > Roni Even > >> -----Original Message----- >> From: kre@munnari.OZ.AU [mailto:kre@munnari.OZ.AU] >> Sent: Thursday, December 24, 2009 11:47 AM >> To: Roni Even >> Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; iesg@ietf.org; >> ietf@ietf.org; codec@ietf.org >> Subject: Re: WG Review: Internet Wideband Audio Codec (codec) >> >> =A0 =A0 Date: =A0 =A0 =A0 =A0Thu, 24 Dec 2009 08:50:30 +0200 >> =A0 =A0 From: =A0 =A0 =A0 =A0"Roni Even" >> =A0 =A0 Message-ID: =A0<4b33100a.01135e0a.2ab9.ffff8e9b@mx.google.com> >> >> =A0 | I am not sure but are you suggesting that the IETF will define the >> =A0 | requirements, metric and quality assessment requirements and all >> proposed >> =A0 | codecs should provide the results and then the WG will choose the >> best codec >> =A0 | bases without discussing the codec itself. This is what I would >> call a >> =A0 | selection process (at least in ITU terms). >> >> The WG can decide how it wants to go about the process, I'd just prefer >> that >> the charter not (effectively) rule out selection of something that >> already >> exists with an assumption that something entirely new will be created. >> >> =A0 | The problem is that the IETF process allows anyone to contribute t= o >> existing >> =A0 | work hopefully leading to a better the end result. >> >> Of course, but also be aware that there's no one definition of >> "better". >> Something that can be defined quickly and used immediately might be >> much >> better than something it takes 5 years to create and more to implement, >> even if the invented one saves a little bandwidth or has better loss >> recovery characteristics. > > This is the IETF process for better or worse, I asked similar questions a= nd > the response is that the IETF decide what is better is based on rough > consensus. > BTW: my personal view is that your suggestion is in line with the process= at > the ITU when doing codec selection, but there are people who prefer doing= it > at the IETF using the IETF procedures for other reasons. > > >> >> =A0 | What about the change control, does it stay with the original >> contributor or >> =A0 | can the IETF modify the codec based on input from other parties, >> which means >> =A0 | that the codec may change by the IETF anyhow. >> >> The IETF will have change control over its protocol, of course, which >> may >> cause it to diverge from that upon which it was originally based. =A0And >> yes, >> everything changes with time. >> >> kre > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > --=20 --=20 New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ From steveu@coppice.org Thu Dec 24 21:22:45 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79EC13A6842 for ; Thu, 24 Dec 2009 21:22:45 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJfkB--IRhRK for ; Thu, 24 Dec 2009 21:22:44 -0800 (PST) Received: from hanghau.pacific.net.hk (hanghau.pacific.net.hk [202.64.33.147]) by core3.amsl.com (Postfix) with ESMTP id 6CE223A6823 for ; Thu, 24 Dec 2009 21:22:44 -0800 (PST) Received: from i7.coppice.org ([202.64.176.25]) by hanghau.pacific.net.hk with ESMTP id nBP5MPih003099 for ; Fri, 25 Dec 2009 13:22:25 +0800 Message-ID: <4B344C11.60406@coppice.org> Date: Fri, 25 Dec 2009 13:22:25 +0800 From: Steve Underwood User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-3.fc11 Thunderbird/3.0 MIME-Version: 1.0 To: codec@ietf.org References: <4b33100a.01135e0a.2ab9.ffff8e9b@mx.google.com> <3D3C75174CB95F42AD6BCC56E5555B450204C143@FIESEXC015.nsn-intra.net> <20091223171501.7BAE33A697D@core3.amsl.com> <14093.1261593597@epsilon.noi.kre.to> <14853.1261600779@epsilon.noi.kre.to> <2401.1261648036@epsilon.noi.kre.to> <4b3373d7.02135e0a.241a.fffffb62@mx.google.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [codec] WG Review: Internet Wideband Audio Codec (codec) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Dec 2009 05:22:45 -0000 On 12/25/2009 11:26 AM, Phillip Hallam-Baker wrote: > I don't think it is a very good idea to attempt this type of work in > the IETF. We have enough difficulty doing crypto algorithms and that > is an area where we have tens of people with decades worth of > expertise who pretty much mostly agree on the algorithms to use in any > case. > > An unencumbered CODEC would be very useful, but any new CODEC that was > developed would be subject to attack by patent trolls. So the group > would be pretty much limited to reviewing existing technologies and > attempting to select one that is out of patent. > > Looking at technologies that are out-of-patent or soon to be out of > patent, well DVD came out in 1995 and the patent licensing terms are > reasonably well defined. MP3 and AC3 are the existing industry > standards. If we know when the patents drop dead, I can't see how IETF > imprimatur is going to add or detract anything there. Its not as if > the IETF can stand behind the spec and say that it is definitively > unencumbered. So the most we are going to have is a document that > brings together all the relevant information and allows people to > quickly come to a degree of confidence that the technology will be > inencumbered on a certain date. > So, you think the IETF should stop all work, because there's not a single thing they define that can't be subject to the same patent issues. Steve From koen.vos@skype.net Thu Dec 24 23:55:51 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43D803A68F6; Thu, 24 Dec 2009 23:55:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkzyK5qifMRA; Thu, 24 Dec 2009 23:55:50 -0800 (PST) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id B0A773A682C; Thu, 24 Dec 2009 23:55:49 -0800 (PST) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id EFE226003D73C; Fri, 25 Dec 2009 07:55:30 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=FHHm4dMS1w3w x+1jGAamVlyT3Mk=; b=nxWoPpbwJy0xoDEYKfSKBNRxo2Ec1COxVKAz2kKJyy2Q 8gQnZ1pcIihx3CmJdEpvrujUPGwkVJBH3tOt7Q1GM0JM/v7z4O+6B8H1lxFc536p BPxLCvRYNROptg70igOn994KUasntvdkuuRR6Fw/quRLnOXru02cXyzjNX9ofxg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:cc:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=E1OX0cc42TYJGyMxnTvB em2H3ElJ+bwba0uoMzZNANSiwEIKNzzhz02p1V/f6AWs+aNP15qsG2s9E2Qr9na8 MMUuQbyDG9RchGgdV+LHRsTTVcJ0bLKgzeZMVPs2GMuk9+CbWz73BB/7SD+gvXsb O6LuuJlC7oIhOJKuhRKKTgk= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id E37F26003D6F6; Fri, 25 Dec 2009 07:55:30 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at dub-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIxulsYXMDqW; Fri, 25 Dec 2009 07:55:30 +0000 (GMT) Received: by mail.skype.net (Postfix, from userid 33) id 2BE2B6003D728; Fri, 25 Dec 2009 07:55:30 +0000 (GMT) Received: from ip64-75-163-14.hsia.aloha.net (ip64-75-163-14.hsia.aloha.net [64.75.163.14]) by mail.skype.net (Horde Framework) with HTTP; Thu, 24 Dec 2009 23:55:30 -0800 Message-ID: <20091224235530.49092xi81l9bng1e@mail.skype.net> Date: Thu, 24 Dec 2009 23:55:30 -0800 From: Koen Vos To: Phillip Hallam-Baker References: <4b33100a.01135e0a.2ab9.ffff8e9b@mx.google.com> <3D3C75174CB95F42AD6BCC56E5555B450204C143@FIESEXC015.nsn-intra.net> <20091223171501.7BAE33A697D@core3.amsl.com> <14093.1261593597@epsilon.noi.kre.to> <14853.1261600779@epsilon.noi.kre.to> <2401.1261648036@epsilon.noi.kre.to> <4b3373d7.02135e0a.241a.fffffb62@mx.google.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Cc: codec@ietf.org, iesg@ietf.org, kre@munnari.oz.au, ietf@ietf.org Subject: Re: [codec] WG Review: Internet Wideband Audio Codec (codec) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Dec 2009 07:55:51 -0000 Quoting Phillip Hallam-Baker: > MP3 and AC3 are the existing industry standards. These codecs are rarely used for real-time communications, mostly because of their high bitrates/poor quality for voice signals. > So the most we are going to have is a document that > brings together all the relevant information and allows people to > quickly come to a degree of confidence that the technology will be > inencumbered on a certain date. Any difference with other standards? koen. From steveu@coppice.org Fri Dec 25 00:22:20 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AB3C3A692C for ; Fri, 25 Dec 2009 00:22:20 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lKs-bDXyO17 for ; Fri, 25 Dec 2009 00:22:19 -0800 (PST) Received: from cwb.pacific.net.hk (cwb.pacific.net.hk [202.14.67.92]) by core3.amsl.com (Postfix) with ESMTP id 6DBBC3A693B for ; Fri, 25 Dec 2009 00:22:19 -0800 (PST) Received: from i7.coppice.org (25.176.64.202.dyn.pacific.net.hk [202.64.176.25]) by cwb.pacific.net.hk with ESMTP id nBP8M0oP011179 for ; Fri, 25 Dec 2009 16:22:00 +0800 Message-ID: <4B347628.104@coppice.org> Date: Fri, 25 Dec 2009 16:22:00 +0800 From: Steve Underwood User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-3.fc11 Thunderbird/3.0 MIME-Version: 1.0 To: codec@ietf.org References: <4b33100a.01135e0a.2ab9.ffff8e9b@mx.google.com> <3D3C75174CB95F42AD6BCC56E5555B450204C143@FIESEXC015.nsn-intra.net> <20091223171501.7BAE33A697D@core3.amsl.com> <14093.1261593597@epsilon.noi.kre.to> <14853.1261600779@epsilon.noi.kre.to> <2401.1261648036@epsilon.noi.kre.to> <4b3373d7.02135e0a.241a.fffffb62@mx.google.com> <20091224235530.49092xi81l9bng1e@mail.skype.net> In-Reply-To: <20091224235530.49092xi81l9bng1e@mail.skype.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [codec] WG Review: Internet Wideband Audio Codec (codec) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Dec 2009 08:22:20 -0000 On 12/25/2009 03:55 PM, Koen Vos wrote: > Quoting Phillip Hallam-Baker: >> MP3 and AC3 are the existing industry standards. > > These codecs are rarely used for real-time communications, mostly > because of their high bitrates/poor quality for voice signals. I would have thought their latency was the key factor for interactive communication, which is the main focus here. Regards, Steve From koen.vos@skype.net Fri Dec 25 00:53:02 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 738A33A6942 for ; Fri, 25 Dec 2009 00:53:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-57SVTDGFoN for ; Fri, 25 Dec 2009 00:53:01 -0800 (PST) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id 7059F3A6945 for ; Fri, 25 Dec 2009 00:53:01 -0800 (PST) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 94C7E6003D756 for ; Fri, 25 Dec 2009 08:52:43 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=kNJjdQsaYFUz WCx0V3wHNh7D6oQ=; b=kTt0iXaFNOkf8z3iNPtoy4nFtZEFVO7gKmUZVEgDrFPM rzoDc0YObZNxIIZpWyI88mdlKLi8ahOlgJfJDZFzH7NZW29q0qDCCpMoOg5nyzBk HgC3oojWN+Qb60f2eo5H9MK/uvojnFlhM+UiYoWAmGSXqD5PAYJDETbb3JyjWuA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=dKmIuGg92VCjicV28qy6 hgtBa7eN1ptsXgq7KM7HRoZslMAWvRcHttylNoonOoBoWKAZzsXwYtC+frxFeXte OSTtdYIEzVVICF/3lkpydg+rHkbxPyjLVvJy0eBpVOG3hqN5Z6jmCMl7JJJGPZUT svm8UZ/VQ1fQ9CPV/6/smmE= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 9224D6003C8A9 for ; Fri, 25 Dec 2009 08:52:43 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at dub-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unbe1WKddd8q for ; Fri, 25 Dec 2009 08:52:42 +0000 (GMT) Received: by mail.skype.net (Postfix, from userid 33) id E44BB6003D753; Fri, 25 Dec 2009 08:52:42 +0000 (GMT) Received: from ip64-75-163-14.hsia.aloha.net (ip64-75-163-14.hsia.aloha.net [64.75.163.14]) by mail.skype.net (Horde Framework) with HTTP; Fri, 25 Dec 2009 00:52:42 -0800 Message-ID: <20091225005242.13596y3o026d04t6@mail.skype.net> Date: Fri, 25 Dec 2009 00:52:42 -0800 From: Koen Vos To: codec@ietf.org References: <4b33100a.01135e0a.2ab9.ffff8e9b@mx.google.com> <3D3C75174CB95F42AD6BCC56E5555B450204C143@FIESEXC015.nsn-intra.net> <20091223171501.7BAE33A697D@core3.amsl.com> <14093.1261593597@epsilon.noi.kre.to> <14853.1261600779@epsilon.noi.kre.to> <2401.1261648036@epsilon.noi.kre.to> <4b3373d7.02135e0a.241a.fffffb62@mx.google.com> <20091224235530.49092xi81l9bng1e@mail.skype.net> <4B347628.104@coppice.org> In-Reply-To: <4B347628.104@coppice.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Subject: Re: [codec] WG Review: Internet Wideband Audio Codec (codec) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Dec 2009 08:53:02 -0000 Quoting Steve Underwood: > I would have thought their latency was the key factor for > interactive communication That's a factor too. MP3 has 54 ms algorithmic delay (at 48 kHz sampling rate) - around 11 ms more than G.718. AC3 seems to have < 10 ms algorithmic delay. koen.