From magnus.westerlund@ericsson.com Mon Oct 9 03:04:57 2023 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B337FC151534 for ; Mon, 9 Oct 2023 03:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.009 X-Spam-Level: X-Spam-Status: No, score=-7.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzpUgRNlF6F6 for ; Mon, 9 Oct 2023 03:04:52 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04on2083.outbound.protection.outlook.com [40.107.6.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3305FC14E513 for ; Mon, 9 Oct 2023 03:04:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fSGV0CXSNZxl0ysDCLViwzaOwY7IBFe9w2h4gS7/5qrScTKvouLJfgDGtMv/7Tw4qItUE21NdfLTHvcl/o9gW8DeFwao3a1ker3iNOhSp4+o+RtTQyx4S991RjbzjCFx3dIET5Vwd+TZKOAUpCnUkE0Q2jWROlVQrbWkktutqZ78kE9+kyf5pXb24kMbuhGZHrPRDLCAAIU3XB/r4RyaISZTNIKlV/Fj0G76RYCNijNyEBzFzlrgyEtyMGcqYsEhTVdlIrnpyCXXwGmipW2dCPPM5uQYv7amPKNwnPjufu1o/P0YWEwafHYhVgRpupLwK74UvR5RqVAqkxQ8YD86DA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9x0PRSkFCIffiWKquq/6Jr33HpRwrbYWENtw83OQMsw=; b=WnPVhVEqh9Mw9ztZAjo9cJDkaibjttaQU48UADh8jtoOSYgWPak95cVra2C3MivGm/pPVmFAMT4yv/7wyKDTrTN6V7koi2SMiv4SUl9SbSCxR6PC3o7+ik1IN3NIMrQ1oZIDz7ximAiTMolLKII54PnCXTBf4fQng8cW/u8zGsHFpxZ6IhRcFFXKGVSSlJoOJl7QLPFce087yejZsnJL1AosATY8aOfcfyAD4BY5GYJZjhTaqqykqcGjldIVojFEbM+0SJACYrxZpDFVXL2DviWLs2BF0vmNhL4QujSo9hf7KrCOXqDHGeMueZv+OkSP3SVkPI9vhuSaytv+EEbp2Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9x0PRSkFCIffiWKquq/6Jr33HpRwrbYWENtw83OQMsw=; b=ms6N/gsjdRyNm83+waAGwCXC7C+hXXcLKCdlLlxWjkcqqXWBNw3FOAUbVTbw0EG2+7iVugDNrzuhiowmt5IGwWuWfqi0DpCR7mKFxnrG3tap5vRk2RHI2ekgnUgDGS2ZY+1QVO75I6CsBtA/GbvpabYBkOce8CY0wE4QGyBdiNA= Received: from DU0PR07MB8970.eurprd07.prod.outlook.com (2603:10a6:10:40e::17) by VI1PR07MB6256.eurprd07.prod.outlook.com (2603:10a6:800:133::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6863.36; Mon, 9 Oct 2023 10:04:48 +0000 Received: from DU0PR07MB8970.eurprd07.prod.outlook.com ([fe80::56cc:35fd:adfa:2117]) by DU0PR07MB8970.eurprd07.prod.outlook.com ([fe80::56cc:35fd:adfa:2117%6]) with mapi id 15.20.6838.040; Mon, 9 Oct 2023 10:04:48 +0000 From: Magnus Westerlund To: Stephan Wenger , Bernard Aboba , IETF AVTCore WG CC: Harald Alvestrand Thread-Topic: [AVTCORE] Fwd: RTP payload format type registry vs. MIME-type registry Thread-Index: AQHZ9lW8Rpyd95aRj0iT0EFXR682TLA5pNQAgAeaNfw= Date: Mon, 9 Oct 2023 10:04:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, sv-SE Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DU0PR07MB8970:EE_|VI1PR07MB6256:EE_ x-ms-office365-filtering-correlation-id: f890d39e-c361-4b38-b2ba-08dbc8af2bd6 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: b4Y145GtaiWrWZYGfWmf6kdRhI3ph0lzguT5L/B9VgNvvFjInppZ8eFTKaieHVlecUkD8VNfEAINBOKquLTDgNvVRcvshWJEtviYim5pl/qyXT+tiPPuDrJnTT2+ncfPJzSKoQA3zi+bmHO2fxgUo5FoEBS3AaWoapckX/Jbw3gGC7smFmUTL+GSG7iFombNABOcstAcC7Gp9GZ25IcOhqWXoh2b8m/8lRTiWWtvw3QHv46EB8lROC7tdOT0TI2K+HR2Iwf7HqCcejUlA+NK3zvzYKRpA1zQepfRE+Z0vWsHQH0DU1eeJE5sDrY/KA2/XSrU+ioAtBQBUNXu5LOll8VQmnRzQy7bUU0UFOaIeFm93HxS3WnndEgvITk0LNlSmDxW1+8r3bgxffNWp262NshlLxGlUlWmHmu3eayormWziMofOv3CHbhhhNCrFsKUkMlidjri+UAh+GBwS4JJbvw59x/GhoyAf4ZHNFl5Gi52pO6tqUfzp/p8G1lERRXMxX0I6AP+Hti6xbKK50SaF9WveXaoKeEyJWCh7ZkQkG7h9tYSxcl736LQnsH5RdbZyt2lOvZMcHUXP/bFsSy0rRsEoZGaT+Js0tGT5bGnd7LcqcZVof3XRbW/k9Ok3touNtH6RmvilmEbL0ggW3dyFw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DU0PR07MB8970.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(136003)(376002)(346002)(39860400002)(396003)(366004)(230922051799003)(1800799009)(64100799003)(186009)(451199024)(7696005)(9686003)(66899024)(71200400001)(26005)(53546011)(55016003)(82960400001)(33656002)(38070700005)(86362001)(38100700002)(166002)(122000001)(83380400001)(4326008)(2906002)(478600001)(6506007)(8676002)(8936002)(52536014)(44832011)(21615005)(966005)(41300700001)(316002)(5660300002)(64756008)(66446008)(66946007)(110136005)(66556008)(66476007)(76116006); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?KSS3GlQDdubhgs+QF23oeXLBhmjQeLVnzHMc77ytsB71TlOSeNjdq+GJ?= =?Windows-1252?Q?gmty2dXWtWSlZvEFf5beSED3A0xR0bHqCwzaqgd3FnYjbPHUfAhOBUJ3?= =?Windows-1252?Q?9/bde/4AhAlYsGJXbStOE7sobakzLWnjZu8AcZim5DRI70k+SXy1akqU?= =?Windows-1252?Q?gJi3fCr/FPrzpt4MA6+TkXQ3VOZM/YSrSiO6N4eG18pYy3egNi3LLJZq?= =?Windows-1252?Q?tWQHyspC7KtPiNbYk8rm/SGca1urxsmq8KbfgQGsgpc1HOLRowlWh0IA?= =?Windows-1252?Q?GOOXRw4JA5/GdBFtqNWyTNDl5QurOe5Uc2WbU9K6bBxtYCPZUX7Pr+FI?= =?Windows-1252?Q?xsHxOMk7CmnwhHCuBA66pMOvC/FLROyw6RFYJs0L4N19oKhjBTBI82k0?= =?Windows-1252?Q?ol4sd8tOOlnAaPAtusDa5rjlfVUkjWTsbYpZhCWTJgr07iojvUKqHM8v?= =?Windows-1252?Q?aPpd4wNzpuQQYWzLQGGUFe/18Y87dgaElLnKTqHCfSc90zqVvNlR8thY?= =?Windows-1252?Q?Gm9NIfY1oeeHBdpQ/n3o7EUEDqtFkqZT/3f0HTkqh8d61IAQ4fmpVXtC?= =?Windows-1252?Q?tDnD3BRpNquIHCNi4GPq/RJngzvsHjsEOn9s8+r37yg2qid72gaEd2I4?= =?Windows-1252?Q?4XV8F1NuEsn6wAx1CSx8dYZiQFRGHYYNQD0QAqDVKuQ+2X/kiVufxsDE?= =?Windows-1252?Q?mTqfB9Gy21idVBtNG7FDf0TwpwKxjPL6iSwe5k0BPEs+td4aO0Hb32HK?= =?Windows-1252?Q?XTRxt3uHHzXzvVOZxY57Qw8ef2rvGTbCMb89uFyjRuoTxxMGB/BR24Ca?= =?Windows-1252?Q?6xVmRz11/fkPbpbW8sTUOprLa+7gk/3Wz1gZoirnGFmYYoNpyaBP3Mde?= =?Windows-1252?Q?Qquzpen4tCkuObgmdSlcRGCojuuEjUjZbASAuAxAWkN8avtzK9MMufN6?= =?Windows-1252?Q?VouUbSH3lkj5MGAhfDsOEo6AnVo/4V0brU8t+BI/4JooiC13BeI2Rsk6?= =?Windows-1252?Q?PpN8++Do3a0xcARzl25+DioYKTLKP0FYOe+GnZDFt0m81ys59U7Um5K6?= =?Windows-1252?Q?1vK6oF9VCwEB6qE2oV9Lni82e2bMkI59vhHDYSSE5ZYuEN6YlH+JPhMw?= =?Windows-1252?Q?5rnpKPEavgJX1xZDI6YOnASeLrpNV04Of3QZMBChmpMSLb+uAgyQ7/Zc?= =?Windows-1252?Q?b2gEahziF/pat9pAfhrrdwVqqSRDx8MgXphKTdYI+/2CTofKWfwIrozr?= =?Windows-1252?Q?R13b/Vay9ZngEj9rWQAR0Epg+ikUujZysyN+1xpfIrVAh/opRL6QHfJT?= =?Windows-1252?Q?ZdDlUtCy6UVil+Rp94KBVFxQQSS2swGIIijNU5lEGESPGvAfTvJkmj0V?= =?Windows-1252?Q?eDmI69+XMmYC1GYYXVmsmB/xkjhvILfE6ydFUlEoaJTj/+tk8bmVIhez?= =?Windows-1252?Q?9/zjxxdsE1bqw9LFkM8qIoAzjEmQLzUOPoh0cBCtqgK5a97oG1HTsjNz?= =?Windows-1252?Q?H5E746TFuJbK/0IBzjoZp2z1r57TASYrkL0hg06A5uc2WkmJDWCAmFxN?= =?Windows-1252?Q?GUohVJlcyf6Pwqr2E3Rgg0tAcKlDnCtb+mj5J+jKljJVR/Z/AU8fxNVM?= =?Windows-1252?Q?UnBw7rBdGnskDn6jJHPA+p5WKob86Ri++SgN0Rgy29a/gzbYyq5kp+xK?= =?Windows-1252?Q?zNF5KKeRFNCLCsK9UNf/0v8ILroIANmy4I2CnOq/0iVsUegJH53qlsNg?= =?Windows-1252?Q?wW4ZRNrE8qZbCkUoIAk=3D?= Content-Type: multipart/alternative; boundary="_000_DU0PR07MB897048FB88F5DBADBFC9813B95CEADU0PR07MB8970eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DU0PR07MB8970.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f890d39e-c361-4b38-b2ba-08dbc8af2bd6 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2023 10:04:48.2758 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: RMSi8KwPKsS/4t/C/K7i8EmBYjGVxlWr20QlPj2/vPB1EFchp+IflKWDR5IZJHnfZp69wx0KEvII+W0JuVthw/JC/iilWqKEe6dg3jSjGkU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB6256 Archived-At: Subject: Re: [AVTCORE] Fwd: RTP payload format type registry vs. MIME-type registry X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2023 10:04:57 -0000 --_000_DU0PR07MB897048FB88F5DBADBFC9813B95CEADU0PR07MB8970eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, The RTP Payload Format Media Types is a mostly redundant registry, in that = its only purpose is to help determine which media types that has RTP Payloa= d formats. Already prior to RFC 8088 was written we had discussion about th= is registry and if we should kill it. We didn=92t do that at that time, and= the best we could do in RFC 8088 was to be very clear that you need to ens= ure that it is registered there also. However, as noted it has been forgott= en several times, as the media type registry is what is actually relevant t= o register. I would think a reasonable way forward is to actually close the registry an= d update RFC4855 and RFC 8088. When closing this, one could consider to cle= an up the registry up to the date of closing by adding the missing RTP payl= oad format media types that have been missed. But, unless someone knows of = someone externally depending on this registry, to avoid future issues, and = also be able to make a clear comment that this registry is not relevant in = a note, writing a document killing it is likely an easy way forward. Cheers Magnus From: Stephan Wenger Date: Wednesday, 4 October 2023 at 15:43 To: Bernard Aboba , IETF AVTCore WG Cc: Harald Alvestrand , Magnus Westerlund Subject: Re: [AVTCORE] Fwd: RTP payload format type registry vs. MIME-type = registry Hi, Copying specifically Harald Alvenstrand (as Mediaman chair) and Magnus West= erlund (as RFC 8088 author) I=92m an arguably experienced payload format author, but know little about = IANA mechanics, and care even less. I=92m sure I=92m not alone with respec= t to the latter. People like me will need a template and guidance from whi= ch we can copy-paste-adapt in the future. I don=92t know who can provide t= hat guidance, but frankly, I don=92t believe AVTcore is the right group to = provide it, simply because we didn=92t get it right so many times in the pa= st. I also don=92t think we can rely on guidance by the IESG or the media= type review people without specifically asking. They didn=92t spot proble= ms in the past, either. I have no idea on how to arrive at that suggestion, though W3C identifying = and Bernard and Jonathan taking ownership of the problem by at least descri= bing it clearly is an excellent first step. Maybe move the discussion over= to the media-types list? Or Mediaman could help? Once we have the senten= ce or two needed, the EVC payload could be used as a test case as it is in = the right stage of the process to see results quickly. Then, I would suggest revising RFC 8088 and specifically section 7.4. (In = a revised RFC 8088, we should also insert a section dealing with normative = references to media codec specs, as this has been another recent pain point= .) Stephan From: avt on behalf of Bernard Aboba Date: Tuesday, October 3, 2023 at 16:59 To: IETF AVTCore WG Subject: [AVTCORE] Fwd: RTP payload format type registry vs. MIME-type regi= stry On August 29, 2023 a post to the W3C public-webrtc mailing list pointed out= an issue with IANA RTP payload format type registrations: https://lists.w3= .org/Archives/Public/public-webrtc/2023Aug/0033.html The RTP payload format registry, which is referenced by the W3C WebRTC-PC s= pecification, omits entries for widely deployed video codecs, including VP8= (RFC 7741), HEVC (RFC 7798), VVC (RFC 9328) and AV1 (https://aomediacodec.= github.io/av1-rtp-spec/): https://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-pa= rameters-2 However, the IANA mime-types registry (see =93video=94) is more complete, i= ncluding entries for the missing codecs: https://www.iana.org/assignments/m= edia-types/media-types.xhtml At the IETF AVTCORE WG interim meeting on September 26, the WG discussed th= e discrepancy and based on the discussion, it appears that the divergence b= etween the two registries is inadvertent. Jonathan and I took the action = item to consult with IANA to explore ways we could address the divergence. I have sent an email to IANA relating to the registries and will report bac= k to the WG at IETF 118 about potential options for addressing the divergen= ce. Notes -------- The VP8 RTP payload format (RFC 7741) Media-type Section 6.1 references bot= h the RFC 6838 Mime-type registration template as well as the RFC 4855 RTP = payload format registration, yet VP8 was only registered in the Mime-type r= egistry. The VP9 RTP payload format (https://datatracker.ietf.org/doc/draft-ietf-pay= load-vp9/) Media-Type Section 7 references both RFC 6838 and RFC 4855. VP9= was registered in both registries. The HEVC RTP payload format (RFC 7798) Media-type Section 7.1 mentions only= that "The media subtype for the HEVC codec is allocated from the IETF tree= " which would appear to refer to the MIME-type registry. It was registered = only in the MIME-type registry. The VVC RTP payload format (RFC 9328) Media-type Section 7.1 does not inclu= de an explicit indication of which registry to use for the registration. It= was registered only in the MIME-type registry. The AV1 RTP payload format Media-type Section 7.1 (https://aomediacodec.git= hub.io/av1-rtp-spec/#71-media-type-definition) refers explicitly to t= he MIME-type registry (https://www.iana.org/assignments/media-types/video/A= V1 ) It was registered only in the MIME-type registry. The EVC RTP payload format (draft-ietf-avtcore-rtp-evc) Media-type Section = 7.1 does not include an explicit indication of which registry to use for th= e registration. Should we add a reference to RFC 4855 so as to indicate th= at it should be registered in both the RTP payload format and MIME-type reg= istries? --_000_DU0PR07MB897048FB88F5DBADBFC9813B95CEADU0PR07MB8970eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi,

 

The RTP Payload Format Media Types is a mostly redun= dant registry, in that its only purpose is to help determine which media ty= pes that has RTP Payload formats. Already prior to RFC 8088 was written we had discussion about this registry and if= we should kill it. We didn=92t do that at that time, and the best we could= do in RFC 8088 was to be very clear that you need to ensure that it is reg= istered there also. However, as noted it has been forgotten several times, as the media type registry is what is= actually relevant to register.

 

I would think a reasonable way forward is to actuall= y close the registry and update RFC4855 and RFC 8088. When closing this, on= e could consider to clean up the registry up to the date of closing by adding the missing RTP payload format media t= ypes that have been missed. But, unless someone knows of someone externally= depending on this registry, to avoid future issues, and also be able to ma= ke a clear comment that this registry is not relevant in a note, writing a document killing it is likely an easy= way forward.

 

Cheers

 

Magnus

 

 

From: Step= han Wenger <stewe@stewe.org>
Date: Wednesday, 4 October 2023 at 15:43
To: Bernard Aboba <bernard.aboba@gmail.com>, IETF AVTCore WG &= lt;avt@ietf.org>
Cc: Harald Alvestrand <harald@alvestrand.no>, Magnus Westerlun= d <magnus.westerlund@ericsson.com>
Subject: Re: [AVTCORE] Fwd: RTP payload format type registry vs. MIM= E-type registry

Hi,<= o:p>

&nbs= p;

Copy= ing specifically Harald Alvenstrand (as Mediaman chair) and Magnus Westerlu= nd (as RFC 8088 author)

&nbs= p;

I=92= m an arguably experienced payload format author, but know little about IANA= mechanics, and care even less.  I=92m sure I=92m not alone with respe= ct to the latter.  People like me will need a template and guidance from which we can copy-paste-adapt in the future.  I don= =92t know who can provide that guidance, but frankly, I don=92t believe AVT= core is the right group to provide it, simply because we didn=92t get it ri= ght so many times in the past.   I also don=92t think we can rely on guidance by the IESG or the media type review people = without specifically asking.  They didn=92t spot problems in the past,= either. 

&nbs= p;

I ha= ve no idea on how to arrive at that suggestion, though W3C identifying and = Bernard and Jonathan taking ownership of the problem by at least describing= it clearly is an excellent first step.  Maybe move the discussion over to the media-types list?  Or Mediaman = could help?  Once we have the sentence or two needed, the EVC payload = could be used as a test case as it is in the right stage of the process to = see results quickly.

&nbs= p;

Then= , I would suggest revising RFC 8088 and specifically section 7.4.  (In= a revised RFC 8088, we should also insert a section dealing with normative= references to media codec specs, as this has been another recent pain point.)

&nbs= p;

Step= han

&nbs= p;

&nbs= p;

From: avt <av= t-bounces@ietf.org> on behalf of Bernard Aboba <bernard.aboba@gmail.c= om>
Date: Tuesday, October 3, 2023 at 16:59
To: IETF AVTCore WG <avt@ietf.org>
Subject: [AVTCORE] Fwd: RTP payload format type registry vs. MIME-ty= pe registry

On August 29, 2023 a post to the W3C public-webrtc mailing list pointe= d out an issue with IANA RTP payload format type registrations: = https://lists.w3.org/Archives/Public/public-webrtc/2023Aug/0033.html=

 

The RTP payload format registry, which is referenc= ed by the W3C WebRTC-PC specification, omits entries for widely deployed vi= deo codecs, including VP8 (RFC 7741), HEVC (RFC 7798), VVC (RFC 9328) and AV1 (https://aomediacod= ec.github.io/av1-rtp-spec/): 

 

However, the IANA mime-types registry (see =93video=94) is more complete, including entries for the missing codecs: https://www.iana.org/assignments/media-types/med= ia-types.xhtml

 

At the IETF AVTCORE WG interim meeting on Septembe= r 26, the WG discussed the discrepancy and based on the discussion, it appe= ars that the divergence between the two registries is inadvertent.   Jonathan and I took the action item= to consult with IANA to explore ways we could address the divergence. = ;

 

I have sent an email to IANA relating to the regis= tries and will report back to the WG at IETF 118 about potential options fo= r addressing the divergence. 

 

Notes

--------

 

The VP8 RTP payload format (RFC 7741) Media-type S= ection 6.1 references both the RFC 6838 Mime-type registration template as = well as the RFC 4855 RTP payload format registration, yet VP8 was only registered in the Mime-type registry. =

 

The VP9 RTP payload format (https://da= tatracker.ietf.org/doc/draft-ietf-payload-vp9/) Media-Type Section 7 references both RFC 6838 and RFC 4855.  VP9 was = registered in both registries. 

 

The HEVC RTP payload format (RFC 7798) Media-type = Section 7.1 mentions only that "The media subtype for th= e HEVC codec is allocated from the IETF tree" which would appear to re= fer to the MIME-type registry. It was registered only in the MIME-type regi= stry. 

 

The VVC RTP payload format (RFC 9328) = Media-type Section 7.1 does not include an explicit indication of which reg= istry to use for the registration. It was registered only in the MIME-type registry. 

 

The AV1 RTP payload format Media-type = Section 7.1 (https://aomediacodec.github.io/av1-= rtp-spec/#71-media-type-definition) refers explicitly to the MIME-type registry (https://www.iana.org/assignments/media-types/vide= o/AV1 ) It was registered only in the MIME-type registry. 

 

The EVC RTP payload format (draft-ietf= -avtcore-rtp-evc) Media-type Section 7.1 does not include an explicit indic= ation of which registry to use for the registration.  Should we add a reference to RFC 4855 so as to indicate that it should be = registered in both the RTP payload format and MIME-type registries? 

 

 

 

 

 

 

 

--_000_DU0PR07MB897048FB88F5DBADBFC9813B95CEADU0PR07MB8970eurp_--