Re: [Cellar] IANA Considerations for EBML
Steve Lhomme <slhomme@matroska.org> Tue, 28 August 2018 19:06 UTC
Return-Path: <slhomme@matroska.org>
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 9F888130EC9 for <cellar@ietfa.amsl.com>; Tue, 28 Aug 2018 12:06:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.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 Wm1LEQ1JuLV3 for <cellar@ietfa.amsl.com>; Tue, 28 Aug 2018 12:06:51 -0700 (PDT)
Received: from mail-pg1-x542.google.com (mail-pg1-x542.google.com [IPv6:2607:f8b0:4864:20::542]) (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 D8F29127148 for <cellar@ietf.org>; Tue, 28 Aug 2018 12:06:51 -0700 (PDT)
Received: by mail-pg1-x542.google.com with SMTP id y4-v6so1159834pgp.9 for <cellar@ietf.org>; Tue, 28 Aug 2018 12:06:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=ESKTpltcPM4AmFD8zS5qaJakxBrcrk/aLhlfbYdKZmE=; b=cKlgoQT3DgEfCGCRn0/Z/U9BFioiwEz+pUA1tH46CR+S7UqgbGOdbNNJer5tnaDMD1 psK5gkgN4Yb6aolxBT1HTwhPZ60Cg6R2Gy/VARtZ0GwcePpSNwWk2BVsCkupEExpm4o/ iLUxmqJO56ihtlgWplOnmXSXfGY+3ES8oEWzF4pj2U3zEf+iLpLDjb6oOy74i/DZOVKv kKxOHJ8VNph00j6VhqFr8NFgVOw6OZsITASRAbPQMd60hXrKddi7kVR/87qAL2E+TPZt JWK5Je0sOTbw+utZKr9QmczU3CRxXIs8czZgrrCMOWmjO/4FSRKyrsCBUtGZ6oANeId0 cOrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=ESKTpltcPM4AmFD8zS5qaJakxBrcrk/aLhlfbYdKZmE=; b=b1TQD/mGVe2iKEHHgxcaCMuC7zRf+oPNmrGDf5ZdKfETTAsd2wkds1U7DhveEPPy02 kdqagNacbUUWjLBRhF/wM8SOxJAh3d2nQyMOrRB1NRP1xXtY+1vA+l/nu/yDyzpYOoxe Rz4fPAmFpNK1psjm6FsQaGF0UcyImm72vu/oZvySyvm/C+SJjcuYcVCvUoVv+Lhv3FGq VrFnyRx53+0c9CBxRk6UAQnGY/r6lK8h6xNEzkoOfsbdkuf1lREoOrWrbJWqQo/xQbRQ FcE5xQSA0Hd4RxWaQPLdQfYHweau7G+4DXHc64dSpwhfcSt/sSwEyc8rQvVAS8a/2A3p QiDQ==
X-Gm-Message-State: APzg51A36nMNoPfJyS9MVzzsqzfuUm6kat88T+yk/DUPNYa62pKWiiUR yGTnoy7qoYexSErChxQ4XpjgipZweFsBFBPaG3Jmr/Q3
X-Google-Smtp-Source: ANB0Vdb3cJC/QuykXnWvOgDguIM6S2kUR8kyrBk7JRTUIrpM37m2U81XhFrmREHaqWnrXmzMXaMpkUaxo2iQPmAdKlQ=
X-Received: by 2002:a63:5c5e:: with SMTP id n30-v6mr2721161pgm.253.1535483211067; Tue, 28 Aug 2018 12:06:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a17:90a:9c13:0:0:0:0 with HTTP; Tue, 28 Aug 2018 12:06:50 -0700 (PDT)
In-Reply-To: <3970.1531804177@localhost>
References: <15361.1528336434@localhost> <CAOXsMFLO70MAZ62OBwZEZh+rxihXh5u58P0VAB7yN0DuZB2bDQ@mail.gmail.com> <B09596BD-6B83-4DF0-8DD6-E74CEC6AA52F@dericed.com> <3970.1531804177@localhost>
From: Steve Lhomme <slhomme@matroska.org>
Date: Tue, 28 Aug 2018 21:06:50 +0200
Message-ID: <CAOXsMFLbNPfqPAZzcqLWd9cdyAoLdRD3+9z4jVvexT12KJfJXg@mail.gmail.com>
To: Codec Encoding for LossLess Archiving and Realtime transmission <cellar@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/qRgec7pHdj1pf0zHVX5c8ZhUTcw>
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, 28 Aug 2018 19:06:54 -0000
2018-07-17 7:09 GMT+02:00 Michael Richardson <mcr+ietf@sandelman.ca>: > > 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. Yes but Class A (1 octet) elements are rare and the most likely to be used for each EBML-based format. Matroska uses a lot of them. That will leave almost none left for the other formats. > > 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 [ > -- Steve Lhomme Matroska association Chairman
- Re: [Cellar] IANA Considerations for EBML Steve Lhomme
- [Cellar] IANA Considerations for EBML Michael Richardson
- Re: [Cellar] IANA Considerations for EBML Dave Rice
- Re: [Cellar] IANA Considerations for EBML Michael Richardson
- Re: [Cellar] IANA Considerations for EBML Steve Lhomme
- Re: [Cellar] IANA Considerations for EBML Michael Richardson
- Re: [Cellar] IANA Considerations for EBML Moritz Bunkus