Re: [AVTCORE] Fwd: RTP payload format type registry vs. MIME-type registry

[Magnus Westerlund <[e-mail]>]

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 Payload formats. Already prior to RFC 8088 was written we had discussion about this registry and if we should kill it. We didn’t 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.

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 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 <[e-mail]>
Date: Wednesday, 4 October 2023 at 15:43
To: Bernard Aboba <[e-mail]>, IETF AVTCore WG <[e-mail]>
Cc: Harald Alvestrand <[e-mail]>, Magnus Westerlund <[e-mail]>
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’m an arguably experienced payload format author, but know little about IANA mechanics, and care even less.  I’m sure I’m not alone 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’t know who can provide that guidance, but frankly, I don’t believe AVTcore is the right group to provide it, simply because we didn’t get it right so many times in the past.   I also don’t think we can rely on guidance by the IESG or the media type review people without specifically asking.  They didn’t spot problems 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 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.

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 <[e-mail]> on behalf of Bernard Aboba <[e-mail]>
Date: Tuesday, October 3, 2023 at 16:59
To: IETF AVTCore WG <[e-mail]>
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://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-db3c9ccec786cf77&q=1&e=bcb5dc8f-c55e-46ea-a97e-9f83e105e745&u=https%3A%2F%2Faomediacodec.github.io%2Fav1-rtp-spec%2F>):
https://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-parameters-2

However, the IANA mime-types registry (see “video”) is more 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 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 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<https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-0fe18ba921df50fe&q=1&e=bcb5dc8f-c55e-46ea-a97e-9f83e105e745&u=https%3A%2F%2Faomediacodec.github.io%2Fav1-rtp-spec%2F%2371-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 Section 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 indicate that it should be registered in both the RTP payload format and MIME-type registries?