Re: [Cellar] ATRAC1 codec ID for Matroska

[Michael Richardson <[e-mail]>]

Steve Lhomme <[e-mail]> wrote:
    > On 2022-10-07 10:17, Michael Richardson wrote:
    >> On Mon 3 Oct 2022 at 18:55, Sir68k <[e-mail]> wrote:
    >>> As RAW ATRAC1 isn't common but may become (slightly) more common due
    >>> to the ripping software that we have been creating, we would like to
    >>> start using a decent container format. Matroska already has support
    >>> for ATRAC3 as a format (A_REAL/ATRC), and as such, we would like to
    >>> request a new codec ID for ATRAC1 as well.
    >> As I understand it, you want a new entry in:
    >> https://www.ietf.org/archive/id/draft-ietf-cellar-codec-09.html#name-audio-codec-mappings
    >> or:
    >> https://www.ietf.org/archive/id/draft-ietf-cellar-matroska-14.html#name-chapter-codec-ids-registry
    >> In reviewing this, I'm actually a bit lost, as I thought that the IANA
    >> considerations on Matroska was complete, but now it looks rather
    >> incomplete.

    > For the Matroska document, yes. For codecs we will also need a
    > registry. There's a section about that in the document:

    > 8. IANA Considerations

> To be determined.

My face is red having missed this in my review.

    >> At this point, the document is not published, so the IANA process to
    >> allocate you an ID is not live.  But, as a WG, we can add your request
    >> to the document.

    > Do we have to move this registry declaration in the Matroska document ?
    > Same thing with the Tag Names which will need their own registry.

We don't have to move the list.  We can, in the IANA Considerations ask IANA
to insert the contents of section XYZ into the initial registry.

    >> I don't see ATRAC3 in the document, but maybe I'm looking in the wrong
    >> place.

    > Indeed, it's missing. That document may not be exhaustive for all the
    > existing codecs in the wild.

    >> Please, could the WG clarify where the right registry would be?

Let's talk about what the IANA Considerations are for adding items.
I think that probably Specifications Required would be fine.

(Requires *a* document, but not necessarily an RFC.  Note that if published
outside of the IETF, or just as a web page somewhere, that it might have
significant IPR claims.  That would be fine)

Or, it could be Expert Review, if we want to accept that some codecs might
not be publically documented.

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide