From ron.even.tlv@gmail.com Mon Oct 9 05:10:24 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 D2591C14CE22 for ; Mon, 9 Oct 2023 05:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.005 X-Spam-Level: X-Spam-Status: No, score=-7.005 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 PMec2hpoflng for ; Mon, 9 Oct 2023 05:10:20 -0700 (PDT) Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3BE2C14E513 for ; Mon, 9 Oct 2023 05:10:15 -0700 (PDT) Received: by mail-ot1-x32c.google.com with SMTP id 46e09a7af769-6c4c594c0eeso3018849a34.0 for ; Mon, 09 Oct 2023 05:10:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696853415; x=1697458215; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=IdPXEcFUX0mVETMaTxUFA0XSvsxS3Z28ofWy/BKzXfw=; b=jVR9j+g+/Bv4234OJjOQMXmZwyxW5ysUbb2MYgTxuWZ8Ck8DYwdRFr2pflKW3iV2fA irYyqmf6ohWWFSbjbcimEd00+KzGOQaG00lyJX7qZW4ZGUVhJ9pwQm9l85jPm11sEP7S 9ZRa+HDwcRKEbz5JVtGMw78axJq5FogzvmnNrChieeN6yAK5LltIuJnV589hzpjzTVVP Ol2Bi8WbP2gDEXv6V7Kvhz0xqDBttmuvJ6vb+DR85thFaMdsAAb6JTs8Vi1cweJfC5YX nMZs75XhUvO6op6Cmps4i6wwlmox/N6aQbvDnYPgc0NXIjHsA1d6Z6CJP6tACwleGjvO 3U3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696853415; x=1697458215; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=IdPXEcFUX0mVETMaTxUFA0XSvsxS3Z28ofWy/BKzXfw=; b=IwljBros2NRcmvLiLCl2PzubljZIWB0ytobAYSqfKZz65+LZEcYTJGiTFbDuWvicmu O/YuhQfG4SriknFsSa+ND9Zzl1FUSKBvo/nq437+6/TcqgldAJ8MUTFq1XW/nv+osjXG TAVPVIGtCmh/zYt/FlB/nvJKF13laa4+LUhCV+xKuIq1Ot7YdTRlWcgwpv6gW81jt2X2 xDSHqzXpgORKlD4vx3pmCdku8oAvyodiaj76JbGKXbm6pKZGpelD2/AjkjNjHX3ZSRPq hiDiaF2YNzKr0/7qg3bIEkGW2gu45nix9SXjMmIR0c4ukRcThHnrAvxeunOMyr2Vw/TG unhg== X-Gm-Message-State: AOJu0YyhLFkVFBjF92tz4bRZCFQt2In02Fyh/gNGxMtSvXMGwb732xuF dvSAHhe4Qdp8DyTyypehyxxx1gH77gK9S9v3qNQ= X-Google-Smtp-Source: AGHT+IGumgKmd4qw2PsSOmJPaigm2cBjxyB8fDMBRNjK7yswBQzEgRN6q3lpS4DqnvXUQ0rfWHlmRN1h61z0BnI3aGE= X-Received: by 2002:a05:6358:98a8:b0:139:b4c0:94d with SMTP id q40-20020a05635898a800b00139b4c0094dmr19117917rwa.12.1696853414600; Mon, 09 Oct 2023 05:10:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ron Even Date: Mon, 9 Oct 2023 15:10:03 +0300 Message-ID: To: Magnus Westerlund Cc: Bernard Aboba , Harald Alvestrand , IETF AVTCore WG , Stephan Wenger Content-Type: multipart/alternative; boundary="0000000000000362df060747792a" 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 12:10:24 -0000 --0000000000000362df060747792a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I agree with what Magnus suggested. I was part of the discussion in the pas= t Roni Even On Mon, 9 Oct 2023 at 13:05 Magnus Westerlund wrote: > Hi, > > > > The RTP Payload Format Media Types is a mostly redundant registry, in tha= t > its only purpose is to help determine which media types 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=E2=80=99t do that a= t that > time, and the best we could do in RFC 8088 was to be very clear that you > need to ensure that it is registered 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 actually close the registry > and update RFC4855 and RFC 8088. When closing this, one could consider to > clean up the registry up to the date of closing by adding the missing RTP > payload format media types that have been missed. But, unless someone kno= ws > 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 releva= nt > 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 < > avt@ietf.org> > *Cc: *Harald Alvestrand , Magnus Westerlund < > magnus.westerlund@ericsson.com> > *Subject: *Re: [AVTCORE] Fwd: RTP payload format type registry vs. > MIME-type registry > > Hi, > > > > Copying specifically Harald Alvenstrand (as Mediaman chair) and Magnus > Westerlund (as RFC 8088 author) > > > > I=E2=80=99m an arguably experienced payload format author, but know littl= e about > IANA mechanics, and care even less. I=E2=80=99m sure I=E2=80=99m not alo= ne with respect to > the latter. People like me will need a template and guidance from which = we > can copy-paste-adapt in the future. I don=E2=80=99t know who can provide= that > guidance, but frankly, I don=E2=80=99t believe AVTcore is the right group= to > provide it, simply because we didn=E2=80=99t get it right so many times i= n the > past. I also don=E2=80=99t think we can rely on guidance by the IESG or= the media > type review people without specifically asking. They didn=E2=80=99t spot= problems > in the past, either. > > > > I have no idea on how to arrive at that suggestion, though W3C identifyin= g > 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 w= e > 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. > > > > Then, I would suggest revising RFC 8088 and specifically section 7.4. (I= n > a revised RFC 8088, we should also insert a section dealing with normativ= e > references to media codec specs, as this has been another recent pain > point.) > > > > Stephan > > > > > > *From: *avt on behalf of Bernard Aboba < > bernard.aboba@gmail.com> > *Date: *Tuesday, October 3, 2023 at 16:59 > *To: *IETF AVTCore WG > *Subject: *[AVTCORE] Fwd: RTP payload format type registry vs. MIME-type > registry > > 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 > specification, 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-= parameters-2 > > > > However, the IANA mime-types registry (see =E2=80=9Cvideo=E2=80=9D) is mo= re complete, > including entries for the missing codecs: > https://www.iana.org/assignments/media-types/media-types.xhtml > > > > At the IETF AVTCORE WG interim meeting on September 26, the WG discussed > the discrepancy and based on the discussion, it appears that the divergen= ce > between the two registries is inadvertent. Jonathan and I took the acti= on > 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 > back to the WG at IETF 118 about potential options for addressing the > divergence. > > > > Notes > > -------- > > > > The VP8 RTP payload format (RFC 7741) Media-type Section 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://datatracker.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 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 > include 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.github.io/av1-rtp-spec/#71-media-type-definition > ) > refers explicitly to the MIME-type registry ( > https://www.iana.org/assignments/media-types/video/AV1 ) It was > registered only in the MIME-type registry. > > > > The EVC RTP payload format (draft-ietf-avtcore-rtp-evc) Media-type Sectio= n > 7.1 does not include an explicit indication of which registry to use for > the registration. Should we add a reference to RFC 4855 so as to indicat= e > that it should be registered in both the RTP payload format and MIME-type > registries? > > > > > > > > > > > > > > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > --0000000000000362df060747792a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
I agree with what Magnus sugge= sted. I was part of the discussion in the past
Roni = Even

On Mon, 9 Oct 2023 at 13:05 Magnus Westerlund <magnus.westerlun= d=3D40ericsson.com@dmarc.i= etf.org> wrote:

Hi,<= u>

<= /u>=C2=A0

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 Payload fo= rmats. Already prior to RFC 8088 was written we had discussion about this registry and if= we should kill it. We didn=E2=80=99t 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 registered there also. However, as noted it has been forgotten several times, as the media type registry is what is= actually relevant to register.

<= /u>=C2=A0

I wo= uld think a reasonable way forward is to actually close the registry and up= date RFC4855 and RFC 8088. When closing this, one could consider to clean u= p 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.

<= /u>=C2=A0

Chee= rs

<= /u>=C2=A0

Magn= us

=C2=A0

=C2=A0

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

Hi,<= u>

=C2= =A0

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

=C2= =A0

I=E2= =80=99m an arguably experienced payload format author, but know little abou= t IANA mechanics, and care even less.=C2=A0 I=E2=80=99m sure I=E2=80=99m no= t alone with respect to the latter.=C2=A0 People like me will need a templa= te and guidance from which we can copy-paste-adapt in the future.=C2=A0 I don= =E2=80=99t know who can provide that guidance, but frankly, I don=E2=80=99t= believe AVTcore is the right group to provide it, simply because we didn= =E2=80=99t get it right so many times in the past.=C2=A0=C2=A0 I also don= =E2=80=99t think we can rely on guidance by the IESG or the media type review people = without specifically asking.=C2=A0 They didn=E2=80=99t spot problems in the= past, either.=C2=A0

=C2= =A0

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.=C2=A0 Maybe move the discussion over to the media-types list?=C2=A0 Or Mediaman = could help?=C2=A0 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.

=C2= =A0

Then= , I would suggest revising RFC 8088 and specifically section 7.4.=C2=A0 (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.)

=C2= =A0

Step= han

=C2= =A0

=C2= =A0

From: avt <avt-bounces@ietf.or= g> on behalf of Bernard Aboba <bernard.aboba@gmail.com>
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=

=C2=A0

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/):=C2=A0

=C2=A0

However, the=C2=A0IANA mime-types registry (see =E2=80=9Cvideo=E2=80=9D) is more complete, i= ncluding entries for the missing codecs: https://www.iana.org/assignments/media-types/med= ia-types.xhtml

=C2=A0

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.=C2=A0 =C2=A0Jonathan and I took the action item= to consult with IANA to explore ways we could address the divergence.=C2= =A0

=C2=A0

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.=C2=A0

=C2=A0

Notes

--------

=C2=A0

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.=C2=A0=

=C2=A0

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.=C2=A0 VP9 was = registered in both registries.=C2=A0

=C2=A0

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.=C2=A0

=C2=A0

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.=C2=A0It was registered only in the MIME-type registry.=C2=A0

=C2=A0

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=C2=A0) It was registered only in the MIME-type registry.=C2=A0

=C2=A0

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.=C2=A0 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?=C2=A0<= /p>

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt
--0000000000000362df060747792a--