Re: [Cellar] IANA Considerations for EBML

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 17 July 2018 05:14 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 A462D130F1F for <cellar@ietfa.amsl.com>; Mon, 16 Jul 2018 22:14:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 pwbpps3NUIKY for <cellar@ietfa.amsl.com>; Mon, 16 Jul 2018 22:14:11 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C65B130F13 for <cellar@ietf.org>; Mon, 16 Jul 2018 22:14:11 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 48F742008C; Tue, 17 Jul 2018 01:29:53 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 2D25C2686; Tue, 17 Jul 2018 01:09:37 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 2AF1A267E; Tue, 17 Jul 2018 01:09:37 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Dave Rice <dave@dericed.com>
cc: Steve Lhomme <slhomme@matroska.org>, Codec Encoding for LossLess Archiving and Realtime transmission <cellar@ietf.org>
In-Reply-To: <B09596BD-6B83-4DF0-8DD6-E74CEC6AA52F@dericed.com>
References: <15361.1528336434@localhost> <CAOXsMFLO70MAZ62OBwZEZh+rxihXh5u58P0VAB7yN0DuZB2bDQ@mail.gmail.com> <B09596BD-6B83-4DF0-8DD6-E74CEC6AA52F@dericed.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Tue, 17 Jul 2018 01:09:37 -0400
Message-ID: <3970.1531804177@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/m_AXxOjRNTTVyKGLJVaP_Q_oPK8>
Subject: Re: [Cellar] IANA Considerations for EBML
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.27
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, 17 Jul 2018 05:14:14 -0000

Dave Rice <dave@dericed.com> wrote:
    > I might be mistaken here, but from the draft the process of
    > registering an Element ID via IANA only seems interested in the
    > Element ID itself. For a curious onlooker of the IANA registrations it
    > might be helpful to see what the associated DocType is so that the
    > context and semantics could be understood, otherwise the registration
    > only seems to indicate that somewhere someone registered it via
    > first-come first-serve.

I've been reading ebml more deeply in the last two weeks, and I actually have
significant concerns.  I don't really understand what is going on.

We have a virtual interim on the 31st, and I'd like to discuss this
in person, perhaps. Earlier 1:1 if you think you could help me.

In particular, I have no idea what the binary format of EBML even is!
I thought I'd just missed the description before...

    > Additionally I think I’d prefer (except for the IDs used by EBML
    > itself) that the combination of DocType and ElementID be required as
    > unique rather than only the ElementID itself. This seems analogous to
    > how the same node name is allowed in various XML Schemas but don’t
    > necessarily have any relation to one another in semantics.

That's a choice.
Given 2^35 ElementIDs, I don't see why you'd want to complicate your life
that way. 

    > Is it acceptable to extend the IANA Considerations section to clarify
    > the required information for registrations? From the discussion in the
    > pull request these scenarios seem to be:

If you want to make the ElementID a function of DocType, then put all the
ElementID allocations into the document that defines that DocType.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [