[Cellar] IANA Considerations for EBML
Michael Richardson <mcr+ietf@sandelman.ca> Thu, 07 June 2018 01:54 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 633A113107D for <cellar@ietfa.amsl.com>; Wed, 6 Jun 2018 18:54:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 au3_HaJUrys8 for <cellar@ietfa.amsl.com>; Wed, 6 Jun 2018 18:54:31 -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 5DD2F130E16 for <cellar@ietf.org>; Wed, 6 Jun 2018 18:54:31 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9C0E120090 for <cellar@ietf.org>; Wed, 6 Jun 2018 22:07:58 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id A3A1925C3; Wed, 6 Jun 2018 21:53:54 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A13D574 for <cellar@ietf.org>; Wed, 6 Jun 2018 21:53:54 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: cellar@ietf.org
X-Attribution: mcr
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: Wed, 06 Jun 2018 21:53:54 -0400
Message-ID: <15361.1528336434@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/k-77-POOqdQRv0TUGe_TusfwG2o>
Subject: [Cellar] IANA Considerations for EBML
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.26
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: Thu, 07 Jun 2018 01:54:35 -0000
I've made a pull request, https://github.com/Matroska-Org/ebml-specification/pull/179 but I include the text here so that we can discuss it on the list. I havne't gotten the references done correctly for mmark, so don't worry about that for now. Note: "Specification Required" does not imply IETF specification. It could be any SDO, and many other entities that might publish things. First Come/First Served requires no document at all... just ask IANA. RFC Required does not imply standards track. see https://tools.ietf.org/html/rfc8126 # IANA Considerations This document creates a new IANA Registry called "CELLAR EBML Element ID Registry". Element IDs are described in section {{#element-id}}. Element IDs are encoded using the VINT mechanism described in section {{#variable-sized-integer}} can be between one and five bytes long. Five byte long Element IDs are possible only if declared in the header. One byte Element IDs are numbers between 1 and 126. These items are valuable because they short, and need to be used for commonly repeated elements. Values from 1 to 126 are to be allocated according to RFC Required. Two byte Element IDs are numbers between 127 and 16382. Numbers may be allocated within this range according to Specification Required. Three byte Element IDs are numbers between 16383 and 2097150. Numbers may be allocated within this range according to First Come First Served. Four byte Element IDs are numbers between 2097151 and 268435456. Four byte Element IDs are somewhat special in that they are useful for resynchronizing to major structures in the event of data corruption or loss. As such four byte Element IDs are split into two categories. Four byte Element IDs whose lower three bytes (as encoded) would make printable 7-bit ASCII values may be allocated only Specification Required. Sequential allocation of values is not required: specifications SHOULD include a specific request, and are encouraged to do early allocations. To be clear about the above category: Four Byte Element IDs always start with hex 0x10 to 0x1F, and that byte may be chosen so that the entire number has some desirable property, such as a specific CRC. The other three bytes, when ALL having values between 33 (ASCII !) and 126 (ASCII ~), fall into this catgory. Other Four Byte Element IDs may be allocated by First Come First Served. Five Byte Element IDs (values from 268435457 upwards) are reserved for Experimental use. -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
- 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