[Cellar] CodecIDs for non-standard and unregistered data formats

Matt Gruenke <matt.gruenke@gmail.com> Tue, 14 February 2017 06:46 UTC

Return-Path: <matt.gruenke@gmail.com>
X-Original-To: cellar@ietfa.amsl.com
Delivered-To: cellar@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A4212947A for <cellar@ietfa.amsl.com>; Mon, 13 Feb 2017 22:46:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7KA0C3OsffQ for <cellar@ietfa.amsl.com>; Mon, 13 Feb 2017 22:46:54 -0800 (PST)
Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E88F12940E for <cellar@ietf.org>; Mon, 13 Feb 2017 22:46:53 -0800 (PST)
Received: by mail-vk0-x230.google.com with SMTP id k127so74689006vke.0 for <cellar@ietf.org>; Mon, 13 Feb 2017 22:46:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Empa3go30k2SEFhXN+953ACNL0pLjwPmrTEMc+U5t1U=; b=UVWRt2Ly9YWXYAV+GqCfMzQbOqdnEdlkjbJFpoCALL7q+wHuTZGnJcN2fdwzA/wLmh VwbySdC6KiTXAmWPfY7goK5AkJzPz6Ek8zNhpWGFUjIrhwrpuvsiw8iS1omixf4fMkiC z9PCbfc7jfi7t+4hKbRpjoJZ3sFc7i43PHCMdbYkyAFPbSpH6PkT2wonuqOJKSuxxso6 UrnTrEqRVk6Xpdpk/shPb6tcfbqgFdbac+0/W4BvjQe2Gvy8AMdNreYs8YpTU1OF2ue/ QtLaIHp3yRJfcycQuIfWHB7+MHYVlm5HaR+dcg4nPglr/BhqD359wW3Gi0LbBz4ofTwa eUmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Empa3go30k2SEFhXN+953ACNL0pLjwPmrTEMc+U5t1U=; b=jt7zwIGiWshyMxMMybcqWW34DcdxDD3vNrLBi1Cp5zIuW7sK3mCfM9oJLU5STXW5eT hA5qC7CrJIxbovvUHCfdh9kYa1oz+7sC0BsxAbcAaDh6/22G3VujhqgvKRIekhh9M8oE OD3T84S/7bl7VFQBbqLaS9w73q/SejWTKrTU+/z6dfXO06Ru/mcHs75cwkXA7A9ilMoZ i3I8Bs05Z0TGTrpEfoDMBhRO9/k3EUlHq0c/5pf+2GO1Nz29t+MGnM/YIvLF/knLTH3u Ibn4lMsFJp2jF/XSG4yvBMuF8xcagGHmXgdjasltJsxQUlhpLMHoKqDHDznC+mQKFvJ1 cMNA==
X-Gm-Message-State: AMke39n8qQAyFah6xgyVMvw2oFYIVuOwobIih1XOhzj+sxO+S1xtsFpRI+yIq8pOpAIJcvoFkP7ndwr94oajWw==
X-Received: by 10.31.58.215 with SMTP id h206mr11642747vka.164.1487054812887; Mon, 13 Feb 2017 22:46:52 -0800 (PST)
MIME-Version: 1.0
Received: by 10.31.102.196 with HTTP; Mon, 13 Feb 2017 22:46:52 -0800 (PST)
From: Matt Gruenke <matt.gruenke@gmail.com>
Date: Tue, 14 Feb 2017 01:46:52 -0500
Message-ID: <CAJKCwWj2rZu0OWksLiTvT9E4jjiN6XOHzYGSuUaRbtiXxnbCDQ@mail.gmail.com>
To: cellar@ietf.org
Content-Type: multipart/alternative; boundary="001a114407d4e24275054877edae"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/NizT2Pq_07oHzp5U_SqVo4xlnEs>
Subject: [Cellar] CodecIDs for non-standard and unregistered data formats
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Codec Encoding for LossLess Archiving and Realtime transmission <cellar.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cellar>, <mailto:cellar-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cellar/>
List-Post: <mailto:cellar@ietf.org>
List-Help: <mailto:cellar-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cellar>, <mailto:cellar-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Feb 2017 06:46:55 -0000

Related to my recent query about TrackTypes for non-standard data formats,
I'd like to discuss CodecIDs.  I had previously raised this issue, on the
matroska-devel list, and was advised to take it up, here.  In the interim,
my thinking on the matter has evolved.

I wonder why not allow IANA Media Types (aka MIME types), as a sub-class of
CodecIDs?  Of course, the official Matroska CodecID would be preferred, for
all formats for which one has been designated.  However, this would enable
broader use of Matroska files, including for private, application-specific
data stream formats.

Perhaps a prefix like 'X_MEDIATYPE/' could simply be prepended to media
type names conforming with RFC 6838.  The value of TrackType would still
determine whether video, audio, or any other type-specific elements can be
used in such tracks.

Thank you for considering my suggestion.


Matt