From nobody Wed Oct 2 09:05:06 2019 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E62A120169 for ; Wed, 2 Oct 2019 09:05:04 -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_HELO_NONE=0.001, 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 W9yHztv9Ash7 for ; Wed, 2 Oct 2019 09:05:02 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E8BC120147 for ; Wed, 2 Oct 2019 09:05:01 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 38FEA3897A for ; Wed, 2 Oct 2019 12:02:58 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B6AFD4F4 for ; Wed, 2 Oct 2019 12:05:00 -0400 (EDT) From: Michael Richardson To: tools-discuss@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 Archived-At: Subject: [Tools-discuss] webex stopped working... X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2019 16:05:04 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable This morning I failed to connect to two IETF meetings with webex's webrtc From=20a Linux desktop. I used both chrome and firefox. In each case, aft= er the name/email page, it just got stuck loading, giving me a blank page. This was on ietf.webex.com and cisco.webex.com. (I dialed in to listen) It used to work great. Yes, I restarted browsers. Has anyone experienced this problem? =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl2UyqsACgkQgItw+93Q 3WWxmQgAog7viD4Zj2hVkxjWgYZQeEWOuEv6gEfuyfAXSMWJYcOKETAUqf/3f7v+ OJx793j5cu19+soBGFsir6O5WPxW6r5zBwz+ZbNb796m5jMq0wNKfdx+ot0BTnlp 8D7ZuiFKyRiwYpuHgFmC8zCzMsAwo5NMvRRGu5OMoGkZXt/fPz2IB1Te3USVUozM 3x5aMUc5OTIidAQwax1ESA9bL+u7Phs3ZjkyJh+55rjZOB9ZJEgUhCZ52Dle5Hud ptsgkXXfQd9FmtmevJanHosgvJRFguSC36wcGfd5rdaWh4n7odjcTp43NqiJIq2M F4J/kQodgM23RB5CyqFWfoP32juIGg== =VO7S -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Oct 2 13:47:59 2019 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B26612004D for ; Wed, 2 Oct 2019 13:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 EGvtYg9kzfRm for ; Wed, 2 Oct 2019 13:47:56 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DF3612004C for ; Wed, 2 Oct 2019 13:47:56 -0700 (PDT) Received: from [192.168.34.217] (h-164-71.A137.corp.bahnhof.se [37.123.164.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46k7WG5FcNzyny; Wed, 2 Oct 2019 22:47:54 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <3291.1570032300@localhost> Date: Wed, 2 Oct 2019 22:47:54 +0200 Cc: tools-discuss@ietf.org X-Mao-Original-Outgoing-Id: 591742072.2532001-15f78fbd929a0c4e1200c298bf636878 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3291.1570032300@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Tools-discuss] webex stopped working... X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2019 20:47:58 -0000 Hi Michael, I=E2=80=99m not aware of anybody else who had trouble in our VI today. I think most people are using the application (which is disguised as a = browser plugin) and not the WebRTC variant though, so that may not be = very indicative. Gr=C3=BC=C3=9Fe, Carsten > On Oct 2, 2019, at 18:05, Michael Richardson wrote: >=20 > Signed PGP part >=20 > This morning I failed to connect to two IETF meetings with webex's = webrtc > =46rom a Linux desktop. I used both chrome and firefox. In each = case, after > the name/email page, it just got stuck loading, giving me a blank = page. > This was on ietf.webex.com and cisco.webex.com. > (I dialed in to listen) >=20 > It used to work great. > Yes, I restarted browsers. >=20 > Has anyone experienced this problem? >=20 > -- > ] Never tell me the odds! | ipv6 mesh = networks [ > ] Michael Richardson, Sandelman Software Works | IoT = architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on = rails [ >=20 >=20 >=20 >=20 From nobody Wed Oct 2 14:26:49 2019 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E052120043 for ; Wed, 2 Oct 2019 14:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=xo6w8AWC; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=uglgyF3P 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 HeMK8GNy1ynF for ; Wed, 2 Oct 2019 14:26:46 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC19B12002F for ; Wed, 2 Oct 2019 14:26:45 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1570051605; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=BORHvOClG8pOzl9Pk/+zPnY5+pDIvDjx0lDFKv8DYqI=; b=xo6w8AWCc6LgQDIhda53911RQhiGTP/T0myKf4KGdBd8st0739RxWTCj dBqCECADCuYh2BYO+qrQnL6Ps18jCA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1570051605; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=BORHvOClG8pOzl9Pk/+zPnY5+pDIvDjx0lDFKv8DYqI=; b=uglgyF3P2HlsbTLZ2lxSGx2471XpqQaOj54Rhq1E/rc4hsgM3Z6+v6w5 7yEuxPhT+leed8ktB4F3NRmBv8KuJTtDGtAoWXWmGygXPapwKSUQS/+8L1 H1YkFM2QcpXVk6sG/gCV1AKiSeIbgR3+m7iaWmq/zMNwf+KhndEcfP7j7m JhK4NpG6Oi/GfRelGv8aiOKkdFAfnRz2LXHMQXiCjcgvtaYY5+bYg0bDYM q8+YkQ55+ESw8Ao6soDQ5I2l/TOs7OQQ0o0S8vJgabMsJ4q4oCaQf3xW+W WgCiZZARPPY8tFCwDBABifATcHwqzRZpqQB3NJP8DP/T1sgkWpw8zw== Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 07F20F9A7; Wed, 2 Oct 2019 17:26:44 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id E031220466; Wed, 2 Oct 2019 16:54:32 -0400 (EDT) From: Daniel Kahn Gillmor To: Henrik Levkowetz , tools-discuss@ietf.org In-Reply-To: <20e45f26-b1df-d1b4-15b6-8ad1ce2df151@levkowetz.com> References: <87zhip26qa.fsf@fifthhorseman.net> <20e45f26-b1df-d1b4-15b6-8ad1ce2df151@levkowetz.com> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Wed, 02 Oct 2019 16:54:32 -0400 Message-ID: <87o8yyx3zr.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [Tools-discuss] rfcmarkup revision control repository? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2019 21:26:48 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon 2019-09-30 17:09:26 +0200, Henrik Levkowetz wrote: > There is a repository at > > https://svn.tools.ietf.org/svn/src/rfcmarkup/, > > but I would like to point at the repository for the packaged htmlizer > code which I've extracted from the rfcmarkup code, instead:=20 > > https://svn.tools.ietf.org/svn/src/rfc2html/ > > That's where I expect to do any new development, and that's the code > being used by the rfc-editor and datatracker sites for their htmlized > document pages. > > I expect to eventually re-write rfcmarkup on tools.ietf.org to just use > the rfc2html module, too. Gotcha. I see you mentioned this in an e-mail back in November 2018 as well, though the code has moved into trunk/ since then. I've now cloned this repo with git-svn so i can keep track of it. Thanks for your work on this part of the IETF document archive. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXZUOiAAKCRB2GBllKa5f +NvRAP4hXnThlB0PxKZU+44dPmE1lIUljJB9SxNHHpwW6XWVjQD+KO1C8CcDzESJ dCTWErdrFinDaZHeMEqHltvzYJIgvwc= =VeP7 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Oct 2 14:33:27 2019 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67447120043 for ; Wed, 2 Oct 2019 14:33:25 -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_HELO_NONE=0.001, 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 Qy4h2WZqp5n1 for ; Wed, 2 Oct 2019 14:33:23 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A49AF12002F for ; Wed, 2 Oct 2019 14:33:23 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 054D13897A; Wed, 2 Oct 2019 17:31:20 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D8AF2529; Wed, 2 Oct 2019 17:33:22 -0400 (EDT) From: Michael Richardson To: Carsten Bormann cc: tools-discuss@ietf.org In-Reply-To: References: <3291.1570032300@localhost> 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 Archived-At: Subject: Re: [Tools-discuss] webex stopped working... X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2019 21:33:26 -0000 Carsten Bormann wrote: > I=E2=80=99m not aware of anybody else who had trouble in our VI today. > I think most people are using the application (which is disguised as a > browser plugin) and not the WebRTC variant though, so that may not be > very indicative. Yes, the JAVA/JWS version, which would run fine on Linux for viewing screen (but not audio, for reasons of poor programming), except that cisco has marked it as incompatible. -- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ From nobody Mon Oct 7 13:10:54 2019 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24AEF120046; Mon, 7 Oct 2019 13:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 kQI59kONKj8J; Mon, 7 Oct 2019 13:10:37 -0700 (PDT) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 56860120020; Mon, 7 Oct 2019 13:10:37 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id m61so10016588qte.7; Mon, 07 Oct 2019 13:10:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eZo5HwR0jXmeiTLII8i0mADScha/E3FoOXPDFX55NEA=; b=QlWYTAhGr62D8Rb4anrXxKyFyyX8NLwhcsInAQaNgkcOtL4+hF37d1ca2QPUFYNxxw Lrf+SxWBxI6O4P/h5kIp/fd4U7+sEZtTuacbcGPpOF7hdz/CFtAM6J+ZpPSNEfzd7vUZ r9fSeS7UACNV+AgQIQH9MdeHEHsW3DNzv0OwHCr+53CSQNT1E0SDQRBFzZepgnom2wSh vDVp26VS2MZ/rrMEle9ANXiqfuKFb1CFUB2aI9kj1LLydP4IR11Rf4gt1HAmO54jdp9S E8nuzVp7qSIvSTIVE9Jb20LjUO6IuWy4P0+vMKKVRXE5WobF1k3HUz4iJkD1Yb5kf5i7 +cGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eZo5HwR0jXmeiTLII8i0mADScha/E3FoOXPDFX55NEA=; b=h10vgyZlOIqOBBIArRFXpA4Ymvvg80GWQjSC9Byv0JBhUJrAxaiIEoCpb2NiRISDVf ibip6JSBPedmnh7vgRH++xCn369IXZIuEWedpcvMTdrj40fi5Sk/2y6W5Gwcht6MKpGq de10bLJZrc+ewxNC41KQaphYZj7xucWrJCGAZ2pa8RXSdEwQ7K8COicknMPZZ/gT8ujJ 7HQZttVjkxLM1i2+I3tcP3g+Xl0H3HJoiiZaSU+cLhq6FNmFptKpcXMpasPoPCH94zpB SHvogFdBfumcRYb9p7GnTuYGIIQ71Au6D/Mtkvdbbex5ZzeOsZUgiZCyrKW648yOcw+S etQw== X-Gm-Message-State: APjAAAWWzw/IBYa1e7YXrrHaABk0CWywcaP4/HKV5oTTjNoYdq2YU9vk lgKqHEfMsBpnkeGjii0eG99l6jRtk7r/MGA3BgmBmQ== X-Google-Smtp-Source: APXvYqzfen9c8B6Q7t+QQI7GJyQvAD9MG8CN2u4QOEaRBBdWLyjTKnQ8ZMKPvCBtGIkCN93E0UXGWIO7ltTBLpXjkps= X-Received: by 2002:ac8:33d3:: with SMTP id d19mr31675361qtb.60.1570479036260; Mon, 07 Oct 2019 13:10:36 -0700 (PDT) MIME-Version: 1.0 References: <20191007195852.11BD7B800CB@rfc-editor.org> In-Reply-To: From: "Andrew G. Malis" Date: Mon, 7 Oct 2019 16:10:25 -0400 Message-ID: To: Heather Flanagan , tools-discuss Cc: IETF discussion list , RFC Interest , RSOC , Internet Architecture Board Content-Type: multipart/alternative; boundary="00000000000015661a059457a5a2" Archived-At: Subject: Re: [Tools-discuss] [rfc-i] First v3 RFC is published - RFC 8651 on Dynamic Link Exchange Protocol (DLEP) Control-Plane-Based Pause Extension X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2019 20:10:40 -0000 --00000000000015661a059457a5a2 Content-Type: text/plain; charset="UTF-8" Heather, Congratulations! And a request ... probably not for you, but for the tools team (added to the to: list). The Datatracker has a pointer to the htmlized version from the tools site, but not the HTML version from the rfc-editor site ... can that be added? Thanks, Andy On Mon, Oct 7, 2019 at 4:00 PM Heather Flanagan wrote: > Wow, everyone. We did it! > > Thank you all for years and years of effort in getting us to this point. > RFC 8651 is now the first RFC to be published in the v3 format. > > As those of you on the xml2rfc list know, there are still heated > discussions underway about some aspects of the XML vocabulary. Getting the > -bis documents out to capture the reality of the v3 format is critically > important. That is in the top 3 priorities for me as I wrap up my time as > RSE (the other two are operational transition items and the RFC Model > process discussion). > > I particularly want to thank the RPC staff. They have worked incredibly > hard to fill the roles of expert copyeditors, quality assurance engineers, > and key stakeholders throughout the seven years (and counting) of the RFC > format project. This is an amazing team. Thank you. > > Heather Flanagan, RSE > > Begin forwarded message: > > *From: *rfc-editor@rfc-editor.org > *Subject: **RFC 8651 on Dynamic Link Exchange Protocol (DLEP) > Control-Plane-Based Pause Extension* > *Date: *October 7, 2019 at 12:58:52 PM PDT > *To: *ietf-announce@ietf.org, rfc-dist@rfc-editor.org > *Cc: *rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, > manet@ietf.org > > A new Request for Comments is now available in online RFC libraries. > > > RFC 8651 > > Title: Dynamic Link Exchange Protocol (DLEP) > Control-Plane-Based Pause Extension > Author: B. Cheng, > D. Wiggins, > L. Berger, Ed. > Status: Standards Track > Stream: IETF > Date: October 2019 > Mailbox: bcheng@ll.mit.edu, > david.wiggins@ll.mit.edu, > lberger@labn.net > Pages: 12 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-manet-dlep-pause-extension-08.txt > > URL: https://www.rfc-editor.org/info/rfc8651 > > DOI: 10.17487/RFC8651 > > This document defines an extension to the Dynamic Link Exchange > Protocol (DLEP) that enables a modem to use DLEP messages to pause > and resume data traffic coming from its peer router. > > This document is a product of the Mobile Ad-hoc Networks Working Group of > the IETF. > > This is now a Proposed Standard. > > STANDARDS TRACK: This document specifies an Internet Standards Track > protocol for the Internet community, and requests discussion and > suggestions > for improvements. Please refer to the current edition of the Official > Internet Protocol Standards (https://www.rfc-editor.org/standards) for > the > standardization state and status of this protocol. Distribution of this > memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > https://www.ietf.org/mailman/listinfo/ietf-announce > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see https://www.rfc-editor.org/search > For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > > > _______________________________________________ > rfc-interest mailing list > rfc-interest@rfc-editor.org > https://www.rfc-editor.org/mailman/listinfo/rfc-interest > --00000000000015661a059457a5a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Heather,

Congratulations!
And a request ... probably=C2=A0not for you, but for the tools = team (added to the to: list). The Datatracker has a pointer to the htmlized= version from the tools site, but not the HTML version from the rfc-editor = site ... can that be added?

Thanks,
Andy=


On Mon, Oct 7, 2019 at 4:00 PM Heather Flanagan <rse@rfc-editor.org> wrote:
Wow, everyone. We did it!

Thank you all for years and years of effort in getting us to this point. = RFC 8651 is now the first RFC to be published in the v3 format.
<= br>
As those of you on the xml2rfc list know, there are still hea= ted discussions underway about some aspects of the XML vocabulary. Getting = the -bis documents out to capture the reality of the v3 format is criticall= y important. That is in the top 3 priorities for me as I wrap up my time as= RSE (the other two are operational transition items and the RFC Model proc= ess discussion).

I particularly want to thank the = RPC staff. They have worked incredibly hard to fill the roles of expert cop= yeditors, quality assurance engineers, and key stakeholders throughout the = seven years (and counting) of the RFC format project. This is an amazing te= am. Thank you.

Heather Flanagan, RSE
Begin forwarded message:

Subject: RFC 8651 on Dynamic Link Exchange Protocol (DLEP) Control-P= lane-Based Pause Extension
= Cc: rfc-editor= @rfc-editor.org, drafts-update-ref@iana.org, manet@ietf.org

A new= Request for Comments is now available in online RFC libraries.


= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0RFC 8651

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0Title: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Dynamic Lin= k Exchange Protocol (DLEP)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Con= trol-Plane-Based Pause Extension
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0Author: =C2=A0=C2=A0=C2=A0=C2=A0B. Cheng,
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0D. Wiggins,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= L. Berger, Ed.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Status: =C2=A0= =C2=A0=C2=A0=C2=A0Standards Track
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0Stream: =C2=A0=C2=A0=C2=A0=C2=A0IETF
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0Date: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0October 2019
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Mailbox: =C2=A0=C2=A0=C2=A0bcheng@ll.mit.edu, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0david.wiggins@ll.mit.edu,
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0lberger@labn.net
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0Pages: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A012
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0Updates/Obsoletes/SeeAlso: =C2=A0=C2=A0None

=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0I-D Tag: =C2=A0=C2=A0=C2=A0draft-ietf-m= anet-dlep-pause-extension-08.txt

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0URL: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.rfc-editor.o= rg/info/rfc8651

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0DOI: = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A010.17487/RFC8651

This docu= ment defines an extension to the Dynamic Link Exchange
Protocol (DLEP) t= hat enables a modem to use DLEP messages to pause
and resume data traffi= c coming from its peer router.

This document is a product of the Mob= ile Ad-hoc Networks Working Group of the IETF.

This is now a Propose= d Standard.

STANDARDS TRACK: This document specifies an Internet Sta= ndards Track
protocol for the Internet community, and requests discussio= n and suggestions
for improvements.=C2=A0 Please refer to the current ed= ition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/st= andards) for the
standardization state and status of this protocol.= =C2=A0 Distribution of this
memo is unlimited.

This announcement= is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubs= cribe, see
=C2=A0https://www.ietf.org/mailman/listinfo/ietf-anno= unce
=C2=A0https://mailman.rfc-editor.org/mailman/listi= nfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/s= earch
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk=

Requests for special distribution should be addressed to either= the
author of the RFC in question, or to rfc-editor@rfc-editor.org.=C2=A0 Unles= s
specifically noted otherwise on the RFC itself, all RFCs are for
un= limited distribution.


The RFC Editor Team
Association Managem= ent Solutions, LLC



____= ___________________________________________
rfc-interest mailing list
rfc-intere= st@rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/= rfc-interest
--00000000000015661a059457a5a2-- From nobody Mon Oct 7 13:13:23 2019 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0741208F6 for ; Mon, 7 Oct 2019 13:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 PZD9WHotCRQw for ; Mon, 7 Oct 2019 13:13:13 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A4571201EA for ; Mon, 7 Oct 2019 13:13:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id CEEAA203426; Mon, 7 Oct 2019 13:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waKmx3J_wYSE; Mon, 7 Oct 2019 13:12:02 -0700 (PDT) Received: from [64.170.98.190] (unknown [64.170.98.190]) by c8a.amsl.com (Postfix) with ESMTPSA id 87870203423; Mon, 7 Oct 2019 13:12:02 -0700 (PDT) From: Heather Flanagan Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_12D3D8B8-2B36-47A7-AA09-E32E51CB3A27" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 7 Oct 2019 13:13:00 -0700 In-Reply-To: Cc: tools-discuss , RFC Interest To: "Andrew G. Malis" References: <20191007195852.11BD7B800CB@rfc-editor.org> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Tools-discuss] [rfc-i] First v3 RFC is published - RFC 8651 on Dynamic Link Exchange Protocol (DLEP) Control-Plane-Based Pause Extension X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2019 20:13:22 -0000 --Apple-Mail=_12D3D8B8-2B36-47A7-AA09-E32E51CB3A27 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 (Trimming the recipient list a bit) I think that=E2=80=99s a great idea (though as you noted, outside of my = purview)! -Heather > On Oct 7, 2019, at 1:10 PM, Andrew G. Malis wrote: >=20 > Heather, >=20 > Congratulations! >=20 > And a request ... probably not for you, but for the tools team (added = to the to: list). The Datatracker has a pointer to the htmlized version = from the tools site, but not the HTML version from the rfc-editor site = ... can that be added? >=20 > Thanks, > Andy >=20 >=20 > On Mon, Oct 7, 2019 at 4:00 PM Heather Flanagan > wrote: > Wow, everyone. We did it! >=20 > Thank you all for years and years of effort in getting us to this = point. RFC 8651 is now the first RFC to be published in the v3 format. >=20 > As those of you on the xml2rfc list know, there are still heated = discussions underway about some aspects of the XML vocabulary. Getting = the -bis documents out to capture the reality of the v3 format is = critically important. That is in the top 3 priorities for me as I wrap = up my time as RSE (the other two are operational transition items and = the RFC Model process discussion). >=20 > I particularly want to thank the RPC staff. They have worked = incredibly hard to fill the roles of expert copyeditors, quality = assurance engineers, and key stakeholders throughout the seven years = (and counting) of the RFC format project. This is an amazing team. Thank = you. >=20 > Heather Flanagan, RSE >=20 >> Begin forwarded message: >>=20 >> From: rfc-editor@rfc-editor.org >> Subject: RFC 8651 on Dynamic Link Exchange Protocol (DLEP) = Control-Plane-Based Pause Extension >> Date: October 7, 2019 at 12:58:52 PM PDT >> To: ietf-announce@ietf.org , = rfc-dist@rfc-editor.org >> Cc: rfc-editor@rfc-editor.org , = drafts-update-ref@iana.org , = manet@ietf.org >>=20 >> A new Request for Comments is now available in online RFC libraries. >>=20 >>=20 >> RFC 8651 >>=20 >> Title: Dynamic Link Exchange Protocol (DLEP)=20 >> Control-Plane-Based Pause Extension=20 >> Author: B. Cheng,=20 >> D. Wiggins, >> L. Berger, Ed. >> Status: Standards Track >> Stream: IETF >> Date: October 2019 >> Mailbox: bcheng@ll.mit.edu ,=20 >> david.wiggins@ll.mit.edu = ,=20 >> lberger@labn.net >> Pages: 12 >> Updates/Obsoletes/SeeAlso: None >>=20 >> I-D Tag: draft-ietf-manet-dlep-pause-extension-08.txt >>=20 >> URL: https://www.rfc-editor.org/info/rfc8651 = >>=20 >> DOI: 10.17487/RFC8651 >>=20 >> This document defines an extension to the Dynamic Link Exchange >> Protocol (DLEP) that enables a modem to use DLEP messages to pause >> and resume data traffic coming from its peer router. >>=20 >> This document is a product of the Mobile Ad-hoc Networks Working = Group of the IETF. >>=20 >> This is now a Proposed Standard. >>=20 >> STANDARDS TRACK: This document specifies an Internet Standards Track >> protocol for the Internet community, and requests discussion and = suggestions >> for improvements. Please refer to the current edition of the = Official >> Internet Protocol Standards (https://www.rfc-editor.org/standards = ) for the=20 >> standardization state and status of this protocol. Distribution of = this=20 >> memo is unlimited. >>=20 >> This announcement is sent to the IETF-Announce and rfc-dist lists. >> To subscribe or unsubscribe, see >> https://www.ietf.org/mailman/listinfo/ietf-announce = >> https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist = >>=20 >> For searching the RFC series, see https://www.rfc-editor.org/search = >> For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk = >>=20 >> Requests for special distribution should be addressed to either the >> author of the RFC in question, or to rfc-editor@rfc-editor.org = . Unless >> specifically noted otherwise on the RFC itself, all RFCs are for >> unlimited distribution. >>=20 >>=20 >> The RFC Editor Team >> Association Management Solutions, LLC >>=20 >>=20 >=20 > _______________________________________________ > rfc-interest mailing list > rfc-interest@rfc-editor.org > https://www.rfc-editor.org/mailman/listinfo/rfc-interest = > _______________________________________________ > rfc-interest mailing list > rfc-interest@rfc-editor.org > https://www.rfc-editor.org/mailman/listinfo/rfc-interest --Apple-Mail=_12D3D8B8-2B36-47A7-AA09-E32E51CB3A27 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 (Trimming the recipient list a bit)

I think that=E2=80=99s a great idea = (though as you noted, outside of my purview)!

-Heather

On Oct = 7, 2019, at 1:10 PM, Andrew G. Malis <agmalis@gmail.com> = wrote:

Heather,

Congratulations!

And a request ... probably not for you, but for the = tools team (added to the to: list). The Datatracker has a pointer to the = htmlized version from the tools site, but not the HTML version from the = rfc-editor site ... can that be added?

Thanks,
Andy


On Mon, Oct 7, 2019 at 4:00 PM Heather Flanagan = <rse@rfc-editor.org> wrote:
Wow, everyone. We did = it!

Thank you = all for years and years of effort in getting us to this point. RFC 8651 = is now the first RFC to be published in the v3 format.

As those of you on the = xml2rfc list know, there are still heated discussions underway about = some aspects of the XML vocabulary. Getting the -bis documents out to = capture the reality of the v3 format is critically important. That is in = the top 3 priorities for me as I wrap up my time as RSE (the other two = are operational transition items and the RFC Model process = discussion).

I = particularly want to thank the RPC staff. They have worked incredibly = hard to fill the roles of expert copyeditors, quality assurance = engineers, and key stakeholders throughout the seven years (and = counting) of the RFC format project. This is an amazing team. Thank = you.

Heather = Flanagan, RSE

Begin forwarded = message:

From: rfc-editor@rfc-editor.org
Subject: RFC 8651 on = Dynamic Link Exchange Protocol (DLEP) Control-Plane-Based Pause = Extension
Date: October 7, 2019 at 12:58:52 = PM PDT
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, manet@ietf.org

A new Request for Comments is = now available in online RFC libraries.


       RFC 8651

=        Title: =      Dynamic Link Exchange Protocol (DLEP)
=             &n= bsp;      Control-Plane-Based Pause = Extension
=        Author: =     B. Cheng,
=             &n= bsp;      D. Wiggins,
=             &n= bsp;      L. Berger, Ed.
=        Status: =     Standards Track
=        Stream: =     IETF
=        Date: =       October 2019
=        Mailbox:    bcheng@ll.mit.edu,
=             &n= bsp;      david.wiggins@ll.mit.edu,
=             &n= bsp;      lberger@labn.net
=        Pages: =      12
=        Updates/Obsoletes/SeeAlso: =   None

=        I-D Tag: =    draft-ietf-manet-dlep-pause-extension-08.txt

=        URL: =        https://www.rfc-editor.org/info/rfc8651

       DOI: =        10.17487/RFC8651

This document defines an extension to the = Dynamic Link Exchange
Protocol (DLEP) that enables a modem = to use DLEP messages to pause
and resume data traffic = coming from its peer router.

This document = is a product of the Mobile Ad-hoc Networks Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an = Internet Standards Track
protocol for the Internet = community, and requests discussion and suggestions
for = improvements.  Please refer to the current edition of the = Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the
standardization state and status of this protocol.  = Distribution of this
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist = lists.
To subscribe or unsubscribe, see
=  https://www.ietf.org/mailman/listinfo/ietf-announce
 https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
For searching the RFC series, see https://www.rfc-editor.org/search
For = downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to = either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are = for
unlimited distribution.

The RFC Editor Team
Association Management = Solutions, LLC



_______________________________________________
rfc-interest mailing list
rfc-interest@rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-interest
_______________________________________________
rfc-interest= mailing list
rfc-interest@rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

= --Apple-Mail=_12D3D8B8-2B36-47A7-AA09-E32E51CB3A27-- From nobody Mon Oct 7 13:38:04 2019 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08B8E120274 for ; Mon, 7 Oct 2019 13:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bangj.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 y3HlEJwxOeFR for ; Mon, 7 Oct 2019 13:37:50 -0700 (PDT) Received: from oj.bangj.com (69-77-154-174.static.skybest.com [69.77.154.174]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35EC21208C5 for ; Mon, 7 Oct 2019 13:37:50 -0700 (PDT) Received: from [172.16.25.104] (69-77-155-155.static.skybest.com [69.77.155.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 0A5452ADB3; Mon, 7 Oct 2019 16:37:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bangj.com; s=201907; t=1570480669; bh=t665ESn2hx6Bn1loUuswAPqhe/aHx0ep5/cIqMUbthU=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=XRut00ELDQpTGQnvGqIhRNvwSboPtqa99Bq/EsS9Cx7bINd2ZwxUgebKQiKBweVll nXkJX5sj7ceYQrG7T2mPVmKU0A5r47Q5UuTncTwBjQMELen0yJUH/gcvMLNMb85nY4 SWMvAhbuNUaFl62mYIJ8yhP60sQdMcFRwb2rMhIhZYS0yfOHyNYtjus1l3VX2qOP4q 5qHF33hPE/B0ZWG9R9e4AAMrmHSG7Ai5XrkZ3GGAbjeV6/qCYcWjyJzcmNwtV6U5gO E4reF6YnBEI2TuKxDURy9KE18kiUp7PY3PSqXjKpDJrJsltRJ/3kYAri5xFTOaRg4S lbOsk+w0Yhx3w== From: Tom Pusateri Message-Id: <31191B47-311F-4CAB-BA7F-AB55E01A9582@bangj.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_424F32E7-5D37-4D91-B699-641309916E77" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) Date: Mon, 7 Oct 2019 16:37:48 -0400 In-Reply-To: Cc: "Andrew G. Malis" , RFC Interest , tools-discuss To: Heather Flanagan References: <20191007195852.11BD7B800CB@rfc-editor.org> X-Mailer: Apple Mail (2.3594.4.19) Archived-At: Subject: Re: [Tools-discuss] [rfc-i] First v3 RFC is published - RFC 8651 on Dynamic Link Exchange Protocol (DLEP) Control-Plane-Based Pause Extension X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2019 20:38:01 -0000 --Apple-Mail=_424F32E7-5D37-4D91-B699-641309916E77 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This is awesome. And the HTML version is very easy to read. Nice job. = And direct section links! Perfect! Tom > On Oct 7, 2019, at 4:13 PM, Heather Flanagan = wrote: >=20 > (Trimming the recipient list a bit) >=20 > I think that=E2=80=99s a great idea (though as you noted, outside of = my purview)! >=20 > -Heather >=20 >> On Oct 7, 2019, at 1:10 PM, Andrew G. Malis > wrote: >>=20 >> Heather, >>=20 >> Congratulations! >>=20 >> And a request ... probably not for you, but for the tools team (added = to the to: list). The Datatracker has a pointer to the htmlized version = from the tools site, but not the HTML version from the rfc-editor site = ... can that be added? >>=20 >> Thanks, >> Andy >>=20 >>=20 >> On Mon, Oct 7, 2019 at 4:00 PM Heather Flanagan > wrote: >> Wow, everyone. We did it! >>=20 >> Thank you all for years and years of effort in getting us to this = point. RFC 8651 is now the first RFC to be published in the v3 format. >>=20 >> As those of you on the xml2rfc list know, there are still heated = discussions underway about some aspects of the XML vocabulary. Getting = the -bis documents out to capture the reality of the v3 format is = critically important. That is in the top 3 priorities for me as I wrap = up my time as RSE (the other two are operational transition items and = the RFC Model process discussion). >>=20 >> I particularly want to thank the RPC staff. They have worked = incredibly hard to fill the roles of expert copyeditors, quality = assurance engineers, and key stakeholders throughout the seven years = (and counting) of the RFC format project. This is an amazing team. Thank = you. >>=20 >> Heather Flanagan, RSE >>=20 >>> Begin forwarded message: >>>=20 >>> From: rfc-editor@rfc-editor.org >>> Subject: RFC 8651 on Dynamic Link Exchange Protocol (DLEP) = Control-Plane-Based Pause Extension >>> Date: October 7, 2019 at 12:58:52 PM PDT >>> To: ietf-announce@ietf.org , = rfc-dist@rfc-editor.org >>> Cc: rfc-editor@rfc-editor.org , = drafts-update-ref@iana.org , = manet@ietf.org >>>=20 >>> A new Request for Comments is now available in online RFC libraries. >>>=20 >>>=20 >>> RFC 8651 >>>=20 >>> Title: Dynamic Link Exchange Protocol (DLEP)=20 >>> Control-Plane-Based Pause Extension=20 >>> Author: B. Cheng,=20 >>> D. Wiggins, >>> L. Berger, Ed. >>> Status: Standards Track >>> Stream: IETF >>> Date: October 2019 >>> Mailbox: bcheng@ll.mit.edu ,=20 >>> david.wiggins@ll.mit.edu = ,=20 >>> lberger@labn.net >>> Pages: 12 >>> Updates/Obsoletes/SeeAlso: None >>>=20 >>> I-D Tag: draft-ietf-manet-dlep-pause-extension-08.txt >>>=20 >>> URL: https://www.rfc-editor.org/info/rfc8651 = >>>=20 >>> DOI: 10.17487/RFC8651 >>>=20 >>> This document defines an extension to the Dynamic Link Exchange >>> Protocol (DLEP) that enables a modem to use DLEP messages to pause >>> and resume data traffic coming from its peer router. >>>=20 >>> This document is a product of the Mobile Ad-hoc Networks Working = Group of the IETF. >>>=20 >>> This is now a Proposed Standard. >>>=20 >>> STANDARDS TRACK: This document specifies an Internet Standards Track >>> protocol for the Internet community, and requests discussion and = suggestions >>> for improvements. Please refer to the current edition of the = Official >>> Internet Protocol Standards (https://www.rfc-editor.org/standards = ) for the=20 >>> standardization state and status of this protocol. Distribution of = this=20 >>> memo is unlimited. >>>=20 >>> This announcement is sent to the IETF-Announce and rfc-dist lists. >>> To subscribe or unsubscribe, see >>> https://www.ietf.org/mailman/listinfo/ietf-announce = >>> https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist = >>>=20 >>> For searching the RFC series, see https://www.rfc-editor.org/search = >>> For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk = >>>=20 >>> Requests for special distribution should be addressed to either the >>> author of the RFC in question, or to rfc-editor@rfc-editor.org = . Unless >>> specifically noted otherwise on the RFC itself, all RFCs are for >>> unlimited distribution. >>>=20 >>>=20 >>> The RFC Editor Team >>> Association Management Solutions, LLC >>>=20 >>>=20 >>=20 >> _______________________________________________ >> rfc-interest mailing list >> rfc-interest@rfc-editor.org >> https://www.rfc-editor.org/mailman/listinfo/rfc-interest = >> _______________________________________________ >> rfc-interest mailing list >> rfc-interest@rfc-editor.org >> https://www.rfc-editor.org/mailman/listinfo/rfc-interest = >=20 > ___________________________________________________________ > Tools-discuss mailing list > Tools-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/tools-discuss >=20 > Please report datatracker.ietf.org and mailarchive.ietf.org > bugs at http://tools.ietf.org/tools/ietfdb > or send email to datatracker-project@ietf.org >=20 > Please report tools.ietf.org bugs at > http://tools.ietf.org/tools/issues > or send email to webmaster@tools.ietf.org --Apple-Mail=_424F32E7-5D37-4D91-B699-641309916E77 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This = is awesome. And the HTML version is very easy to read. Nice job. And = direct section links! Perfect!

Tom

On Oct 7, 2019, at 4:13 PM, Heather Flanagan = <rse@rfc-editor.org> wrote:

(Trimming the recipient list a = bit)

I think that=E2=80= =99s a great idea (though as you noted, outside of my = purview)!

-Heather

On Oct 7, 2019, at 1:10 PM, Andrew G. Malis = <agmalis@gmail.com> wrote:

Heather,

Congratulations!

And a request ... probably not for you, but for the = tools team (added to the to: list). The Datatracker has a pointer to the = htmlized version from the tools site, but not the HTML version from the = rfc-editor site ... can that be added?

Thanks,
Andy


On Mon, Oct 7, 2019 at 4:00 PM Heather Flanagan = <rse@rfc-editor.org> wrote:
Wow, everyone. We = did it!

Thank = you all for years and years of effort in getting us to this point. RFC = 8651 is now the first RFC to be published in the v3 format.

As those of you on the = xml2rfc list know, there are still heated discussions underway about = some aspects of the XML vocabulary. Getting the -bis documents out to = capture the reality of the v3 format is critically important. That is in = the top 3 priorities for me as I wrap up my time as RSE (the other two = are operational transition items and the RFC Model process = discussion).

I = particularly want to thank the RPC staff. They have worked incredibly = hard to fill the roles of expert copyeditors, quality assurance = engineers, and key stakeholders throughout the seven years (and = counting) of the RFC format project. This is an amazing team. Thank = you.

Heather = Flanagan, RSE

Begin forwarded = message:

From: rfc-editor@rfc-editor.org
Subject: RFC 8651 on Dynamic Link Exchange = Protocol (DLEP) Control-Plane-Based Pause Extension
Date: October 7, 2019 at 12:58:52 PM PDT
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, manet@ietf.org

A new Request for Comments is = now available in online RFC libraries.


       RFC 8651

       Title:=      Dynamic Link Exchange Protocol = (DLEP) 
          &nb= sp;        Control-Plane-Based = Pause Extension 
       Author: =     B. Cheng, 
          &nb= sp;        D. Wiggins,
          &nb= sp;        L. Berger, Ed.
       Status: =     Standards Track
       Stream: =     IETF
       Date: =       October 2019
       Mailbox: =    bcheng@ll.mit.edu, 
          &nb= sp;        david.wiggins@ll.mit.edu, 
          &nb= sp;        lberger@labn.net
       Pages: =      12
       Updates/Obsoletes/See= Also:   None

       I-D Tag: =    draft-ietf-manet-dlep-pause-extension-08.txt

       URL: =        https://www.rfc-editor.org/info/rfc8651

       DOI: =        10.17487/RFC8651

This document defines an extension to the = Dynamic Link Exchange
Protocol (DLEP) that enables a modem = to use DLEP messages to pause
and resume data traffic = coming from its peer router.

This document = is a product of the Mobile Ad-hoc Networks Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an = Internet Standards Track
protocol for the Internet = community, and requests discussion and suggestions
for = improvements.  Please refer to the current edition of the = Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  = Distribution of this memo is unlimited.

This = announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
 https://www.ietf.org/mailman/listinfo/ietf-announce
 https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
For searching the RFC series, see https://www.rfc-editor.org/search
For = downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to = either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are = for
unlimited distribution.

The RFC Editor Team
Association Management = Solutions, LLC



_______________________________________________
rfc-interest mailing list
rfc-interest@rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-interest
____________________________________________= ___
rfc-interest mailing list
rfc-interest@rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

___________________________________________________________
Tools-discuss = mailing list
Tools-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/tools-discuss<= br style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; = font-size: 14px; font-style: normal; font-variant-caps: normal; = font-weight: normal; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none;" class=3D"">
Please report = datatracker.ietf.org and mailarchive.ietf.org
bugs at http://tools.ietf.org/tools/ietfdb
or send email to datatracker-project@ietf.org

Please report tools.ietf.org bugs = at
http://tools.ietf.org/tools/issues
or send email to webmaster@tools.ietf.org= --Apple-Mail=_424F32E7-5D37-4D91-B699-641309916E77-- From nobody Tue Oct 8 14:23:53 2019 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE6512004C for ; Tue, 8 Oct 2019 14:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 69Su_OL37ZjJ for ; Tue, 8 Oct 2019 14:23:51 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7F26120046 for ; Tue, 8 Oct 2019 14:23:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 16BA4300AF1 for ; Tue, 8 Oct 2019 17:23:49 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id sINwo4lsH2Dz for ; Tue, 8 Oct 2019 17:23:47 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id EFF133004AF; Tue, 8 Oct 2019 17:23:46 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: Tools Team Discussion Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 8 Oct 2019 17:23:47 -0400 Message-Id: <082EE9F1-D4AA-487F-BB8C-08CDB59C5A2F@vigilsec.com> Cc: Tools Team Discussion , xml2rfc@ietf.org, xml2rfc-dev@ietf.org, rfc-markdown@ietf.org To: IETF X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [Tools-discuss] End of support for xml2rfc on Python 2.x is coming soon X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2019 21:23:53 -0000 Heads up! With the transition to xml2rfc vocabulary version 3, xml2rfc has gained the ability to generate PDF output when the necessary system libraries are installed. However, xml2rfc runs on Python 2.7, but the library needed for PDF generation ended support for Python 2.7 about 10 releases ago. This means that the need to end support for xml2rfc on Python 2.7 is becoming urgent. Another factor is that bugfix support for Python 2.7.x itself officially stops on 1 January 2020, so we need to transition away from Python 2.7 soon in any case. The latest xml2rfc release is 2.32.0. There will most likely be one or two additional xml2rfc releases in the 2.x series, but after that, the plan is to transition to a 3.x release series, with two major changes: (1) xml2rfc will no longer run under Python 2.7; it will require Python 3.5 or higher. If you cannot install and run Python 3 on your system, the web service at xml2rfc.ietf.org can be used. (2) The default output formatters will change to v3. The v2 formatters will still be available by using a --legacy switch. Expect the first xml2rfc 3.x series release before the end of the month. On behalf of the Tools Team, Russ From nobody Tue Oct 8 14:47:33 2019 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91E4E120020; Tue, 8 Oct 2019 14:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 y9ySMo4GtUMM; Tue, 8 Oct 2019 14:47:12 -0700 (PDT) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 A4B3D120033; Tue, 8 Oct 2019 14:47:12 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id a2so167964pfo.10; Tue, 08 Oct 2019 14:47:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; bh=1cLZ2UjtlMRh+eex+VxBVoOprTU34qj4OO1rUsD/wuI=; b=JJt7WrM0Ji+QHm9w0LgBjOZJ+iE2mHGWNxzjsi6M/ZMiJUwpRqG2CKcwDPx/R68kfh z21ccpqleo5nO9juKDFtyEt7mjQHChvoEWPp/tzpbfH7Ze5l5l2RpBSfDdK421sLSWvi 6wqjzFXbY1GVNmil90tt9qOX/t9DMPzPkfMi6DHiJuSlGUQtIoiD+Kux/XTwCtsQ2MC3 w8lpQ7/Wge03YXDeDSZG/Y1VSwuKFu9eTLlgfTVclkzUy5Z2AfWxbUgOFbKw6cdt3C0U KNQixt5fSWeYy38Rqy1yvDm0VlipvZbjm6J0oJ2dxAztDReeqGoxivC3uoTN99pFF/yC nTWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:mime-version:subject :from:in-reply-to:date:cc:message-id:references:to; bh=1cLZ2UjtlMRh+eex+VxBVoOprTU34qj4OO1rUsD/wuI=; b=sQxCmuWyfAyuXrYchhsDSPJSSPuPkJPuQbkbuC8TXjVl/naz0IXLZfZl1xmE41rJiN jElvj07RRx8/YIn7Z9QNopXWvG81DGD4ByAaHlkQOL6vArGcdR0fzXdMpFeCWLaeUGSV +qdVKNbNWsCbbKcs8NtW81Jq77cCJF1enXdK8lHpJB+fGSNejSjEdGYoCsiuw0oE5vnR sc0k/d5nutP9TZKJgdAodNyXGNqwGDxO0vQbt9cEAfD9lXbzr2/bKAX7IRuQNGQVKMqG TVtAOncULXSETAnXhz9Y0XLeTwEBb4lKv4V1/f+IevOiTFMcQTD4elyPSKsmj9yH8RLt 1awg== X-Gm-Message-State: APjAAAV9Zg1AbZJq5vo/kde0fu+qwklecX3dTAXJ/ISxwRtP2aoe0nWZ 947KIW9cIlDP5bkLQuEVgGcN/DJT X-Google-Smtp-Source: APXvYqxvv1mjXacyxM5Og1tqsfRtJFg8sYBpepa0+c/fVuHydKsHorjXKLaP0BmJDzVX44uyQdb3ZA== X-Received: by 2002:a62:d0:: with SMTP id 199mr107321pfa.108.1570571231952; Tue, 08 Oct 2019 14:47:11 -0700 (PDT) Received: from ?IPv6:2601:648:8400:5ab0:98c9:b154:b31:7528? ([2601:648:8400:5ab0:98c9:b154:b31:7528]) by smtp.gmail.com with ESMTPSA id 199sm84365pfv.152.2019.10.08.14.47.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Oct 2019 14:47:11 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) From: Fred Baker In-Reply-To: <082EE9F1-D4AA-487F-BB8C-08CDB59C5A2F@vigilsec.com> Date: Tue, 8 Oct 2019 14:47:08 -0700 Cc: IETF , rfc-markdown@ietf.org, xml2rfc@ietf.org, xml2rfc-dev@ietf.org Message-Id: <858628DA-84DA-4982-89D7-D652E04ACA10@gmail.com> References: <082EE9F1-D4AA-487F-BB8C-08CDB59C5A2F@vigilsec.com> To: Tools Team Discussion X-Mailer: iPhone Mail (17B5059g) Archived-At: Subject: Re: [Tools-discuss] [xml2rfc] End of support for xml2rfc on Python 2.x is coming soon X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2019 21:47:15 -0000 That all fine, and as predictable as you say. What would very helpful would b= e a road map: if you=E2=80=99re using {windows X|Mac X|Linux X|whatever}, we= think you should look at tools {D,E,F}. Speaking personally, I am on a Mac and using XMLmind with Fenner=E2=80=99s t= ools. They mostly worked (note the past tense) except when they didn=E2=80=99= t. Telling me =E2=80=9Cwell, ABCDEF supports =E2=80=9C doesn=E2=80=99t quite work. I used to write in NROFF. I=E2=80=99ll do what it takes. But really? Sent using a machine that autocorrects in interesting ways... > On Oct 8, 2019, at 2:31 PM, Russ Housley wrote: >=20 > =EF=BB=BFHeads up! >=20 > With the transition to xml2rfc vocabulary version 3, xml2rfc has gained > the ability to generate PDF output when the necessary system libraries > are installed. However, xml2rfc runs on Python 2.7, but the library > needed for PDF generation ended support for Python 2.7 about 10 > releases ago. This means that the need to end support for xml2rfc on > Python 2.7 is becoming urgent. Another factor is that bugfix support > for Python 2.7.x itself officially stops on 1 January 2020, so we need > to transition away from Python 2.7 soon in any case. >=20 > The latest xml2rfc release is 2.32.0. There will most likely be one or > two additional xml2rfc releases in the 2.x series, but after that, the > plan is to transition to a 3.x release series, with two major changes: >=20 > (1) xml2rfc will no longer run under Python 2.7; it will require > Python 3.5 or higher. If you cannot install and run Python 3 on > your system, the web service at xml2rfc.ietf.org can be used. >=20 > (2) The default output formatters will change to v3. The v2 formatters > will still be available by using a --legacy switch. >=20 > Expect the first xml2rfc 3.x series release before the end of the month. >=20 > On behalf of the Tools Team, > Russ >=20 > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc From nobody Tue Oct 8 14:48:56 2019 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB5011201AA; Tue, 8 Oct 2019 14:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 3-4g0ixNT3tr; Tue, 8 Oct 2019 14:48:17 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 869E4120255; Tue, 8 Oct 2019 14:48:17 -0700 (PDT) Received: from [192.168.217.110] (p548DCE50.dip0.t-ipconnect.de [84.141.206.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46nrZ74vMjzyW0; Tue, 8 Oct 2019 23:48:15 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <082EE9F1-D4AA-487F-BB8C-08CDB59C5A2F@vigilsec.com> Date: Tue, 8 Oct 2019 23:48:15 +0200 Cc: IETF , RFC Markdown , xml2rfc@ietf.org, xml2rfc-dev@ietf.org X-Mao-Original-Outgoing-Id: 592264092.618379-af4d9d3cb7a636276e96fbba24a54105 Content-Transfer-Encoding: quoted-printable Message-Id: <02046145-9455-4C01-9F6E-246D3940C86E@tzi.org> References: <082EE9F1-D4AA-487F-BB8C-08CDB59C5A2F@vigilsec.com> To: Tools Team Discussion X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Tools-discuss] [Rfc-markdown] End of support for xml2rfc on Python 2.x is coming soon X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2019 21:48:23 -0000 On Oct 8, 2019, at 23:23, Russ Housley wrote: >=20 > (2) The default output formatters will change to v3. The v2 = formatters > will still be available by using a --legacy switch. Please do this in a way that will not randomly break scripts and other = programs that need to run xml2rfc. (A calling script/program has no = idea what version of xml2rfc is installed locally.) [Actually, that is = also true of people calling xml2rfc=E2=80=A6] Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Oct 8 15:19:13 2019 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52887120046; Tue, 8 Oct 2019 15:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.095 X-Spam-Level: X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 fnN0otqq4kT7; Tue, 8 Oct 2019 15:19:04 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99A4F120020; Tue, 8 Oct 2019 15:19:04 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:52055 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1iHxot-0003hr-Bl; Tue, 08 Oct 2019 15:19:03 -0700 To: Carsten Bormann , Tools Team Discussion References: <082EE9F1-D4AA-487F-BB8C-08CDB59C5A2F@vigilsec.com> <02046145-9455-4C01-9F6E-246D3940C86E@tzi.org> Cc: RFC Markdown , xml2rfc@ietf.org, xml2rfc-dev@ietf.org, IETF From: Henrik Levkowetz Message-ID: <96647ed8-2627-4434-ad51-b373eadfade6@levkowetz.com> Date: Wed, 9 Oct 2019 00:18:53 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <02046145-9455-4C01-9F6E-246D3940C86E@tzi.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5gbFIuRtqBF0tK4k6g3Lfn9BMvl0k6wg3" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: ietf@ietf.org, xml2rfc-dev@ietf.org, xml2rfc@ietf.org, rfc-markdown@ietf.org, tools-discuss@ietf.org, cabo@tzi.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Tools-discuss] [xml2rfc] [Rfc-markdown] End of support for xml2rfc on Python 2.x is coming soon X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2019 22:19:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5gbFIuRtqBF0tK4k6g3Lfn9BMvl0k6wg3 Content-Type: multipart/mixed; boundary="QDX8Bkj2buaSfjC9aVlX6Ptt9xonPiKrL"; protected-headers="v1" From: Henrik Levkowetz To: Carsten Bormann , Tools Team Discussion Cc: RFC Markdown , xml2rfc@ietf.org, xml2rfc-dev@ietf.org, IETF Message-ID: <96647ed8-2627-4434-ad51-b373eadfade6@levkowetz.com> Subject: Re: [xml2rfc] [Rfc-markdown] End of support for xml2rfc on Python 2.x is coming soon References: <082EE9F1-D4AA-487F-BB8C-08CDB59C5A2F@vigilsec.com> <02046145-9455-4C01-9F6E-246D3940C86E@tzi.org> In-Reply-To: <02046145-9455-4C01-9F6E-246D3940C86E@tzi.org> --QDX8Bkj2buaSfjC9aVlX6Ptt9xonPiKrL Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Carsten, On 2019-10-08 23:48, Carsten Bormann wrote: > On Oct 8, 2019, at 23:23, Russ Housley wrote: >>=20 >> (2) The default output formatters will change to v3. The v2 formatter= s >> will still be available by using a --legacy switch. >=20 > Please do this in a way that will not randomly break scripts and > other programs that need to run xml2rfc. (A calling script/program > has no idea what version of xml2rfc is installed locally.) [Actually, > that is also true of people calling xml2rfc=E2=80=A6] Does it work for you if we say 'if you want v2 output, please add --legac= y to your scripts already now'? The --legacy switch to force v2 output (for compatible input) has been available for around 6 months, so even if you don't have the bleeding edge version installed, this should work as a compatibility path, I think= ? Best regards, Henrik --QDX8Bkj2buaSfjC9aVlX6Ptt9xonPiKrL-- --5gbFIuRtqBF0tK4k6g3Lfn9BMvl0k6wg3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl2dC00ACgkQTptXS4+7 FxqFHBAA2Hm84wZ1wmxVuIRlcf1WL30QJ48EV+0hQD64pKOW94Tm4R/swxEVrYkz dpjbKJz4ls/IZ0xOY5BYQzIQY4uFGJBJJQiRu+18PErWaG9N86+wPmFgg4ckucGl fxCc3LaSCYslGADr86cEHOUgaIVqhlw+G1ea52+9df2Nf8XiVwmw1EE2UZaQDtFP sxFencdxCkKWGYEmK5fsKcmKEn7e7kJXQtDgxk6PiSM1UiuRUnM5a1DSB0NpxqdY Yd6TjCoAKW29kXVIyiFqyySvjap7/a7chz2liQiXvLfRpAcb5bHhyQ83cstf2gkS wA4O3cBkhoU9FxG9L7kbZyZvJpYWXRlTh7e5Bi75F2/amPK/j9bZJEkWwIB+mIMV T2efVjorGD0gpi/piimN76efHgnHNSsGNIBjndoPx+0aIIb7FnYQMEeOb//DTH2l sBPvfer8PTNxO7zSW4KLIbdLAopWRz6u0C+ufsLI/94RBZosKJo7QjxzxXPbziyw VSIjVhfgnjedaqj9pIkyV9ElgZnmau7HLK+Bi5iEHVAmfjeuwWAnbed+nIZb26es iJgNiedJBzJcUiau1NrCpIIbNJ10e9CEJpyBQSVCP8A3z5d06zJqUULBH1nZ6mMW 1txkeExKnbPHvS8CC9jxFcZm2wNGYBj7ykjUohGVlwT+R6Ttc7o= =vUyQ -----END PGP SIGNATURE----- --5gbFIuRtqBF0tK4k6g3Lfn9BMvl0k6wg3-- From nobody Tue Oct 8 15:23:40 2019 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1E2A120046; Tue, 8 Oct 2019 15:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.095 X-Spam-Level: X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 1eP78JH_33id; Tue, 8 Oct 2019 15:23:20 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23709120020; Tue, 8 Oct 2019 15:23:20 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:52081 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1iHxt0-0003V0-Iz; Tue, 08 Oct 2019 15:23:19 -0700 To: Fred Baker , Tools Team Discussion References: <082EE9F1-D4AA-487F-BB8C-08CDB59C5A2F@vigilsec.com> <858628DA-84DA-4982-89D7-D652E04ACA10@gmail.com> Cc: rfc-markdown@ietf.org, xml2rfc@ietf.org, xml2rfc-dev@ietf.org, IETF From: Henrik Levkowetz Message-ID: Date: Wed, 9 Oct 2019 00:23:09 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <858628DA-84DA-4982-89D7-D652E04ACA10@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="SU6IGfPOISu6mm8qWtIOXANrO8NA2OL1f" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: ietf@ietf.org, xml2rfc-dev@ietf.org, xml2rfc@ietf.org, rfc-markdown@ietf.org, tools-discuss@ietf.org, fredbaker.ietf@gmail.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Tools-discuss] [xml2rfc-dev] [xml2rfc] End of support for xml2rfc on Python 2.x is coming soon X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2019 22:23:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SU6IGfPOISu6mm8qWtIOXANrO8NA2OL1f Content-Type: multipart/mixed; boundary="fp1wuUb3EXp23SnCSLhPK3vWpCbRpHsWW"; protected-headers="v1" From: Henrik Levkowetz To: Fred Baker , Tools Team Discussion Cc: rfc-markdown@ietf.org, xml2rfc@ietf.org, xml2rfc-dev@ietf.org, IETF Message-ID: Subject: Re: [xml2rfc-dev] [xml2rfc] End of support for xml2rfc on Python 2.x is coming soon References: <082EE9F1-D4AA-487F-BB8C-08CDB59C5A2F@vigilsec.com> <858628DA-84DA-4982-89D7-D652E04ACA10@gmail.com> In-Reply-To: <858628DA-84DA-4982-89D7-D652E04ACA10@gmail.com> --fp1wuUb3EXp23SnCSLhPK3vWpCbRpHsWW Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Fred, On 2019-10-08 23:47, Fred Baker wrote: > That all fine, and as predictable as you say. What would very helpful > would be a road map: if you=E2=80=99re using {windows X|Mac X|Linux > X|whatever}, we think you should look at tools {D,E,F}. >=20 > Speaking personally, I am on a Mac and using XMLmind with Fenner=E2=80=99= s > tools. They mostly worked (note the past tense) except when they > didn=E2=80=99t. Telling me =E2=80=9Cwell, ABCDEF supports can read Sanskrit>=E2=80=9C doesn=E2=80=99t quite work. >=20 > I used to write in NROFF. I=E2=80=99ll do what it takes. But really? I'm sorry if the text wasn't clear enough. The roadmap is this: Please install Python 3.5 or higher on your system, and install coming versions of xml2rfc using the 'pip3' command which is part of that Python install.= When we got to the xml2rfc 3.0.0 release, I had planned to update the release note with the information about using pip3, but I'm perfectly happy saying it now, too. Of course, if your default python is Python 3.5 or higher already, then using plain 'pip' to install will continue to work. Best regards, Henrik >=20 > Sent using a machine that autocorrects in interesting ways... >=20 >> On Oct 8, 2019, at 2:31 PM, Russ Housley wrote:= >>=20 >> =EF=BB=BFHeads up! >>=20 >> With the transition to xml2rfc vocabulary version 3, xml2rfc has gaine= d >> the ability to generate PDF output when the necessary system libraries= >> are installed. However, xml2rfc runs on Python 2.7, but the library >> needed for PDF generation ended support for Python 2.7 about 10 >> releases ago. This means that the need to end support for xml2rfc on >> Python 2.7 is becoming urgent. Another factor is that bugfix support >> for Python 2.7.x itself officially stops on 1 January 2020, so we need= >> to transition away from Python 2.7 soon in any case. >>=20 >> The latest xml2rfc release is 2.32.0. There will most likely be one o= r >> two additional xml2rfc releases in the 2.x series, but after that, the= >> plan is to transition to a 3.x release series, with two major changes:= >>=20 >> (1) xml2rfc will no longer run under Python 2.7; it will require >> Python 3.5 or higher. If you cannot install and run Python 3 on >> your system, the web service at xml2rfc.ietf.org can be used. >>=20 >> (2) The default output formatters will change to v3. The v2 formatter= s >> will still be available by using a --legacy switch. >>=20 >> Expect the first xml2rfc 3.x series release before the end of the mont= h. >>=20 >> On behalf of the Tools Team, >> Russ >>=20 >> _______________________________________________ >> xml2rfc mailing list >> xml2rfc@ietf.org >> https://www.ietf.org/mailman/listinfo/xml2rfc >=20 > _______________________________________________ > xml2rfc-dev mailing list > xml2rfc-dev@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc-dev >=20 --fp1wuUb3EXp23SnCSLhPK3vWpCbRpHsWW-- --SU6IGfPOISu6mm8qWtIOXANrO8NA2OL1f Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl2dDE0ACgkQTptXS4+7 FxpVRg//Rc/JWyh/WFEvAuWKXyxh8X+bcSSAs2KJgDBbgR+gvpSLADUNHNOpaTky 75Fk9J02LZmP4J42q7bhq6mgF5EOkyYt//UbeLBS4K0beArsk7AjR/idW3F7NBn6 l3L0gf7KX6fLG7Q4B5k94nDr0UKzgZCWl1t6naaX1XNeZ3DJcXbfY5VGIuDCfrwy jBymiTigmT4tCcPB9vXn2KntyIA6ND3SIdIdFadeDEeUurQJosnxmiHerx+AzXE8 WB+F3xe6P1CbDI6/pCD3nJgKdJ4KBPVSaGThvSji3f2/DZBGVtPU3jkyHUJ3YWvg smF4Zq43fVGz1tpTKtrKXrpTVLQF+S0Gam8MwiDaPbpqwFg1pji8r6qEAbqqSWNI FsOFHQnVwUpw3l5u6EWMRCB4547z+/DYQMY9vO5Qt3k2i6ViDIOKh6CVWhyHf6Qe CzuEbXtbN6wMTy4Aj7qlq7RNTsdHmxznI3mQRg/T3CzHH8cK1MaXhDzO1GSkm3q3 duNmBq9eGboWVMQ6gJYMRQQzp35wGgXF6uTwVqBt74QS7wN3dYODBlyg2FoWWbUH jmDK2RyIMTEI7ecYpCd5c/fv2xRdKVbraU8VW0a/qcE+da5OzPZivL1wMHpvNjVT J4d6tPevzarK9qxb95yAXLt2z+4MEFH0k41hiTpmI0e4MTxBtUc= =cxBe -----END PGP SIGNATURE----- --SU6IGfPOISu6mm8qWtIOXANrO8NA2OL1f-- From nobody Tue Oct 8 15:46:59 2019 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7BB1200B6; Tue, 8 Oct 2019 15:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 o5UwNnSKky6w; Tue, 8 Oct 2019 15:46:40 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D8F8120072; Tue, 8 Oct 2019 15:46:39 -0700 (PDT) Received: from [10.12.17.217] (unknown [172.93.197.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46nssR6GdTz10rL; Wed, 9 Oct 2019 00:46:35 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <96647ed8-2627-4434-ad51-b373eadfade6@levkowetz.com> Date: Wed, 9 Oct 2019 00:46:32 +0200 Cc: Tools Team Discussion , RFC Markdown , XML2RFC Interest Group , xml2rfc-dev@ietf.org, IETF X-Mao-Original-Outgoing-Id: 592267588.8788-baefa19dd9071f150dc18e6ec4c3da9a Content-Transfer-Encoding: quoted-printable Message-Id: <347055CD-74C9-479B-B7FC-BA78580C37B5@tzi.org> References: <082EE9F1-D4AA-487F-BB8C-08CDB59C5A2F@vigilsec.com> <02046145-9455-4C01-9F6E-246D3940C86E@tzi.org> <96647ed8-2627-4434-ad51-b373eadfade6@levkowetz.com> To: Henrik Levkowetz X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Tools-discuss] [xml2rfc] [Rfc-markdown] End of support for xml2rfc on Python 2.x is coming soon X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2019 22:46:42 -0000 On Oct 9, 2019, at 00:18, Henrik Levkowetz wrote: >=20 > Signed PGP part > Hi Carsten, >=20 > On 2019-10-08 23:48, Carsten Bormann wrote: >> On Oct 8, 2019, at 23:23, Russ Housley wrote: >>>=20 >>> (2) The default output formatters will change to v3. The v2 = formatters >>> will still be available by using a --legacy switch. >>=20 >> Please do this in a way that will not randomly break scripts and >> other programs that need to run xml2rfc. (A calling script/program >> has no idea what version of xml2rfc is installed locally.) [Actually, >> that is also true of people calling xml2rfc=E2=80=A6] >=20 > Does it work for you if we say 'if you want v2 output, please add = --legacy > to your scripts already now=E2=80=99? It sure works for me, but I don=E2=80=99t know all the other users of my = software. > The --legacy switch to force v2 output (for compatible input) has been > available for around 6 months, so even if you don't have the bleeding > edge version installed, this should work as a compatibility path, I = think? 6 months is very short in the grand scheme of things. Generally people will upgrade tools like kramdown-rfc and xml2rfc on = different timelines. (And there are also a few hundred makefiles in some repositories = somewhere that call xml2rfc.) With that out of the way, I must admit I don=E2=80=99t even understand = what this means: Format Options: --v3 with --text and --html: use the = v3 formatter, rather than the = legacy one. --legacy with --text and --html: use the = legacy text formatter, rather than the = v3 one. Does the choice of =E2=80=9Clegacy=E2=80=9D and =E2=80=9Cv3=E2=80=9D = formatter have an influence on the accepted XML vocabulary? On the = output format? Both? How? Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Oct 8 16:16:11 2019 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05091200BA; Tue, 8 Oct 2019 16:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.095 X-Spam-Level: X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 c6rXmhntYFRK; Tue, 8 Oct 2019 16:15:55 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCCA61200B6; Tue, 8 Oct 2019 16:15:55 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:52687 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1iHyhu-000111-Te; Tue, 08 Oct 2019 16:15:55 -0700 To: Carsten Bormann References: <082EE9F1-D4AA-487F-BB8C-08CDB59C5A2F@vigilsec.com> <02046145-9455-4C01-9F6E-246D3940C86E@tzi.org> <96647ed8-2627-4434-ad51-b373eadfade6@levkowetz.com> <347055CD-74C9-479B-B7FC-BA78580C37B5@tzi.org> Cc: Tools Team Discussion , RFC Markdown , XML2RFC Interest Group , xml2rfc-dev@ietf.org, IETF From: Henrik Levkowetz Message-ID: Date: Wed, 9 Oct 2019 01:15:46 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <347055CD-74C9-479B-B7FC-BA78580C37B5@tzi.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kTm59LbtfeSD89s3WWgNSO4nqnBxkoGQP" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: ietf@ietf.org, xml2rfc-dev@ietf.org, xml2rfc@ietf.org, rfc-markdown@ietf.org, tools-discuss@ietf.org, cabo@tzi.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Tools-discuss] [xml2rfc] [Rfc-markdown] End of support for xml2rfc on Python 2.x is coming soon X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2019 23:15:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kTm59LbtfeSD89s3WWgNSO4nqnBxkoGQP Content-Type: multipart/mixed; boundary="nsVbam8cmmQMEdmXNQtrhtTOd5igFvlHv"; protected-headers="v1" From: Henrik Levkowetz To: Carsten Bormann Cc: Tools Team Discussion , RFC Markdown , XML2RFC Interest Group , xml2rfc-dev@ietf.org, IETF Message-ID: Subject: Re: [Tools-discuss] [xml2rfc] [Rfc-markdown] End of support for xml2rfc on Python 2.x is coming soon References: <082EE9F1-D4AA-487F-BB8C-08CDB59C5A2F@vigilsec.com> <02046145-9455-4C01-9F6E-246D3940C86E@tzi.org> <96647ed8-2627-4434-ad51-b373eadfade6@levkowetz.com> <347055CD-74C9-479B-B7FC-BA78580C37B5@tzi.org> In-Reply-To: <347055CD-74C9-479B-B7FC-BA78580C37B5@tzi.org> --nsVbam8cmmQMEdmXNQtrhtTOd5igFvlHv Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Carsten, On 2019-10-09 00:46, Carsten Bormann wrote: > On Oct 9, 2019, at 00:18, Henrik Levkowetz wrote= : >>=20 >> Signed PGP part >> Hi Carsten, >>=20 >> On 2019-10-08 23:48, Carsten Bormann wrote: >>> On Oct 8, 2019, at 23:23, Russ Housley wrote: >>>>=20 >>>> (2) The default output formatters will change to v3. The v2 formatt= ers >>>> will still be available by using a --legacy switch. >>>=20 >>> Please do this in a way that will not randomly break scripts and >>> other programs that need to run xml2rfc. (A calling script/program >>> has no idea what version of xml2rfc is installed locally.) [Actually,= >>> that is also true of people calling xml2rfc=E2=80=A6] >>=20 >> Does it work for you if we say 'if you want v2 output, please add --le= gacy >> to your scripts already now=E2=80=99? >=20 > It sure works for me, but I don=E2=80=99t know all the other users of m= y software. Ack. >> The --legacy switch to force v2 output (for compatible input) has been= >> available for around 6 months, so even if you don't have the bleeding >> edge version installed, this should work as a compatibility path, I th= ink? >=20 > 6 months is very short in the grand scheme of things. >=20 > Generally people will upgrade tools like kramdown-rfc and xml2rfc on > different timelines. (And there are also a few hundred makefiles in > some repositories somewhere that call xml2rfc.) >=20 > With that out of the way, I must admit I don=E2=80=99t even understand = what > this means: >=20 > Format Options: > --v3 with --text and --html: use the= v3 > formatter, rather than the lega= cy one. > --legacy with --text and --html: use the= legacy > text formatter, rather than the= v3 > one. >=20 > Does the choice of =E2=80=9Clegacy=E2=80=9D and =E2=80=9Cv3=E2=80=9D fo= rmatter have an influence on > the accepted XML vocabulary? Only indirectly. If you use --v3, the new formatters will be used. xml2rfc will accept both v2 and v3, and run the v2v3 converter internally= in order to not present any deprecated elements to the v3 formatters. If you use --legacy, the old formatters will be used. Since there is no internal v3v2 converter, only v2 input will work. =20 > On the output format? Yes, that's the primary effect intended with these switches. > Both? How? Maybe a processing diagram will help: http://tools.ietf.org/src/xml2rfc/trunk/cli/doc/xml2rfc3.html#processing-= flow Regards, Henrik --nsVbam8cmmQMEdmXNQtrhtTOd5igFvlHv-- --kTm59LbtfeSD89s3WWgNSO4nqnBxkoGQP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl2dGKIACgkQTptXS4+7 Fxo/iA//VFw37zAadC9+vSDjbWuz+vm0Ub2BKRYMPS1+70H//+l1XSgJe6kBkC+Y wzlMFGuUWugv88rvSzA0lCyeNVPP2vM19r34INDMUZbPq/376Ek76ufg12oMpzou vxYH/UxEOwp8SNNsv4CC6bSXzttspuZoBY0Hs15EnZgJ67EtQeScAV6tHqReEZ42 7Ew1qm/LawjeGf8bGmczqcFt2+IXlEMiRhXWTq3hwDipaXAcCrPYirTR+krOFdne f3zu0caNhXU+qhSCw3TzaE27Vd78TPlgFqxrBvAeLmZdD5KLBHTGWiBd6aJSa2+Y r3ie6gNAt/M1oJoN5XK4SdaFlkh+D5as1MUvjFANkAZZ80M9axRN0ryZc7+kLW0y v/B81pO3I1kljy6LN7YLwzjxKlDcSApSAQBfneF4aaILFSV31aHoz1Di/r48trcF K7ev0mF7YB5Ubvrk15l0pttlZ1l6pl5cilX8vV9Fctnao0SKb5dMDANi7jzbtmaC u71Jmedo5t3KvDuZuD6rY4hlXtCWlgy6Vl+39+Fdu9kO2d8uBrWMIUBXY1fIO9e7 iW+81CUy69YbeZHtAy8oYtwb6/dwM8rvYMFFpWDaNdp1MtZnJd0l4iSzDo3z7RbB FQdhnH/09aulzhORbzAbYY9wmIc57Adbz1BmHFU+Adr/pW/OJ9s= =53Wn -----END PGP SIGNATURE----- --kTm59LbtfeSD89s3WWgNSO4nqnBxkoGQP-- From nobody Tue Oct 8 17:00:31 2019 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C87A12006B for ; Tue, 8 Oct 2019 17:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.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 Giz5WcCTRz9T for ; Tue, 8 Oct 2019 17:00:20 -0700 (PDT) Received: from mail-ot1-f68.google.com (mail-ot1-f68.google.com [209.85.210.68]) (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 611BC1200EF for ; Tue, 8 Oct 2019 17:00:20 -0700 (PDT) Received: by mail-ot1-f68.google.com with SMTP id 41so131887oti.12 for ; Tue, 08 Oct 2019 17:00:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=EPJeALIFxIu0XyXuSx4aLAk+QCKCgRINX3FRaaHRA0c=; b=bsbFjRomQzpgWKQLFiSdg1jeybE2nvU48I0rJ1rH1JZWGvaUfVsCUfcquTqyxNSaDZ WZQCw/3Wb7STtVb28ybpXm5n98CV9f1IffN9NXLcik4TCWMVQvINn2pma4M7MKsWRFC/ 9v+DSLa1L5qaNgozI/kbznYnKmlmY0rnwK+ZFxPcNlFWLsoIYzkZLfyrATpEHajFYNs5 IbXBy5aym6TNYc0HAY1Bb3bEsW7ErAzYMM0zOA+fkFQyuVxzfLiX3UwaL32LptxWqVYS Hb8CCHJCXoSZomSmveWZu2KHTEJ+hCpf6vaYMifKEv1izgSmcrya0IaQRIJ7oGo6w+tt +jQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=EPJeALIFxIu0XyXuSx4aLAk+QCKCgRINX3FRaaHRA0c=; b=VIrLXCka6DcoN7Uz5mYDisRG1GkSV9YcUCbm9k1DEzExuKHYC9OHD3w7EM8ovfSSWD /TN7HddkOL3WQ9js3UKGxo3br31+iCv75nHBcCdRGGxIgSuW3wT8z6tuz2NWK4vs8kPc 9wySnNgkAngeHIVn+ugcUjOfvRrZ9tYvXmujQTZuLLiP1APC7y5tNXvQez7QGH5K/ZDo /T08C5+7/2bA9No+eH7XopL41dQy2WetZUDYtOZFcxYB/lhqUKjgxFDrfY61u8lWCA6k cnvT9S8oSjiLqbo4mAY/LaBYNf3pxp4CUW8aC24ydHXxRgBl+K9e4cXsR5BqY8FiBsy4 DCDg== X-Gm-Message-State: APjAAAX/NIkWoi4b9omI+alER67p4qJrl5bM8zkc4TQ3dDpP+h1+V6PF QsldclPLSt8i1BzOU8fpObPmcho3Nao4PcNiDsEH4Q== X-Google-Smtp-Source: APXvYqx/U63Wn0NmONxZ5oXCNH/inzdj2eg5oZLtvnF4ijBCC5A7ffm7/SlW2/z5NUAVyOXvMa+sfDCYxqk6nwSM5+Y= X-Received: by 2002:a05:6830:150c:: with SMTP id k12mr685327otp.106.1570579218857; Tue, 08 Oct 2019 17:00:18 -0700 (PDT) MIME-Version: 1.0 References: <082EE9F1-D4AA-487F-BB8C-08CDB59C5A2F@vigilsec.com> <858628DA-84DA-4982-89D7-D652E04ACA10@gmail.com> In-Reply-To: From: Job Snijders Date: Wed, 9 Oct 2019 00:00:06 +0000 Message-ID: To: Henrik Levkowetz Cc: Fred Baker , Tools Team Discussion , rfc-markdown@ietf.org, xml2rfc@ietf.org, xml2rfc-dev@ietf.org, IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Tools-discuss] [xml2rfc-dev] [xml2rfc] End of support for xml2rfc on Python 2.x is coming soon X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2019 00:00:23 -0000 On Tue, Oct 8, 2019 at 10:23 PM Henrik Levkowetz wro= te: > On 2019-10-08 23:47, Fred Baker wrote: > > That all fine, and as predictable as you say. What would very helpful > > would be a road map: if you=E2=80=99re using {windows X|Mac X|Linux > > X|whatever}, we think you should look at tools {D,E,F}. > > > > Speaking personally, I am on a Mac and using XMLmind with Fenner=E2=80= =99s > > tools. They mostly worked (note the past tense) except when they > > didn=E2=80=99t. Telling me =E2=80=9Cwell, ABCDEF supports > can read Sanskrit>=E2=80=9C doesn=E2=80=99t quite work. > > > > I used to write in NROFF. I=E2=80=99ll do what it takes. But really? > > I'm sorry if the text wasn't clear enough. The roadmap is this: Please > install Python 3.5 or higher on your system, and install coming versions > of xml2rfc using the 'pip3' command which is part of that Python install. > > When we got to the xml2rfc 3.0.0 release, I had planned to update the > release note with the information about using pip3, but I'm perfectly > happy saying it now, too. > > Of course, if your default python is Python 3.5 or higher already, then > using plain 'pip' to install will continue to work. We should note that the potential for pip/pip3 confusion is a result of how the python community approached this transition (acknowleding what their options were in context of how the packaging eco system was set up). Not ideal, but it is what it is. I think it would be good to update public facing documentation about xml2rfc that pip3 must be used, to make it very clear that any version of xml2rfc is not expected to work correctly on python2 systems. Perhaps the final update to xml2rfc 2.x series should be to add a check at boot whether the python interpreter's major version is lower than 3, and if so, exit the xml2rfc program with an informative message and a non-zero exit code, inform the user that python3 must be used? Sometimes it is better to just break fast & early. Between the name of the tool (note the 2 in "xlm2rfc"), the industry's transition from python 2 to python 3, and IETF's transition from the v2 to the v3 RFC XML format, it is no surprise to me end users easily become confused. A simple strong message that python2 can't be used might be helpful, even if it appears somewhat unforgiving. Kind regards, Job From nobody Tue Oct 8 23:09:42 2019 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C22D120088; Tue, 8 Oct 2019 23:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.096 X-Spam-Level: X-Spam-Status: No, score=-1.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=no 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 QXoqMIwSv7yH; Tue, 8 Oct 2019 23:09:20 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA6C7120019; Tue, 8 Oct 2019 23:09:20 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:56563 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1iI59w-0006IT-Tt; Tue, 08 Oct 2019 23:09:19 -0700 To: Job Snijders References: <082EE9F1-D4AA-487F-BB8C-08CDB59C5A2F@vigilsec.com> <858628DA-84DA-4982-89D7-D652E04ACA10@gmail.com> Cc: xml2rfc-dev@ietf.org, IETF , Tools Team Discussion , Fred Baker , xml2rfc@ietf.org, rfc-markdown@ietf.org From: Henrik Levkowetz Message-ID: Date: Wed, 9 Oct 2019 08:09:08 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WPra5w39DAUrBIQdUjTWnCXHsrFmi8132" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: rfc-markdown@ietf.org, xml2rfc@ietf.org, fredbaker.ietf@gmail.com, tools-discuss@ietf.org, ietf@ietf.org, xml2rfc-dev@ietf.org, job@instituut.net X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Tools-discuss] [xml2rfc-dev] [xml2rfc] End of support for xml2rfc on Python 2.x is coming soon X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2019 06:09:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WPra5w39DAUrBIQdUjTWnCXHsrFmi8132 Content-Type: multipart/mixed; boundary="L61KBppnh3fmxwe5Se0JINC6clPAKm38m"; protected-headers="v1" From: Henrik Levkowetz To: Job Snijders Cc: xml2rfc-dev@ietf.org, IETF , Tools Team Discussion , Fred Baker , xml2rfc@ietf.org, rfc-markdown@ietf.org Message-ID: Subject: Re: [Tools-discuss] [xml2rfc-dev] [xml2rfc] End of support for xml2rfc on Python 2.x is coming soon References: <082EE9F1-D4AA-487F-BB8C-08CDB59C5A2F@vigilsec.com> <858628DA-84DA-4982-89D7-D652E04ACA10@gmail.com> In-Reply-To: --L61KBppnh3fmxwe5Se0JINC6clPAKm38m Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Job, On 2019-10-09 02:00, Job Snijders wrote: > On Tue, Oct 8, 2019 at 10:23 PM Henrik Levkowetz = wrote: >> On 2019-10-08 23:47, Fred Baker wrote: >> > That all fine, and as predictable as you say. What would very helpfu= l >> > would be a road map: if you=E2=80=99re using {windows X|Mac X|Linux >> > X|whatever}, we think you should look at tools {D,E,F}. >> > >> > Speaking personally, I am on a Mac and using XMLmind with Fenner=E2=80= =99s >> > tools. They mostly worked (note the past tense) except when they >> > didn=E2=80=99t. Telling me =E2=80=9Cwell, ABCDEF supports > > can read Sanskrit>=E2=80=9C doesn=E2=80=99t quite work. >> > >> > I used to write in NROFF. I=E2=80=99ll do what it takes. But really?= >> >> I'm sorry if the text wasn't clear enough. The roadmap is this: Plea= se >> install Python 3.5 or higher on your system, and install coming versio= ns >> of xml2rfc using the 'pip3' command which is part of that Python insta= ll. >> >> When we got to the xml2rfc 3.0.0 release, I had planned to update the >> release note with the information about using pip3, but I'm perfectly >> happy saying it now, too. >> >> Of course, if your default python is Python 3.5 or higher already, the= n >> using plain 'pip' to install will continue to work. >=20 > We should note that the potential for pip/pip3 confusion is a result > of how the python community approached this transition (acknowleding > what their options were in context of how the packaging eco system was > set up). Not ideal, but it is what it is. >=20 > I think it would be good to update public facing documentation about > xml2rfc that pip3 must be used, to make it very clear that any version > of xml2rfc is not expected to work correctly on python2 systems. Right. > Perhaps the final update to xml2rfc 2.x series should be to add a > check at boot whether the python interpreter's major version is lower > than 3, and if so, exit the xml2rfc program with an informative > message and a non-zero exit code, inform the user that python3 must be > used? Sometimes it is better to just break fast & early. I think that message will come through clearly on first attempt at installing the first xml2rfc version requiring Python 3, as I expect that to tell the user that 'this version of xml2rfc requires Python 3', but I'll do some testing when I come to that point. Better to fail during that installation, but still leave the user and system with a working (though out-of date) version of xml2rfc, than to install a version that cannot be used to do work. > Between the name of the tool (note the 2 in "xlm2rfc"), the industry's > transition from python 2 to python 3, and IETF's transition from the > v2 to the v3 RFC XML format, it is no surprise to me end users easily > become confused. A simple strong message that python2 can't be used > might be helpful, even if it appears somewhat unforgiving. Yes. I'd still like to leave the user with a system which hasn't been robbed of the xml2rfc functionality as a result of installing 'the last 2.x release of xml2rfc'. Best regards, Henrik --L61KBppnh3fmxwe5Se0JINC6clPAKm38m-- --WPra5w39DAUrBIQdUjTWnCXHsrFmi8132 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl2deYQACgkQTptXS4+7 Fxo9/A/6Apq3QSnxL0yYqUHJlft6qw6bl2jZA0/L44d2MWe7WeaRhIpZI83zan6P yv4B1QPhg7zHcwNIQ1z5KFcD1sIRq669BxqkmR4pDI+i3gCbu/knTxzxRlMMscMc TPSNx7oJQ8rgCrICMku0tay0jDtooqv7wHHsX5p2J2/j9gi1yaRJYfF1LpezmdqC 3Kh/OFTxFxf7RRUCraOYXgUzib6c00+XXtpdsgsOxZVxwle8ZwraGUMirwVe1Tu0 wN2bFxvYJzzGTDj84EdgrDWWF2iWW0aSM2l3oL2yrXp3Zm4on/LwUFComXG7Ijow o06WKnyijldrWB5pVvAlfLNzeJ+QNc82MEwHHRrRiSFPN+DEymvlwg7qBO38otHX h8cfkW9IJfyAum+lCVGyZwe+Yr9GBbSidPVfIQ+x4p5joySt+o1sYSvgjdFMZCyw xpgoTzujTnu3UNu9Ox8v6HiNWaT1oTFGEGPy8BrfVl1GVtymok+cdR4S5/xz4JsF lPV/+fzURfHyrv33+ScyeebG+kWzWZupdNQV6UrsAuSMInck+3NvB76CS66nydpu nQYNeCnp9+nIaxJ9yLsnU2a4IBKEeRIFPcEn1vBpN7IeKcc24MeX2TaRl6pjKJoo 5OG+Rc9DqBUAcWzXK7wEN09NMmqZvdVIdnRkn/YSSyeaHBQf0ks= =o2g1 -----END PGP SIGNATURE----- --WPra5w39DAUrBIQdUjTWnCXHsrFmi8132-- From nobody Tue Oct 8 23:53:02 2019 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF3C31200E3; Tue, 8 Oct 2019 23:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.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 4MvsJsY-CYgU; Tue, 8 Oct 2019 23:52:46 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-eopbgr1400095.outbound.protection.outlook.com [40.107.140.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DD8C120108; Tue, 8 Oct 2019 23:52:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Tnfe23Lyu0SQg7PgfiS+EP78182FZSSQIcLQXdvsGM0pL4CMSu6BBpK4nNgDrPK4aDO5sxNkEHUxVZoGW4KZigb+PW9HFUxKIzO1DmxGxVLJ5Td//pV9q43D4C1v16DfzGLcjRN5cuU4eki0FgmnQj1ScANjr2Jlxll+1bjPjrXf2axqYyySIP46iM65JuZGr3He5nMRIkmgA32B0gKkE8WJwkh25TmsFGEOEIo1deWCulT9KswC/1W9tUO2us3oLwpgUsrr0BCdJ1w4EtcpI4c9YW7R389FaBwEFyG8TQNS48L0Lx/6RHbY/2zWzT/sqlZAd8+Kp6I4keP+TnhiPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fOg+PDuhYVcprDge44ixo+7gC5Hwes5WONqPo7LIIJE=; b=VzYinOV7WQfNYJyBrO+KkrzZq4MlYmy3ukNDSjDsSmqUw2E9jh/9JU15dh7gMOPT0Q04LmaJEScmUPfope+tIsO3mPDU+rOEjm2NnmfuhNTceKZOJNxdLgn+0dXk5PIvBwdbcEQ3kSljwU9abisIEwp3jveIst8TNvBaI5pqcQtoD65bFLCeeoCnC7j4TAu4/fPNJXWdQJri+Tl0mKE7NcvdaOlXlskiXtVifw81CtAkNxduD/p6UOjdH0FuOufs2oH4qMKt9Xtf/MONCkl80WXOOrX28RIsHWWxI+Bg5NggiSIy74J8EVTqNg3knI0ThwFwAyWBzsHKifK8/paNQw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fOg+PDuhYVcprDge44ixo+7gC5Hwes5WONqPo7LIIJE=; b=O7n4L8Fgk9Te2u8FIS10qqoip4fcB9CcYqlfQr//V6CaoaL3l32y1IAaHHZnnMvjcgc3iNqRbSdsOfIB2d3otwvruJVF65FMORgT41JOvMK1K0n/E+iuQzPoYwqyLOih+LWSeg3jDQTtHm7BOxX482XGEcF1p2s5kCessUWSA74= Received: from OSAPR01MB2193.jpnprd01.prod.outlook.com (52.134.235.146) by OSAPR01MB4545.jpnprd01.prod.outlook.com (20.179.176.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2327.24; Wed, 9 Oct 2019 06:52:44 +0000 Received: from OSAPR01MB2193.jpnprd01.prod.outlook.com ([fe80::a418:e2c6:45b5:dc38]) by OSAPR01MB2193.jpnprd01.prod.outlook.com ([fe80::a418:e2c6:45b5:dc38%7]) with mapi id 15.20.2327.026; Wed, 9 Oct 2019 06:52:43 +0000 From: =?utf-8?B?TWFydGluIEouIETDvHJzdA==?= To: Job Snijders , Henrik Levkowetz CC: "xml2rfc-dev@ietf.org" , IETF , Tools Team Discussion , Fred Baker , "xml2rfc@ietf.org" , "rfc-markdown@ietf.org" Thread-Topic: [xml2rfc-dev] [xml2rfc] End of support for xml2rfc on Python 2.x is coming soon Thread-Index: AQHVfiH/y0WtOkFie0+XuTKWAq7XJ6dRUamAgAAbFgCAAFccAA== Date: Wed, 9 Oct 2019 06:52:43 +0000 Message-ID: References: <082EE9F1-D4AA-487F-BB8C-08CDB59C5A2F@vigilsec.com> <858628DA-84DA-4982-89D7-D652E04ACA10@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: TYCPR01CA0104.jpnprd01.prod.outlook.com (2603:1096:405:4::20) To OSAPR01MB2193.jpnprd01.prod.outlook.com (2603:1096:603:17::18) authentication-results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [133.2.0.65] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8b82439f-e3c5-4666-4169-08d74c854901 x-ms-traffictypediagnostic: OSAPR01MB4545: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 018577E36E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(396003)(366004)(39840400004)(346002)(376002)(189003)(199004)(81156014)(26005)(66556008)(64756008)(66446008)(31696002)(85182001)(85202003)(86362001)(4744005)(81166006)(66476007)(66946007)(6246003)(4326008)(6512007)(31686004)(6436002)(5660300002)(6486002)(8936002)(2906002)(486006)(229853002)(3846002)(6116002)(2616005)(786003)(99286004)(256004)(11346002)(446003)(102836004)(76176011)(386003)(6506007)(53546011)(52116002)(8676002)(54906003)(186003)(476003)(71190400001)(305945005)(71200400001)(66066001)(7736002)(508600001)(14454004)(316002)(25786009)(110136005); DIR:OUT; SFP:1102; SCL:1; SRVR:OSAPR01MB4545; H:OSAPR01MB2193.jpnprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5y4bepYZzmb823vHL0/Um1h+YWa6qirIgD7/9CfYd+2d1ovv6JGBD74viWMc51ecV4yBeOAuTVtu9efNgMrDov3dKTpB1D+nrzAe/izzTbm569xDG7T/o7hXQhP390s3mFoTz4Ck4nFRD/1cH4HdLJ7Sp64+7cTYZtCcjavG6T/RQyxD8zRFKQ8JFXeiuM25BsSQZ9mUYX05hMaYqRfgN9AYGpzSv0Z5lqaqDFoAasRJZsBjjZIhD1sQB36nCCvo85Kfv4mXT0ql3344mjqZP+WgPW7WsILfzXzZabn+dB9PrhKHolI70hLMRh+5mPMEkhPJ+k0ltsxVDWdeuhL4dHQ551E3pH8zdbA1PxJxj/kwN+gY9dF/HSU7fABTCxwLcyaZ2NgBPISk3i9SDl43ErWzA+jld8vDFeMtGlGorE4= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <4DECC6D5B063E140BB6BF6A599050DAC@jpnprd01.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 8b82439f-e3c5-4666-4169-08d74c854901 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2019 06:52:43.7663 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /g9mCdKVFGERU37SAs3/+g9tYXJXy5srqtHUnUz5bLncHPXUr+jdiBre3kRXFUUhkYs0tz8g85qE/1hfaQKEPQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSAPR01MB4545 Archived-At: Subject: Re: [Tools-discuss] [xml2rfc-dev] [xml2rfc] End of support for xml2rfc on Python 2.x is coming soon X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2019 06:52:49 -0000 T24gMjAxOS8xMC8wOSAwOTowMCwgSm9iIFNuaWpkZXJzIHdyb3RlOg0KDQo+IEJldHdlZW4gdGhl IG5hbWUgb2YgdGhlIHRvb2wgKG5vdGUgdGhlIDIgaW4gInhsbTJyZmMiKSwgdGhlIGluZHVzdHJ5 J3MNCj4gdHJhbnNpdGlvbiBmcm9tIHB5dGhvbiAyIHRvIHB5dGhvbiAzLCBhbmQgSUVURidzIHRy YW5zaXRpb24gZnJvbSB0aGUNCj4gdjIgdG8gdGhlIHYzIFJGQyBYTUwgZm9ybWF0LCBpdCBpcyBu byBzdXJwcmlzZSB0byBtZSBlbmQgdXNlcnMgZWFzaWx5DQo+IGJlY29tZSBjb25mdXNlZC4gQSBz aW1wbGUgc3Ryb25nIG1lc3NhZ2UgdGhhdCBweXRob24yIGNhbid0IGJlIHVzZWQNCj4gbWlnaHQg YmUgaGVscGZ1bCwgZXZlbiBpZiBpdCBhcHBlYXJzIHNvbWV3aGF0IHVuZm9yZ2l2aW5nLg0KDQpX aGF0IGFib3V0IGNoYW5naW5nIHhtbDJyZmMncyBuYW1lIHRvIHhtbDNyZmM/IFRoYXQgd2F5LCB4 bWwzcmZjLCBweXRob24gDQozLCB2MyBvZiBSRkMgWE1MLCBhbmQgcGlwMyB3b3VsZCBhbGwgYWxp Z24gOi0pLg0KDQpSZWdhcmRzLCAgIE1hcnRpbi4NCg== From nobody Wed Oct 9 00:51:29 2019 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2878712009C; Wed, 9 Oct 2019 00:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 Ri9ss1NR4REn; Wed, 9 Oct 2019 00:51:00 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAF4212008D; Wed, 9 Oct 2019 00:50:59 -0700 (PDT) Received: from [192.168.217.110] (p548DCE50.dip0.t-ipconnect.de [84.141.206.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46p5xZ1Lm8zyjS; Wed, 9 Oct 2019 09:50:58 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Wed, 9 Oct 2019 09:50:57 +0200 Cc: RFC Markdown , XML2RFC Interest Group , XML Developer List , IETF , Tools Team Discussion X-Mao-Original-Outgoing-Id: 592300255.881325-fe82cdbdd203abebd6b828cecf7d497a Content-Transfer-Encoding: quoted-printable Message-Id: <23153F7D-BA50-4F3A-9BFB-60F06BC0A6D0@tzi.org> References: <082EE9F1-D4AA-487F-BB8C-08CDB59C5A2F@vigilsec.com> <02046145-9455-4C01-9F6E-246D3940C86E@tzi.org> <96647ed8-2627-4434-ad51-b373eadfade6@levkowetz.com> <347055CD-74C9-479B-B7FC-BA78580C37B5@tzi.org> To: Henrik Levkowetz X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Tools-discuss] [xml2rfc] [Rfc-markdown] End of support for xml2rfc on Python 2.x is coming soon X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2019 07:51:03 -0000 On Oct 9, 2019, at 01:15, Henrik Levkowetz wrote: >=20 > = http://tools.ietf.org/src/xml2rfc/trunk/cli/doc/xml2rfc3.html#processing-f= low Thank you! That is really useful. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Oct 9 07:23:09 2019 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 482B512084C; Wed, 9 Oct 2019 07:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 aLP3GvYvs2Oc; Wed, 9 Oct 2019 07:22:52 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4C64120220; Wed, 9 Oct 2019 07:22:52 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:59788 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1iICrZ-0001Zj-1E; Wed, 09 Oct 2019 07:22:50 -0700 To: =?UTF-8?Q?Martin_J._D=c3=bcrst?= , Job Snijders References: <082EE9F1-D4AA-487F-BB8C-08CDB59C5A2F@vigilsec.com> <858628DA-84DA-4982-89D7-D652E04ACA10@gmail.com> Cc: "xml2rfc-dev@ietf.org" , IETF , Tools Team Discussion , Fred Baker , "xml2rfc@ietf.org" , "rfc-markdown@ietf.org" From: Henrik Levkowetz Message-ID: <85192317-24ae-7f69-f523-ffc3f2400466@levkowetz.com> Date: Wed, 9 Oct 2019 16:22:40 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FqlQI9njEgxgCXv6R4VETnWhnWIB7Xkgw" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: rfc-markdown@ietf.org, xml2rfc@ietf.org, fredbaker.ietf@gmail.com, tools-discuss@ietf.org, ietf@ietf.org, xml2rfc-dev@ietf.org, job@instituut.net, duerst@it.aoyama.ac.jp X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Tools-discuss] [xml2rfc-dev] [xml2rfc] End of support for xml2rfc on Python 2.x is coming soon X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2019 14:23:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FqlQI9njEgxgCXv6R4VETnWhnWIB7Xkgw Content-Type: multipart/mixed; boundary="eXomrW96kEOg6D7xNR62HVfNgSPAGM9Si"; protected-headers="v1" From: Henrik Levkowetz To: =?UTF-8?Q?Martin_J._D=c3=bcrst?= , Job Snijders Cc: "xml2rfc-dev@ietf.org" , IETF , Tools Team Discussion , Fred Baker , "xml2rfc@ietf.org" , "rfc-markdown@ietf.org" Message-ID: <85192317-24ae-7f69-f523-ffc3f2400466@levkowetz.com> Subject: Re: [xml2rfc-dev] [xml2rfc] End of support for xml2rfc on Python 2.x is coming soon References: <082EE9F1-D4AA-487F-BB8C-08CDB59C5A2F@vigilsec.com> <858628DA-84DA-4982-89D7-D652E04ACA10@gmail.com> In-Reply-To: --eXomrW96kEOg6D7xNR62HVfNgSPAGM9Si Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Martin, On 2019-10-09 08:52, Martin J. D=C3=BCrst wrote: > On 2019/10/09 09:00, Job Snijders wrote: >=20 >> Between the name of the tool (note the 2 in "xlm2rfc"), the industry's= >> transition from python 2 to python 3, and IETF's transition from the >> v2 to the v3 RFC XML format, it is no surprise to me end users easily >> become confused. A simple strong message that python2 can't be used >> might be helpful, even if it appears somewhat unforgiving. >=20 > What about changing xml2rfc's name to xml3rfc? That way, xml3rfc, pytho= n=20 > 3, v3 of RFC XML, and pip3 would all align :-). True, but it would also break things for every person and script going to= the python package index to fetch the tool (https://pypi.org/project/xml2= rfc/) =2E.. ,:-) Best regards, Henrik --eXomrW96kEOg6D7xNR62HVfNgSPAGM9Si-- --FqlQI9njEgxgCXv6R4VETnWhnWIB7Xkgw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl2d7TAACgkQTptXS4+7 FxrAWhAA1koa/tbu5nqYkPvVJeRbwcD2kj3LjYqSCK7vFLFV52HQSeBzbR/eehiy KI/plVrbiVuIYNSfSp1CLz0HXEM0/LeynbbEAvmyMnxjkRIfxxWTyr1OA6+sQfjV Cr+GnxFenxlQWHZCtEef1r/mSqe/NGQYP3NmooX0NOJi6BhO+P1h9b2lnz/YTm2H sQuEAVaJaoLBMDlXJGlb/VTdcMN1h2mKzd300L19odrg40Ag61I1cZ1uSzOeLBw9 HWljl0WiO1Hvfl2qrLl6Pb0rpYu+rmmUuO6DWwgtR/W4EoYWQzrPGdmF4eIlSWle 8kcNju4wbB82rOFKSB17A+4crko5GT6DxWolgaTs6OsQRtYLXn7LBrfykDtjcFy4 m5IZQreA3BuuQnfNuGavEr0HFXaJTLkhpSUeNVX1SD8zxpVeGBP5BQZGEKU7yBi1 E0kwK1TfPlPJXRxqt4WZXLf65UoBn9sgiBVZNksMTWV5M2N9BaNjGNAZ0aUu6tNN OR4f7ziiuxtkBOz2LOntv1LZIWXjIgz0UMz7Invu+M08DDWV8LhDYVDyEJMb4rQh Z8xJ5sDzBwrXgLcKrIUARdMK+7AZIE1v2vlMdQyR//5TNx39lfgwotcH2QylrGzP jANcFGG7cf4vVtRCQ6YsV2js0cZ96/nHeuOYoiF/6c+IZLETGSM= =MGNA -----END PGP SIGNATURE----- --FqlQI9njEgxgCXv6R4VETnWhnWIB7Xkgw-- From nobody Wed Oct 9 08:33:02 2019 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C780120111 for ; Wed, 9 Oct 2019 08:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 XUxDCapERSqD for ; Wed, 9 Oct 2019 08:32:59 -0700 (PDT) Received: from server172-3.web-hosting.com (server172-3.web-hosting.com [68.65.122.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B75E12010E for ; Wed, 9 Oct 2019 08:32:59 -0700 (PDT) Received: from [146.96.19.240] (port=62377 helo=[10.10.201.23]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1iIDxL-002Zuo-Lp; Wed, 09 Oct 2019 11:32:57 -0400 From: Dave Rice Message-Id: <3650B5EF-A442-4291-928A-2FCB2144134C@dericed.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_B13FF9E8-B92E-48ED-9E91-CCA08AC0D130" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Wed, 9 Oct 2019 11:32:42 -0400 In-Reply-To: <3a8f5865-9f5c-8c65-63be-bca31c5f1c86@levkowetz.com> Cc: Michael Richardson , rfc-interest , tools-discuss@ietf.org To: Henrik Levkowetz References: <20285.1568652805@localhost> <705AA16B-68B1-4B5E-AE47-0714F6781C1A@dericed.com> <26105.1568818137@localhost> <1268.1568828850@localhost> <15814.1569013442@localhost> <3a8f5865-9f5c-8c65-63be-bca31c5f1c86@levkowetz.com> X-Mailer: Apple Mail (2.3445.104.8) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Tools-discuss] [rfc-i] Update: The transition to xml2rfc v3 (today!) (fwd) Heather Flanagan: Update: The transition to xml2rfc v3 (today!) X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2019 15:33:01 -0000 --Apple-Mail=_B13FF9E8-B92E-48ED-9E91-CCA08AC0D130 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks Henrik, > On Sep 20, 2019, at 5:26 PM, Henrik Levkowetz = wrote: >=20 > Hi Michael, David, >=20 > On 2019-09-20 23:04, Michael Richardson wrote: >>=20 >> Dave Rice wrote: >>> Another annoyance here is the the xml processor in the submission = tool >>> and the xml processor at >>> https://xml2rfc.tools.ietf.org/experimental.html >>> perform = differently, >>> so there=E2=80=99s effectively no test environment to use before = submitting. >>> Dave >>=20 >> Dave, can you please try xml2rfc.ietf.org, which is a different = installation, >> supported by a different entity? >=20 > Michael: Umm, no, that redirects to tools.ietf.org, too, and the = processor > behind that, and behind = https://xml2rfc.tools.ietf.org/experimental.html, > _and_ behind the submission tool are all the latest release of = xml2rfc. >=20 > David: I'd be happy to look into any discrepancies you see, but I can = only > do so if you provide observations and input XML files for me to work > with. It won't happen if I don't know about it :-) When I use the tool at https://xml2rfc.tools.ietf.org or = https://xml2rfc.tools.ietf.org/experimental.html, the plain text output = appears ok, but when I use https://datatracker.ietf.org/submit/ = , the contents of the = elements (which are new in xml2rfc version 3) have their line breaks = stripped out and thus cause an error when the line length limits are = exceeded. For the moment, I=E2=80=99m proposing a find and replace to convert the = newer elements back to elements as in = https://github.com/FFmpeg/FFV1/pull/171/commits/a018f091534678f45cc157bfd1= 54518ad6267c7e = , thus an xml2rfc version 2 processor or version 3 = processor should proceed accurate results though not as semantically = clear in the xml. > FWIW, if you have a tools.ietf.org login, you can use the xml2rfc = issue > tracker at https://trac.tools.ietf.org/tools/xml2rfc/trac/newticket, = for > xml2rfc issues, and https://trac.tools.ietf.org/tools/ietfdb/newticket > for datatracker issues. I don=E2=80=99t have a login, but I=E2=80=99ll see if I can make a tiny = test file for this issue and file a concise ticket. Dave= --Apple-Mail=_B13FF9E8-B92E-48ED-9E91-CCA08AC0D130 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks Henrik,

On Sep 20, 2019, at 5:26 PM, = Henrik Levkowetz <henrik@levkowetz.com> wrote:

Hi = Michael, David,

On 2019-09-20 23:04, = Michael Richardson wrote:

Dave Rice <dave@dericed.com> = wrote:
Another = annoyance here is the the xml processor in the submission tool
and the xml processor at
https://xml2rfc.tools.ietf.org/experimental.html
<https://xml2rfc.tools.ietf.org/experimental.html> = perform differently,
so there=E2=80=99s effectively no = test environment to use before submitting.
Dave

Dave, can you please try xml2rfc.ietf.org, which = is a different installation,
supported by a different = entity?

Michael:  Umm, = no, that redirects to tools.ietf.org, too, and the processor
behind= that, and behind https://xml2rfc.tools.ietf.org/experimental.html,
_and_ behind the submission tool are all the latest release = of xml2rfc.

David: I'd be happy to look = into any discrepancies you see, but I can only
do so if = you provide observations and input XML files for me to work
with.  It won't happen if I don't know about it :-)

When = I use the tool at https://xml2rfc.tools.ietf.org or https://xml2rfc.tools.ietf.org/experimental.html, the = plain text output appears ok, but when I use https://datatracker.ietf.org/submit/, the contents of the = <sourcecode> elements (which are new in xml2rfc version 3) have = their line breaks stripped out and thus cause an error when the line = length limits are exceeded.

For the = moment, I=E2=80=99m proposing a find and replace to convert the newer = <sourcecode> elements back to <artwork> elements as = in https://github.com/FFmpeg/FFV1/pull/171/commits/a018f091534678f= 45cc157bfd154518ad6267c7e, thus an xml2rfc version 2 processor or = version 3 processor should proceed accurate results though not as = semantically clear in the xml.

FWIW, if you = have a tools.ietf.org = login, you can use the xml2rfc issue
tracker at https://trac.tools.ietf.org/tools/xml2rfc/trac/newticket, = for
xml2rfc issues, and https://trac.tools.ietf.org/tools/ietfdb/newticket
for datatracker issues.

I= don=E2=80=99t have a login, but I=E2=80=99ll see if I can make a tiny = test file for this issue and file a concise ticket.
Dave
= --Apple-Mail=_B13FF9E8-B92E-48ED-9E91-CCA08AC0D130-- From nobody Wed Oct 9 10:38:45 2019 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A73211208E4 for ; Wed, 9 Oct 2019 10:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.096 X-Spam-Level: X-Spam-Status: No, score=-1.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=no 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 AgT-xqFr5Vo7 for ; Wed, 9 Oct 2019 10:38:42 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 213211208D7 for ; Wed, 9 Oct 2019 10:38:42 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:60690 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1iIFv6-0006m1-2e; Wed, 09 Oct 2019 10:38:40 -0700 To: Dave Rice References: <20285.1568652805@localhost> <705AA16B-68B1-4B5E-AE47-0714F6781C1A@dericed.com> <26105.1568818137@localhost> <1268.1568828850@localhost> <15814.1569013442@localhost> <3a8f5865-9f5c-8c65-63be-bca31c5f1c86@levkowetz.com> <3650B5EF-A442-4291-928A-2FCB2144134C@dericed.com> Cc: Michael Richardson , rfc-interest , tools-discuss@ietf.org From: Henrik Levkowetz Message-ID: <06122b6d-d5f9-30b9-2db4-a2427d299a1f@levkowetz.com> Date: Wed, 9 Oct 2019 19:38:31 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <3650B5EF-A442-4291-928A-2FCB2144134C@dericed.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fHE6MfmwjTpGvTo5Dmi8bhv2BHbS9gwsd" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: tools-discuss@ietf.org, rfc-interest@rfc-editor.org, mcr+ietf@sandelman.ca, dave@dericed.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Tools-discuss] [rfc-i] Update: The transition to xml2rfc v3 (today!) (fwd) Heather Flanagan: Update: The transition to xml2rfc v3 (today!) X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2019 17:38:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fHE6MfmwjTpGvTo5Dmi8bhv2BHbS9gwsd Content-Type: multipart/mixed; boundary="4cXqtUWhC6ChdAG4rcTjjhxKSVXikQq88"; protected-headers="v1" From: Henrik Levkowetz To: Dave Rice Cc: Michael Richardson , rfc-interest , tools-discuss@ietf.org Message-ID: <06122b6d-d5f9-30b9-2db4-a2427d299a1f@levkowetz.com> Subject: Re: [rfc-i] Update: The transition to xml2rfc v3 (today!) (fwd) Heather Flanagan: Update: The transition to xml2rfc v3 (today!) References: <20285.1568652805@localhost> <705AA16B-68B1-4B5E-AE47-0714F6781C1A@dericed.com> <26105.1568818137@localhost> <1268.1568828850@localhost> <15814.1569013442@localhost> <3a8f5865-9f5c-8c65-63be-bca31c5f1c86@levkowetz.com> <3650B5EF-A442-4291-928A-2FCB2144134C@dericed.com> In-Reply-To: <3650B5EF-A442-4291-928A-2FCB2144134C@dericed.com> --4cXqtUWhC6ChdAG4rcTjjhxKSVXikQq88 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi David, On 2019-10-09 17:32, Dave Rice wrote: > Thanks Henrik, >=20 >> On Sep 20, 2019, at 5:26 PM, Henrik Levkowetz w= rote: >>=20 >> Hi Michael, David, >>=20 >> On 2019-09-20 23:04, Michael Richardson wrote: >>>=20 >>> Dave Rice wrote: >>>> Another annoyance here is the the xml processor in the submission to= ol >>>> and the xml processor at >>>> https://xml2rfc.tools.ietf.org/experimental.html >>>> perform different= ly, >>>> so there=E2=80=99s effectively no test environment to use before sub= mitting. >>>> Dave >>>=20 >>> Dave, can you please try xml2rfc.ietf.org, which is a different insta= llation, >>> supported by a different entity? >>=20 >> Michael: Umm, no, that redirects to tools.ietf.org, too, and the proc= essor >> behind that, and behind https://xml2rfc.tools.ietf.org/experimental.ht= ml, >> _and_ behind the submission tool are all the latest release of xml2rfc= =2E >>=20 >> David: I'd be happy to look into any discrepancies you see, but I can = only >> do so if you provide observations and input XML files for me to work >> with. It won't happen if I don't know about it :-) >=20 > When I use the tool at https://xml2rfc.tools.ietf.org or > https://xml2rfc.tools.ietf.org/experimental.html, the plain text > output appears ok, but when I use > https://datatracker.ietf.org/submit/ > , the contents of the > elements (which are new in xml2rfc version 3) have their > line breaks stripped out and thus cause an error when the line length > limits are exceeded. That sounds like a bug. > For the moment, I=E2=80=99m proposing a find and replace to convert the= newer > elements back to elements as in > https://github.com/FFmpeg/FFV1/pull/171/commits/a018f091534678f45cc157b= fd154518ad6267c7e > , > thus an xml2rfc version 2 processor or version 3 processor should > proceed accurate results though not as semantically clear in the > xml. >=20 >> FWIW, if you have a tools.ietf.org login, you can use the xml2rfc >> issue >> tracker at https://trac.tools.ietf.org/tools/xml2rfc/trac/newticket, f= or >> xml2rfc issues, and https://trac.tools.ietf.org/tools/ietfdb/newticket= >> for datatracker issues. >=20 > I don=E2=80=99t have a login, but I=E2=80=99ll see if I can make a tiny= test file for this issue and file a concise ticket. Please don't put time into this; I'm perfectly happy to work from the xml= file you found problematic on submission. Just let me know the name of t= he draft in question, so I can pull it. Best regards, Henrik --4cXqtUWhC6ChdAG4rcTjjhxKSVXikQq88-- --fHE6MfmwjTpGvTo5Dmi8bhv2BHbS9gwsd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl2eGxgACgkQTptXS4+7 Fxp2Gg//femS93I+mnuQdUqK60OLHGKXwZSIYVWZ57Jc+Vvvj2Z2xTlrm1XZJ0G/ 2o07i+h62nFKEfH17Ly0+DeMaG9FOzsvJhMaoOApoDMw/46D0ZyqiyxrkPDFHkZT bBLhrbxFjJlBPJU9M9NLX0S1sYnuyEXQHbyHH1jkulRFboCbHGo3ZrpUD2l+7tE8 IBQdmNzIzJat8p/YNSdI+MJc1XL+EJ+NYpqXVjhMuAnlQq3Q+BbX34l9LSUsjtYH A9zonZaxBXiNj1CK5q0TdPGWVTdg7KEIdzz7j9gbZqNawh8U0tJYrcBAhCLcdvjd aEmVWizwLmF+tOm1sUMawoEGgMyElCsUrWav74cBAJ8y9O6XFIQZUmywRM9/AbyS y5isN0ZBT0laPA0dVKKcmu/f7TMapL/dObUne82pGVgdanGcxCEnA5zD44IitSYF gSxP7vjSu5wyP45xsHXHB+TNh4Q7KKZ5uKawevf5Nria4mreZ6I4Uf9wXW4Co09b qll9ia4uZ0+DM7OWtEKaBhqkYONrNIZeGDR2Qb/FPXSa5uWuYx76Ep46+fTtUjLz u5qXAMwHTZggXtnGoqk2+FCFazK3YTqi6p1tdon22xaYZbA6JOtd5MjKTJxGGNtQ UNYEIsQnv/cXmCmFOBhT4Fe0OvSttBX1WcBaperB3BpYkrdOS6o= =WxAA -----END PGP SIGNATURE----- --fHE6MfmwjTpGvTo5Dmi8bhv2BHbS9gwsd-- From nobody Wed Oct 9 10:47:41 2019 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04EB3120A16 for ; Wed, 9 Oct 2019 10:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 76lQxAnaagC2 for ; Wed, 9 Oct 2019 10:47:35 -0700 (PDT) Received: from server172-3.web-hosting.com (server172-3.web-hosting.com [68.65.122.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BBFD120A14 for ; Wed, 9 Oct 2019 10:47:34 -0700 (PDT) Received: from [146.96.19.240] (port=21167 helo=[10.10.201.23]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1iIG3b-0046Oy-Hd; Wed, 09 Oct 2019 13:47:33 -0400 From: Dave Rice Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_4E082775-84E4-45D9-ACAE-9A4C132D8DC2" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Wed, 9 Oct 2019 13:47:18 -0400 In-Reply-To: <06122b6d-d5f9-30b9-2db4-a2427d299a1f@levkowetz.com> Cc: Michael Richardson , rfc-interest , tools-discuss@ietf.org To: Henrik Levkowetz References: <20285.1568652805@localhost> <705AA16B-68B1-4B5E-AE47-0714F6781C1A@dericed.com> <26105.1568818137@localhost> <1268.1568828850@localhost> <15814.1569013442@localhost> <3a8f5865-9f5c-8c65-63be-bca31c5f1c86@levkowetz.com> <3650B5EF-A442-4291-928A-2FCB2144134C@dericed.com> <06122b6d-d5f9-30b9-2db4-a2427d299a1f@levkowetz.com> X-Mailer: Apple Mail (2.3445.104.8) X-OutGoing-Spam-Status: No, score=-2.6 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Tools-discuss] [rfc-i] Update: The transition to xml2rfc v3 (today!) (fwd) Heather Flanagan: Update: The transition to xml2rfc v3 (today!) X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2019 17:47:38 -0000 --Apple-Mail=_4E082775-84E4-45D9-ACAE-9A4C132D8DC2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Henrik, > On Oct 9, 2019, at 1:38 PM, Henrik Levkowetz = wrote: >=20 > Hi David, >=20 > On 2019-10-09 17:32, Dave Rice wrote: >> Thanks Henrik, >>=20 >>> On Sep 20, 2019, at 5:26 PM, Henrik Levkowetz = wrote: >>>=20 >>> Hi Michael, David, >>>=20 >>> On 2019-09-20 23:04, Michael Richardson wrote: >>>>=20 >>>> Dave Rice wrote: >>>>> Another annoyance here is the the xml processor in the submission = tool >>>>> and the xml processor at >>>>> https://xml2rfc.tools.ietf.org/experimental.html >>>>> perform = differently, >>>>> so there=E2=80=99s effectively no test environment to use before = submitting. >>>>> Dave >>>>=20 >>>> Dave, can you please try xml2rfc.ietf.org, which is a different = installation, >>>> supported by a different entity? >>>=20 >>> Michael: Umm, no, that redirects to tools.ietf.org, too, and the = processor >>> behind that, and behind = https://xml2rfc.tools.ietf.org/experimental.html, >>> _and_ behind the submission tool are all the latest release of = xml2rfc. >>>=20 >>> David: I'd be happy to look into any discrepancies you see, but I = can only >>> do so if you provide observations and input XML files for me to work >>> with. It won't happen if I don't know about it :-) >>=20 >=20 >> When I use the tool at https://xml2rfc.tools.ietf.org or >> https://xml2rfc.tools.ietf.org/experimental.html, the plain text >> output appears ok, but when I use >> https://datatracker.ietf.org/submit/ >> >, the contents of the >> elements (which are new in xml2rfc version 3) have their >> line breaks stripped out and thus cause an error when the line length >> limits are exceeded. >=20 > That sounds like a bug. >=20 >> For the moment, I=E2=80=99m proposing a find and replace to convert = the newer >> elements back to elements as in >> = https://github.com/FFmpeg/FFV1/pull/171/commits/a018f091534678f45cc157bfd1= 54518ad6267c7e = >> = >, >> thus an xml2rfc version 2 processor or version 3 processor should >> proceed accurate results though not as semantically clear in the >> xml. >>=20 >>> FWIW, if you have a tools.ietf.org login, = you can use the xml2rfc >>> issue >>> tracker at https://trac.tools.ietf.org/tools/xml2rfc/trac/newticket = , for >>> xml2rfc issues, and = https://trac.tools.ietf.org/tools/ietfdb/newticket = >>> for datatracker issues. >>=20 >> I don=E2=80=99t have a login, but I=E2=80=99ll see if I can make a = tiny test file for this issue and file a concise ticket. >=20 > Please don't put time into this; I'm perfectly happy to work from the = xml > file you found problematic on submission. Just let me know the name = of the > draft in question, so I can pull it. The draft at https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/ = . The current = version, 09, has several sections where the content of = elements exceed the line length in txt renderings, such as in = https://www.ietf.org/id/draft-ietf-cellar-ffv1-09.txt = . For example, this in the xml: >
> Level Coding > Level coding is identical to the normal difference = coding with the exception that the 0 value is removed as it cannot = occur: > diff =3D = get_vlc_symbol(context_state); > if (diff >=3D 0) { > diff++; > } > > Note, this is different from JPEG-LS, which doesn=E2=80= =99t use prediction in run mode and uses a different encoding and = context model for the last difference On a small set of test = Samples the use of prediction slightly improved the compression = rate. >
will become this in the output txt: > 3.8.2.2.2. Level Coding >=20 > Level coding is identical to the normal difference coding with the > exception that the 0 value is removed as it cannot occur: >=20 > diff =3D get_vlc_symbol(context_state); if (diff >=3D 0) { diff++; = } >=20 > Note, this is different from JPEG-LS, which doesn't use prediction = in > run mode and uses a different encoding and context model for the = last >=20 >=20 >=20 > Niedermayer, et al. Expires March 9, 2020 [Page = 21] > =0C > Internet-Draft FFV1 September = 2019 >=20 >=20 > difference On a small set of test "Samples" the use of prediction > slightly improved the compression rate. I=E2=80=99m adding underlines to these to show where the line returns = are lost. In this case it doesn=E2=80=99t result in exceeding the line = length but in most it does. I can workaround this issue by change the = element to . Dave Rice --Apple-Mail=_4E082775-84E4-45D9-ACAE-9A4C132D8DC2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Henrik,

On Oct 9, 2019, at 1:38 PM, Henrik Levkowetz = <henrik@levkowetz.com> wrote:

Hi David,

On 2019-10-09 17:32, Dave Rice = wrote:
Thanks = Henrik,

On Sep 20, 2019, at 5:26 PM, Henrik Levkowetz <henrik@levkowetz.com> wrote:

Hi Michael, David,

On 2019-09-20 = 23:04, Michael Richardson wrote:

Dave Rice <dave@dericed.com> = wrote:
Another = annoyance here is the the xml processor in the submission tool
and the xml processor at
https://xml2rfc.tools.ietf.org/experimental.html
<https://xml2rfc.tools.ietf.org/experimental.html> = perform differently,
so there=E2=80=99s effectively no = test environment to use before submitting.
Dave

Dave, can you please try xml2rfc.ietf.org, which = is a different installation,
supported by a different = entity?

Michael:  Umm, = no, that redirects to tools.ietf.org, too, and the processor
behind= that, and behind https://xml2rfc.tools.ietf.org/experimental.html,
_and_ behind the submission tool are all the latest release = of xml2rfc.

David: I'd be happy to look = into any discrepancies you see, but I can only
do so if = you provide observations and input XML files for me to work
with.  It won't happen if I don't know about it :-)


When = I use the tool at https://xml2rfc.tools.ietf.org or
https://xml2rfc.tools.ietf.org/experimental.html, the = plain text
output appears ok, but when I use
https://datatracker.ietf.org/submit/
<https://datatracker.ietf.org/submit/>, the contents of = the
<sourcecode> elements (which are new in xml2rfc = version 3) have their
line breaks stripped out and thus = cause an error when the line length
limits are = exceeded.

That sounds like a bug.

For the moment, I=E2=80=99m proposing = a find and replace to convert the newer
<sourcecode> = elements back to <artwork> elements as in
https://github.com/FFmpeg/FFV1/pull/171/commits/a018f091534678f= 45cc157bfd154518ad6267c7e
<https://github.com/FFmpeg/FFV1/pull/171/commits/a018f091534678f= 45cc157bfd154518ad6267c7e>,
thus an xml2rfc version = 2 processor or version 3 processor should
proceed accurate = results though not as semantically clear in the
xml.

FWIW, if = you have a tools.ietf.org login, you can use the = xml2rfc
issue
tracker at https://trac.tools.ietf.org/tools/xml2rfc/trac/newticket, = for
xml2rfc issues, and https://trac.tools.ietf.org/tools/ietfdb/newticket
for datatracker issues.

I don=E2=80=99t have a login, but I=E2=80=99ll see if I can = make a tiny test file for this issue and file a concise ticket.

Please don't put time into this; I'm perfectly happy to work = from the xml
file you = found problematic on submission.  Just let me know the name of = the
draft in = question, so I can pull it.

The draft at https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/. = The current version, 09, has several sections where the content of = <sourcecode> elements exceed the line length in txt renderings, = such as in https://www.ietf.org/id/draft-ietf-cellar-ffv1-09.txt.

For example, this = in the xml:

<section anchor=3D"level-coding">
              = <name>Level Coding</name>
    =           <t>Level coding is identical to = the normal difference coding with the exception that the 0 value is = removed as it cannot occur:</t>
    =           <sourcecode type=3D"c">    diff =3D = get_vlc_symbol(context_state);
    if (diff &gt;=3D 0) {
        = diff++;
    = }
</sourcecode>
              = <t>Note, this is different from JPEG-LS, which doesn=E2=80=99t use = prediction in run mode and uses a different encoding and context model = for the last difference On a small set of test = <tt>Samples</tt> the use of prediction slightly improved the = compression rate.</t>
      =       </section>

will become this in the = output txt:
3.8.2.2.2. =
 Level Coding

   Level coding is identical to the normal difference coding with the
   exception that the 0 value is removed as it cannot occur:

   diff =3D get_vlc_symbol(context_state); if (diff >=3D =
0) { diff++; }

   Note, this is different from JPEG-LS, which doesn't use prediction in
   run mode and uses a different encoding and context model for the last



Niedermayer, et al.       Expires March 9, 2020                [Page 21]
=0C
Internet-Draft                    FFV1                    September 2019


   difference On a small set of test "Samples" the use of prediction
   slightly improved the compression rate.

I=E2=80=99m adding =
underlines to these to show where the line returns are lost. In this =
case it doesn=E2=80=99t result in exceeding the line length but in most =
it does. I can workaround this issue by change the <sourcecode =
type=3D=E2=80=9Cc"> element to <artwork =
type=3D=E2=80=9Cascii-art=E2=80=9D>.

Dave Rice

=

--Apple-Mail=_4E082775-84E4-45D9-ACAE-9A4C132D8DC2--


From nobody Wed Oct  9 13:42:21 2019
Return-Path: 
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3AA12004F; Wed,  9 Oct 2019 13:42:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, 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 c8hR69fbzc6m; Wed,  9 Oct 2019 13:42:18 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78C31120B33; Wed,  9 Oct 2019 13:42:16 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1iIImj-00050Y-SU; Wed, 09 Oct 2019 20:42:14 +0000
Date: Wed, 09 Oct 2019 13:42:13 -0700
Message-ID: 
From: Randy Bush 
To: Henrik Levkowetz 
Cc: Tools Team Discussion , xml2rfc@ietf.org, xml2rfc-dev@ietf.org
In-Reply-To: <96647ed8-2627-4434-ad51-b373eadfade6@levkowetz.com>
References: <082EE9F1-D4AA-487F-BB8C-08CDB59C5A2F@vigilsec.com> <02046145-9455-4C01-9F6E-246D3940C86E@tzi.org> <96647ed8-2627-4434-ad51-b373eadfade6@levkowetz.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.2 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Archived-At: 
Subject: Re: [Tools-discuss] [xml2rfc] [Rfc-markdown] End of support for xml2rfc on Python 2.x is coming soon
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Oct 2019 20:42:20 -0000

[ bunch of cc:s removed ]

will xml2rfc.app, the mac gooey, be maintained in any way.  v3?  64-bit?

randy


From nobody Wed Oct  9 14:50:06 2019
Return-Path: 
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0E1112084F; Wed,  9 Oct 2019 14:50:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.096
X-Spam-Level: 
X-Spam-Status: No, score=-1.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=no 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 ReYDgVpujpVx; Wed,  9 Oct 2019 14:50:02 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C33A120043; Wed,  9 Oct 2019 14:50:02 -0700 (PDT)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:62099 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1iIJqL-00089c-KZ; Wed, 09 Oct 2019 14:50:01 -0700
To: Randy Bush 
References: <082EE9F1-D4AA-487F-BB8C-08CDB59C5A2F@vigilsec.com> <02046145-9455-4C01-9F6E-246D3940C86E@tzi.org> <96647ed8-2627-4434-ad51-b373eadfade6@levkowetz.com> 
Cc: Tools Team Discussion , xml2rfc@ietf.org, xml2rfc-dev@ietf.org
From: Henrik Levkowetz 
Message-ID: <44a4ffdf-83c1-50ff-cd5d-a186abfc4d24@levkowetz.com>
Date: Wed, 9 Oct 2019 23:49:52 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5TSlk0u5SJfDkQQA29sOApmNhWHrjSkNI"
X-SA-Exim-Connect-IP: 158.174.202.242
X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, xml2rfc@ietf.org, tools-discuss@ietf.org, randy@psg.com
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org)
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: 
Subject: Re: [Tools-discuss] [xml2rfc] [Rfc-markdown] End of support for xml2rfc on Python 2.x is coming soon
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Oct 2019 21:50:04 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--5TSlk0u5SJfDkQQA29sOApmNhWHrjSkNI
Content-Type: multipart/mixed; boundary="q32MHu9rovxqvhl8elDaIxxrBhmlKg84d";
 protected-headers="v1"
From: Henrik Levkowetz 
To: Randy Bush 
Cc: Tools Team Discussion , xml2rfc@ietf.org,
 xml2rfc-dev@ietf.org
Message-ID: <44a4ffdf-83c1-50ff-cd5d-a186abfc4d24@levkowetz.com>
Subject: Re: [xml2rfc] [Rfc-markdown] End of support for xml2rfc on Python 2.x
 is coming soon
References: <082EE9F1-D4AA-487F-BB8C-08CDB59C5A2F@vigilsec.com>
 <02046145-9455-4C01-9F6E-246D3940C86E@tzi.org>
 <96647ed8-2627-4434-ad51-b373eadfade6@levkowetz.com>
 
In-Reply-To: 

--q32MHu9rovxqvhl8elDaIxxrBhmlKg84d
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Randy,

On 2019-10-09 22:42, Randy Bush wrote:
> [ bunch of cc:s removed ]
>=20
> will xml2rfc.app, the mac gooey, be maintained in any way.  v3?  64-bit=
?

I don't expect so.  It's not been updated in ages, and even if it runs
xml2rfc under the hood, it knows nothing of the new switches.


Best regards,

	Henrik


--q32MHu9rovxqvhl8elDaIxxrBhmlKg84d--

--5TSlk0u5SJfDkQQA29sOApmNhWHrjSkNI
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl2eVgEACgkQTptXS4+7
Fxqhug/9GrA6b6X8xuZ94ViX+vMl7pnH6GX4o+nvCI9kQpVtjJYtu/Rp1CrgrzJt
N2YQz0NPkNLL234FYgDnVz0uO3g3sDIy3b7fw7aMHvsApqxCD/nsSFibZrnRBD7r
DZPbT5ame3bQHWCs9CeRBRmTGPXQx9/07/HShhPLflh4pM+6bSK8Uu5YrZ3kceKU
0KDAB969Mr6Ac9I/Cwx1RC8wX54DdS62aUgy2sPDvcQu59pMDVpldb50DPdWquk9
jAcLQXr8vOaBvcAcquFpfRpljOp9/kpfXP0i36HcBIm/1EtGFUhyZCyIOFTHXZDg
Sv3xl6pqaUyhKAQzdI89n6nfOLchEjfkIDKZ0jCHiCp8HvPqc3+/gdRvl+QsLrK/
BfZQ8EomOE0vqJvKOfJH7AdaajtAD06fei09Zr67i9LBzBBEQSzFG/7wHxrZ8Mgb
vYL9zJ0kx6mq3UY+ofIDilMUSDfCELR2iYJB1YME1sqBtHEovWDr4aUo8sU+oX9K
7/joau26KCDbyKaDPk6imCrk1cxp3t+56O5rQMXII3ypoOmKOtyYuX1A4GJkixKN
NTX7dWvuiWlsgxZF1fHhPZr899DFsQ+DJUdWmlIkdorc+D7cOIcY+ST8QLymQg/g
lgSKGS+PTYBgtuw0b6hfmZQ1oYvinVBzvBnqPe6RKBtsVZOkBAw=
=PCLE
-----END PGP SIGNATURE-----

--5TSlk0u5SJfDkQQA29sOApmNhWHrjSkNI--


From nobody Thu Oct 10 05:50:05 2019
Return-Path: 
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA8611200E7; Thu, 10 Oct 2019 05:49:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 ewMq3BuYxmf9; Thu, 10 Oct 2019 05:49:48 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C4E3120018; Thu, 10 Oct 2019 05:49:47 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 4CD2C6212D; Thu, 10 Oct 2019 08:49:46 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xc4IzpA0RaZM; Thu, 10 Oct 2019 08:49:42 -0400 (EDT)
Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 2E31F62124; Thu, 10 Oct 2019 08:49:38 -0400 (EDT)
To: Carsten Bormann , Henrik Levkowetz 
Cc: RFC Markdown , XML2RFC Interest Group , xml2rfc-dev@ietf.org, IETF , Tools Team Discussion 
References: <082EE9F1-D4AA-487F-BB8C-08CDB59C5A2F@vigilsec.com> <02046145-9455-4C01-9F6E-246D3940C86E@tzi.org> <96647ed8-2627-4434-ad51-b373eadfade6@levkowetz.com> <347055CD-74C9-479B-B7FC-BA78580C37B5@tzi.org>
From: Robert Moskowitz 
Message-ID: 
Date: Thu, 10 Oct 2019 08:49:35 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0
MIME-Version: 1.0
In-Reply-To: <347055CD-74C9-479B-B7FC-BA78580C37B5@tzi.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Tools-discuss] [xml2rfc] [Rfc-markdown] End of support for xml2rfc on Python 2.x is coming soon
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Oct 2019 12:49:50 -0000

On 10/8/19 6:46 PM, Carsten Bormann wrote:
> On Oct 9, 2019, at 00:18, Henrik Levkowetz  wrote:
>> Signed PGP part
>> Hi Carsten,
>>
>> On 2019-10-08 23:48, Carsten Bormann wrote:
>>> On Oct 8, 2019, at 23:23, Russ Housley  wrote:
>>>> (2) The default output formatters will change to v3.  The v2 formatters
>>>>    will still be available by using a --legacy switch.
>>> Please do this in a way that will not randomly break scripts and
>>> other programs that need to run xml2rfc. (A calling script/program
>>> has no idea what version of xml2rfc is installed locally.) [Actually,
>>> that is also true of people calling xml2rfc…]
>> Does it work for you if we say 'if you want v2 output, please add --legacy
>> to your scripts already now’?
> It sure works for me, but I don’t know all the other users of my software.
>
>> The --legacy switch to force v2 output (for compatible input) has been
>> available for around 6 months, so even if you don't have the bleeding
>> edge version installed, this should work as a compatibility path, I think?
> 6 months is very short in the grand scheme of things.
>
> Generally people will upgrade tools like kramdown-rfc and xml2rfc on different timelines.
> (And there are also a few hundred makefiles in some repositories somewhere that call xml2rfc.)
>
> With that out of the way, I must admit I don’t even understand what this means:
>
>    Format Options:
>      --v3                                with --text and --html: use the v3
>                                          formatter, rather than the legacy one.
>      --legacy                            with --text and --html: use the legacy
>                                          text formatter, rather than the v3
>                                          one.
>
> Does the choice of “legacy” and “v3” formatter have an influence on the accepted XML vocabulary?  On the output format?  Both?  How?

I have encounter:

draft-moskowitz-hip-new-crypto-02.xml(14): Warning: Setting 
consensus="true" for IETF STD document (this is not the schema default, 
but is the only value permitted for this type of document)
  Created file draft-moskowitz-hip-new-crypto-02.txt

when using the--v3 switch.

I have been told not to worry about this, but so far I have not found 
any documentation on "consensus".



From nobody Thu Oct 10 06:00:10 2019
Return-Path: 
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C7C1201DE; Thu, 10 Oct 2019 06:00:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.095
X-Spam-Level: 
X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 UFRhiUbOuM2V; Thu, 10 Oct 2019 06:00:01 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A554120170; Thu, 10 Oct 2019 06:00:01 -0700 (PDT)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:53794 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1iIY2x-0003Lf-Br; Thu, 10 Oct 2019 05:59:59 -0700
To: Robert Moskowitz , Carsten Bormann 
References: <082EE9F1-D4AA-487F-BB8C-08CDB59C5A2F@vigilsec.com> <02046145-9455-4C01-9F6E-246D3940C86E@tzi.org> <96647ed8-2627-4434-ad51-b373eadfade6@levkowetz.com> <347055CD-74C9-479B-B7FC-BA78580C37B5@tzi.org> 
Cc: RFC Markdown , XML2RFC Interest Group , xml2rfc-dev@ietf.org, IETF , Tools Team Discussion 
From: Henrik Levkowetz 
Message-ID: <2383ca8d-efde-168b-3485-597b25ba6782@levkowetz.com>
Date: Thu, 10 Oct 2019 14:59:50 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HHeSmouxCXP9DT0tKgiuf0DnNVIcOCIri"
X-SA-Exim-Connect-IP: 158.174.202.242
X-SA-Exim-Rcpt-To: tools-discuss@ietf.org, ietf@ietf.org, xml2rfc-dev@ietf.org, xml2rfc@ietf.org, rfc-markdown@ietf.org, cabo@tzi.org, rgm@htt-consult.com
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org)
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: 
Subject: Re: [Tools-discuss] [xml2rfc] [Rfc-markdown] End of support for xml2rfc on Python 2.x is coming soon
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Oct 2019 13:00:03 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--HHeSmouxCXP9DT0tKgiuf0DnNVIcOCIri
Content-Type: multipart/mixed; boundary="NMcqutEeApLoRNPSfeb6k9oNaWR0Kja7v";
 protected-headers="v1"
From: Henrik Levkowetz 
To: Robert Moskowitz , Carsten Bormann 
Cc: RFC Markdown ,
 XML2RFC Interest Group , xml2rfc-dev@ietf.org,
 IETF , Tools Team Discussion 
Message-ID: <2383ca8d-efde-168b-3485-597b25ba6782@levkowetz.com>
Subject: Re: [Tools-discuss] [xml2rfc] [Rfc-markdown] End of support for
 xml2rfc on Python 2.x is coming soon
References: <082EE9F1-D4AA-487F-BB8C-08CDB59C5A2F@vigilsec.com>
 <02046145-9455-4C01-9F6E-246D3940C86E@tzi.org>
 <96647ed8-2627-4434-ad51-b373eadfade6@levkowetz.com>
 <347055CD-74C9-479B-B7FC-BA78580C37B5@tzi.org>
 
In-Reply-To: 

--NMcqutEeApLoRNPSfeb6k9oNaWR0Kja7v
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Bob,

On 2019-10-10 14:49, Robert Moskowitz wrote:
>=20
> I have encounter:
>=20
> draft-moskowitz-hip-new-crypto-02.xml(14): Warning: Setting=20
> consensus=3D"true" for IETF STD document (this is not the schema defaul=
t,=20
> but is the only value permitted for this type of document)
>   Created file draft-moskowitz-hip-new-crypto-02.txt
>=20
> when using the--v3 switch.
>=20
> I have been told not to worry about this, but so far I have not found=20
> any documentation on "consensus".\

See:

	https://tools.ietf.org/html/rfc7749#appendix-A.4
	https://tools.ietf.org/html/rfc7991#section-2.45.2


Best regards,

	Henrik


--NMcqutEeApLoRNPSfeb6k9oNaWR0Kja7v--

--HHeSmouxCXP9DT0tKgiuf0DnNVIcOCIri
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl2fK0YACgkQTptXS4+7
FxoV7RAAoMZ9VQye26UJE6RCx7UZ+LyFOBzAP57LKyCCfEyOQJmfZQr3fscbUV9l
2a7c8TJ04KT7mwjSeFthhjN+NjU3DOxKz9ouGCUcLWI8q54bs4PeqgkyjSsjscCg
DPaWuPxCwiMbesXZ59u1NVwcpMoBPz0eWCatdATAB71OoJWuvbronNb9oQrcc09B
QpxYYesP+HLv5KNAE5EoJ2uU5NauUct8sjNTKDtbWox5qUmlEdg3swwcDzdwfrEa
y8I/o85FwpxRo+0mWIgMC19Li/zjwJg2J7z1BLAGGM6QFVLWaB4AtfOw7lifpRQ0
tOjIU0HjMB1GFTlchis/VNt7fQDOMy0iaiTznoWCFnpRh7rgLQjJ70vJN/cjp8MK
7sQIXEXIWeGCUgAQGJiVe/GX8PycyKFsn8AyJXF6knnSxG1S/Owes8OA4wKiY/Zf
43AxKanFEsNve4VOWjFN3QmudbGHn/cg1JZtGOlwiOJ+CcWIlPElLhtTK+CjPM9f
z9/XxxNorX+KIrvNGuByQmWS7psphdhdLAPjCV2R+fpL2usdAz10yRi5mvPSgkMo
qvgwOrvJmhUigQxx9S+Sg5SNhFwzkXM21Wawb2kBolMTTRrhyR3nkUJcyK/sGXgC
G5TGybGXmCnhMWFjFkgrrkxkvjIdiejbY5x9kVO6h6iVW+XknTU=
=WlL3
-----END PGP SIGNATURE-----

--HHeSmouxCXP9DT0tKgiuf0DnNVIcOCIri--


From nobody Thu Oct 10 06:12:40 2019
Return-Path: 
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAEF212002E; Thu, 10 Oct 2019 06:12:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 2KrwvO2LOlNT; Thu, 10 Oct 2019 06:12:36 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA6BD120026; Thu, 10 Oct 2019 06:12:36 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id BBC376211F; Thu, 10 Oct 2019 09:12:35 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id HqqMajTfPWN2; Thu, 10 Oct 2019 09:12:29 -0400 (EDT)
Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id CFC726211C; Thu, 10 Oct 2019 09:12:25 -0400 (EDT)
To: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= , Job Snijders , Henrik Levkowetz 
Cc: "xml2rfc-dev@ietf.org" , IETF , Tools Team Discussion , "xml2rfc@ietf.org" , "rfc-markdown@ietf.org" 
References: <082EE9F1-D4AA-487F-BB8C-08CDB59C5A2F@vigilsec.com> <858628DA-84DA-4982-89D7-D652E04ACA10@gmail.com>   
From: Robert Moskowitz 
Message-ID: <7c90f3be-901c-ff3a-ff68-b226d9084592@htt-consult.com>
Date: Thu, 10 Oct 2019 09:12:20 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Tools-discuss] [xml2rfc] [xml2rfc-dev] End of support for xml2rfc on Python 2.x is coming soon
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Oct 2019 13:12:38 -0000

On 10/9/19 2:52 AM, Martin J. Dürst wrote:
> On 2019/10/09 09:00, Job Snijders wrote:
>
>> Between the name of the tool (note the 2 in "xlm2rfc"), the industry's
>> transition from python 2 to python 3, and IETF's transition from the
>> v2 to the v3 RFC XML format, it is no surprise to me end users easily
>> become confused. A simple strong message that python2 can't be used
>> might be helpful, even if it appears somewhat unforgiving.
> What about changing xml2rfc's name to xml3rfc? That way, xml3rfc, python
> 3, v3 of RFC XML, and pip3 would all align :-).

because it is suppose to be translated as "xml formatting TO RFC 
formatting"?

And there is some confusion?  It was xml2rfc back in v1.

Finally who remembers that originally it was called Blutooth after King 
Harald Blutooth?  (or somesuch spelling), and despite considerable 
documentation as to the origin of the name, the press won and it became 
Bluetooth?

:)



From nobody Thu Oct 10 06:22:41 2019
Return-Path: 
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E56120099; Thu, 10 Oct 2019 06:22:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 3W648m_BTGfJ; Thu, 10 Oct 2019 06:22:16 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 B7B16120026; Thu, 10 Oct 2019 06:22:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1570713707; bh=rdWLgoEI8IZsEkIAggGEBLn6IN5zv8pS3N+EdUzweBc=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=OGr9+bK9LCEth32QUIa7+YkXeHZd3JelKlzt95Tf0+UkHOERJAhDrFK2wJHX7KAZ7 cvs2UgEXsrKHbJ3ZIx449Q5k9L8JW7sIviyTVOpcONSpcxa2lG8vRlpfB5o6uVxER+ wHq6m8MPBExtgIpZH3tGhuMa6k2V7abFjwpP9GnE=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.124] ([84.171.147.247]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1Mt79F-1hyhDW1Vgf-00tQWJ; Thu, 10 Oct 2019 15:21:47 +0200
To: Henrik Levkowetz , Robert Moskowitz , Carsten Bormann 
Cc: RFC Markdown , XML2RFC Interest Group , xml2rfc-dev@ietf.org, IETF , Tools Team Discussion 
References: <082EE9F1-D4AA-487F-BB8C-08CDB59C5A2F@vigilsec.com> <02046145-9455-4C01-9F6E-246D3940C86E@tzi.org> <96647ed8-2627-4434-ad51-b373eadfade6@levkowetz.com> <347055CD-74C9-479B-B7FC-BA78580C37B5@tzi.org>  <2383ca8d-efde-168b-3485-597b25ba6782@levkowetz.com>
From: Julian Reschke 
Message-ID: <1a576c17-f648-a230-393e-d97c17f43ad7@gmx.de>
Date: Thu, 10 Oct 2019 15:21:42 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <2383ca8d-efde-168b-3485-597b25ba6782@levkowetz.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:r/7sSsppW14ii9FR3GVLko/d6s2taiOSGYaZN4KEBQIVNUt3QhN 8ryaP31k6gGxnOd7VTvMdnmMLDHa+keut+l961ySyql/EEaV3cis21AJsKMC5QXej6v7TR+ D9BxTxlQM9aiNM2Dq3kI9DlK++8RfgGpDINmfusgRmV19qa4FGlEoNCYOr781iHyasoR27k eYIZtCB7DwqRS4GRCqxwA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:PciloICq+lM=:vkokfFwZTolP4eRHzg03yh 7wcaB8FyZD/+IAeEOUeafdCLRyRYcRHp67spUgUdO+AKSuK7sgFyzjUBdD57bO/JI+FP0ONGm b6noi9yJNn6w9ApxmGX/BD3P66MmkkPHEbJ7+Vt6YsCRwqrqOS0sYc4aXsZLLE7mDPGEYGkE3 SKj1xvrUEUCun6k9y1cdBVzPNeJ9qlIULljAa8pc2FlasMloWZB83kZnuz9V/aq2iOOrlyeaS 2+fC8hUIz91Vi04g0hDvJyPk2+tRio3vEElERib44cvAfNJGHRb5C/MBeAONRMkf/rv+hUHmp 40HR5Z/qAel6FbQIV/yzBPOAKYtl9zCp6NIarFSmVM3T0EKJyOAaLiRXpkizQOnbnMclas3Ay EN/HR3stFE54uV6qRMycYCYBa78hJDbnNjamBEfP+b7zPGPscmmP/C3hHj7m+qSLWAKSp8vU9 Jb3HHIY3O9v6CQsMYt5Z21DbivaddfuQ3jLJF8006J+lw9pYA1aO2KcFFYV7mMIWAgTiOaQQp 7ywSaGZJSlVA3GTrkjmTpzmvYt8Pr4fymA8zkEyPqFHm1u/AtDgCPSMD2Bw2zdW01wGxZjfmX a6+tRZrZt1v7xikJ8CQ6vbf781NDa06tnqNTmKaaddXAI3ZZNxqsXapMGc6N5Mhvg5AqsTM0E PW2b0VgZ3I3nIwar6J+/F1u1hHBdhSzLJWC7nXnXhgq0sXVhzv8xVqWAa7+Zg6fIaOGVGz5x6 P3kkqKAsUXN/PIHbQyj+QK4j0PYM/tWbBcOyCQofYqwVcjr4Gyn4z7WsEXqBhDczCBhD/Fc3u 8ocDl2IsxPKejDrI1YffypBxcRyIQaaMtxYRZCde0oBnclbj7w0FcqEDRC0PuwyPuoaF8Dm9O 07y2xbsy4w0U4E7da+UcuqnMDeAMkTQ9G/v/s5liDCAO8msNjYxbOwLcsyr+mKC/5ucuDBLFP 4MWxoJ+6Ybdt8ycrzgPmDlA2MBI0fksDsJh55sfsr1m3x1SQY4bAJfn//PW1OGIHEHQm5Bl4D os+HVzM8pth9SZhfT7BZzxjVk1HHjIhKpoyi21hcsaIo0NGC1McRy8i1Wz0YAOFvMVetYsZIn eSFBkBjF8ahRfhB9hhPBgilHzBpZi3NNXWB/90OvS3UFRp5Ll0/B61G50Hg8v1fsvXFfCW1+r itNgJ5s+Cu66XNxI1nNWSJBXF6DEANlCCO/RWdk6dyHDOYoDtMGS8xcun45k69ocj8XwonEUt Nd5Ao9rCIvHVdje3nt9lqviylYABiCTSU1/0ag6rkz8O4BLJjeDT3VunHX60=
Archived-At: 
Subject: Re: [Tools-discuss] [Rfc-markdown] [xml2rfc] End of support for xml2rfc on Python 2.x is coming soon
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Oct 2019 13:22:19 -0000

On 10.10.2019 14:59, Henrik Levkowetz wrote:
> Hi Bob,
>
> On 2019-10-10 14:49, Robert Moskowitz wrote:
>>
>> I have encounter:
>>
>> draft-moskowitz-hip-new-crypto-02.xml(14): Warning: Setting
>> consensus=3D"true" for IETF STD document (this is not the schema defaul=
t,
>> but is the only value permitted for this type of document)
>>    Created file draft-moskowitz-hip-new-crypto-02.txt
>>
>> when using the--v3 switch.
>>
>> I have been told not to worry about this, but so far I have not found
>> any documentation on "consensus".\
>
> See:
>
> 	https://tools.ietf.org/html/rfc7749#appendix-A.4
> 	https://tools.ietf.org/html/rfc7991#section-2.45.2
> ...

...and...: 

Best regards, Julian


From nobody Mon Oct 21 05:53:36 2019
Return-Path: 
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46E05120099 for ; Mon, 21 Oct 2019 05:53: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_HELO_NONE=0.001, 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 lxaRLTgKMTv0 for ; Mon, 21 Oct 2019 05:53:31 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AEF912004D for ; Mon, 21 Oct 2019 05:53:31 -0700 (PDT)
Received: from [192.168.217.110] (p548DCE50.dip0.t-ipconnect.de [84.141.206.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46xc552mqPzyNL; Mon, 21 Oct 2019 14:53:29 +0200 (CEST)
From: Carsten Bormann 
Content-Type: text/plain; charset=utf-8
X-Mao-Original-Outgoing-Id: 593355206.8298939-2a69d58ece12979d6fd7629dfe1517a0
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Mon, 21 Oct 2019 14:53:28 +0200
Message-Id: 
To: Tools Team Discussion 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: [Tools-discuss] Problems marking headings In htmlized
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2019 12:53:34 -0000

https://tools.ietf.org/html/rfc7252

If I try to mark a section heading, something else is marked, and some =
general weirdness.

Browser: Chrome 78.
(Works for me in Safari 13.)

Gr=C3=BC=C3=9Fe, Carsten


From nobody Mon Oct 21 09:33:56 2019
Return-Path: 
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B37361200B6 for ; Mon, 21 Oct 2019 09:15:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.119
X-Spam-Level: 
X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 I84xhmkMXrC2 for ; Mon, 21 Oct 2019 09:14:59 -0700 (PDT)
Received: from server172-3.web-hosting.com (server172-3.web-hosting.com [68.65.122.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E504E120089 for ; Mon, 21 Oct 2019 09:14:58 -0700 (PDT)
Received: from [146.96.19.240] (port=40594 helo=[10.10.201.23]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1iMaKa-002zQi-7J; Mon, 21 Oct 2019 12:14:57 -0400
From: Dave Rice 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_B20C7190-BE01-4B9F-9E1E-3DFEF488C1CF"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Date: Mon, 21 Oct 2019 12:14:46 -0400
In-Reply-To: <06122b6d-d5f9-30b9-2db4-a2427d299a1f@levkowetz.com>
Cc: Michael Richardson , rfc-interest , tools-discuss@ietf.org
To: Henrik Levkowetz 
References: <20285.1568652805@localhost> <705AA16B-68B1-4B5E-AE47-0714F6781C1A@dericed.com> <26105.1568818137@localhost>  <1268.1568828850@localhost>  <15814.1569013442@localhost> <3a8f5865-9f5c-8c65-63be-bca31c5f1c86@levkowetz.com> <3650B5EF-A442-4291-928A-2FCB2144134C@dericed.com> <06122b6d-d5f9-30b9-2db4-a2427d299a1f@levkowetz.com>
X-Mailer: Apple Mail (2.3445.104.8)
X-OutGoing-Spam-Status: No, score=-2.6
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server172.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - dericed.com
X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com
X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-From-Rewrite: unmodified, already matched
Archived-At: 
X-Mailman-Approved-At: Mon, 21 Oct 2019 09:33:55 -0700
Subject: Re: [Tools-discuss] [rfc-i] Update: The transition to xml2rfc v3 (today!) (fwd) Heather Flanagan: Update: The transition to xml2rfc v3 (today!)
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2019 16:15:02 -0000

--Apple-Mail=_B20C7190-BE01-4B9F-9E1E-3DFEF488C1CF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi all,

> On Oct 9, 2019, at 1:38 PM, Henrik Levkowetz  =
wrote:
>=20
> Hi David,
>=20
> On 2019-10-09 17:32, Dave Rice wrote:
>> Thanks Henrik,
>>=20
>>> On Sep 20, 2019, at 5:26 PM, Henrik Levkowetz  =
wrote:
>>>=20
>>> Hi Michael, David,
>>>=20
>>> On 2019-09-20 23:04, Michael Richardson wrote:
>>>>=20
>>>> Dave Rice  wrote:
>>>>> Another annoyance here is the the xml processor in the submission =
tool
>>>>> and the xml processor at
>>>>> https://xml2rfc.tools.ietf.org/experimental.html
>>>>>  perform =
differently,
>>>>> so there=E2=80=99s effectively no test environment to use before =
submitting.
>>>>> Dave
>>>>=20
>>>> Dave, can you please try xml2rfc.ietf.org, which is a different =
installation,
>>>> supported by a different entity?
>>>=20
>>> Michael:  Umm, no, that redirects to tools.ietf.org, too, and the =
processor
>>> behind that, and behind =
https://xml2rfc.tools.ietf.org/experimental.html,
>>> _and_ behind the submission tool are all the latest release of =
xml2rfc.
>>>=20
>>> David: I'd be happy to look into any discrepancies you see, but I =
can only
>>> do so if you provide observations and input XML files for me to work
>>> with.  It won't happen if I don't know about it :-)
>>=20
>=20
>> When I use the tool at https://xml2rfc.tools.ietf.org or
>> https://xml2rfc.tools.ietf.org/experimental.html, the plain text
>> output appears ok, but when I use
>> https://datatracker.ietf.org/submit/
>> >, the contents of the
>>  elements (which are new in xml2rfc version 3) have their
>> line breaks stripped out and thus cause an error when the line length
>> limits are exceeded.
>=20
> That sounds like a bug.
>=20
>> For the moment, I=E2=80=99m proposing a find and replace to convert =
the newer
>>  elements back to  elements as in
>> =
https://github.com/FFmpeg/FFV1/pull/171/commits/a018f091534678f45cc157bfd1=
54518ad6267c7e =

>> =
>,
>> thus an xml2rfc version 2 processor or version 3 processor should
>> proceed accurate results though not as semantically clear in the
>> xml.
>>=20
>>> FWIW, if you have a tools.ietf.org  login, =
you can use the xml2rfc
>>> issue
>>> tracker at https://trac.tools.ietf.org/tools/xml2rfc/trac/newticket =
, for
>>> xml2rfc issues, and =
https://trac.tools.ietf.org/tools/ietfdb/newticket =

>>> for datatracker issues.
>>=20
>> I don=E2=80=99t have a login, but I=E2=80=99ll see if I can make a =
tiny test file for this issue and file a concise ticket.
>=20
> Please don't put time into this; I'm perfectly happy to work from the =
xml
> file you found problematic on submission.  Just let me know the name =
of the
> draft in question, so I can pull it.


I just uploaded this new version of the EBML specification to the =
datatracker.


On lines 559-609 and 824-939 there are  nodes that contain =
multi-line xml expressions. During the upload the idnit test showed no =
issues or nits at all.  However in the resulting files at =
https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/12/ =
 the =
outputs remove the line-breaks of the multi-line xml within the =
 nodes. So in the HTML version the  is shown as =
a single line, see =
https://www.ietf.org/id/draft-ietf-cellar-ebml-12.html#name-ebml-schema-ex=
ample =
, and in the plain text as well, see Section 11.1.1 of =
https://www.ietf.org/id/draft-ietf-cellar-ebml-12.txt =
.

In another document, I have been find/replacing the  node =
with the older  node as a workaround.

Best Regards,

Dave Rice=

--Apple-Mail=_B20C7190-BE01-4B9F-9E1E-3DFEF488C1CF
Content-Type: multipart/mixed;
 boundary="Apple-Mail=_6992EB9F-D436-4DDC-BEC4-E7F50FEADAC1"


--Apple-Mail=_6992EB9F-D436-4DDC-BEC4-E7F50FEADAC1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi =
all,

On Oct 9, 2019, at 1:38 PM, Henrik Levkowetz =
<henrik@levkowetz.com> wrote:

Hi David,

On 2019-10-09 17:32, Dave Rice =
wrote:
Thanks =
Henrik,

On Sep 20, 2019, at 5:26 PM, Henrik Levkowetz <henrik@levkowetz.com> wrote:

Hi Michael, David,

On 2019-09-20 =
23:04, Michael Richardson wrote:

Dave Rice <dave@dericed.com> =
wrote:
Another =
annoyance here is the the xml processor in the submission tool
and the xml processor at
https://xml2rfc.tools.ietf.org/experimental.html
<https://xml2rfc.tools.ietf.org/experimental.html> =
perform differently,
so there=E2=80=99s effectively no =
test environment to use before submitting.
Dave

Dave, can you please try xml2rfc.ietf.org, which =
is a different installation,
supported by a different =
entity?

Michael:  Umm, =
no, that redirects to tools.ietf.org, too, and the processor
behind=
 that, and behind https://xml2rfc.tools.ietf.org/experimental.html,
_and_ behind the submission tool are all the latest release =
of xml2rfc.

David: I'd be happy to look =
into any discrepancies you see, but I can only
do so if =
you provide observations and input XML files for me to work
with.  It won't happen if I don't know about it :-)


When =
I use the tool at https://xml2rfc.tools.ietf.org or
https://xml2rfc.tools.ietf.org/experimental.html, the =
plain text
output appears ok, but when I use
https://datatracker.ietf.org/submit/
<https://datatracker.ietf.org/submit/>, the contents of =
the
<sourcecode> elements (which are new in xml2rfc =
version 3) have their
line breaks stripped out and thus =
cause an error when the line length
limits are =
exceeded.

That sounds like a bug.

For the moment, I=E2=80=99m proposing =
a find and replace to convert the newer
<sourcecode> =
elements back to <artwork> elements as in
https://github.com/FFmpeg/FFV1/pull/171/commits/a018f091534678f=
45cc157bfd154518ad6267c7e
<https://github.com/FFmpeg/FFV1/pull/171/commits/a018f091534678f=
45cc157bfd154518ad6267c7e>,
thus an xml2rfc version =
2 processor or version 3 processor should
proceed accurate =
results though not as semantically clear in the
xml.

FWIW, if =
you have a tools.ietf.org login, you can use the =
xml2rfc
issue
tracker at https://trac.tools.ietf.org/tools/xml2rfc/trac/newticket, =
for
xml2rfc issues, and https://trac.tools.ietf.org/tools/ietfdb/newticket
for datatracker issues.

I don=E2=80=99t have a login, but I=E2=80=99ll see if I can =
make a tiny test file for this issue and file a concise ticket.

Please don't put time into this; I'm perfectly happy to work =
from the xml
file you =
found problematic on submission.  Just let me know the name of =
the
draft in =
question, so I can pull it.

I just uploaded this new version of the =
EBML specification to the datatracker.
=

--Apple-Mail=_6992EB9F-D436-4DDC-BEC4-E7F50FEADAC1
Content-Disposition: attachment;
	filename=draft-ietf-cellar-ebml-12.xml
Content-Type: application/xml; x-unix-mode=0644;
 name="draft-ietf-cellar-ebml-12.xml"
Content-Transfer-Encoding: quoted-printable

=0A=0A=0A=0A=
=0AExtensible=20Binary=20Meta=20=
Language=0A
=0A=
slhomme@matroska.org=0A
=0A=

=0A=
dave@dericed.com=0A
=0A
=0A=
moritz@bunkus.org=0A
=0A=
=0Aart=0Acellar=0A=0A=
=0AThis=20document=20defines=20the=20Extensible=20Binary=20=
Meta=20Language=20(EBML)=20format=20as=20a=20generalized=20file=20format=20=
for=20any=20type=20of=20data=20in=20a=20hierarchical=20form.=20EBML=20is=20=
designed=20as=20a=20binary=20equivalent=20to=20XML=20and=20uses=20a=20=
storage-efficient=20approach=20to=20build=20nested=20Elements=20with=20=
identifiers,=20lengths,=20and=20values.=20Similar=20to=20how=20an=20XML=20=
Schema=20defines=20the=20structure=20and=20semantics=20of=20an=20XML=20=
Document,=20this=20document=20defines=20how=20EBML=20Schemas=20are=20=
created=20to=20convey=20the=20semantics=20of=20an=20EBML=20Document.=0A=
=0A=0A=0A=0A=0A=0AIntroduction=0AEBML,=20short=20=
for=20Extensible=20Binary=20Meta=20Language,=20specifies=20a=20binary=20=
and=20octet=20(byte)=20aligned=20format=20inspired=20by=20the=20=
principle=20of=20XML=20(a=20framework=20for=20structuring=20data).=0A=
The=20goal=20of=20this=20document=20is=20to=20define=20a=20generic,=20=
binary,=20space-efficient=20format=20that=20can=20be=20used=20to=20=
define=20more=20complex=20formats=20using=20an=20EBML=20Schema.=20EBML=20=
is=20used=20by=20the=20multimedia=20container=20Matrosk=
a.=20The=20applicability=20of=20EBML=20for=20other=20use=20cases=20=
is=20beyond=20the=20scope=20of=20this=20document.=0AThe=20=
definition=20of=20the=20EBML=20format=20recognizes=20the=20idea=20behind=20=
HTML=20and=20XML=20as=20a=20good=20one:=20separate=20structure=20and=20=
semantics=20allowing=20the=20same=20structural=20layer=20to=20be=20used=20=
with=20multiple,=20possibly=20widely=20differing=20semantic=20layers.=20=
Except=20for=20the=20EBML=20Header=20and=20a=20few=20Global=20Elements=20=
this=20specification=20does=20not=20define=20particular=20EBML=20format=20=
semantics;=20however=20this=20specification=20is=20intended=20to=20=
define=20how=20other=20EBML-based=20formats=20can=20be=20defined,=20such=20=
as=20the=20audio-video=20container=20formats=20Matroska=20and=20=
WebM.=0AEBML=20uses=20a=20simple=20approach=20of=20building=20=
Elements=20upon=20three=20pieces=20of=20data=20(tag,=20length,=20and=20=
value)=20as=20this=20approach=20is=20well=20known,=20easy=20to=20parse,=20=
and=20allows=20selective=20data=20parsing.=20The=20EBML=20structure=20=
additionally=20allows=20for=20hierarchical=20arrangement=20to=20support=20=
complex=20structural=20formats=20in=20an=20efficient=20manner.=0A=
A=20typical=20EBML=20file=20has=20the=20following=20structure:=0A=0A=
EBML=20Header=20(master)=0A=20=20+=20DocType=20(string)=0A=20=20=
+=20DocTypeVersion=20(unsigned=20integer)=0AEBML=20Body=20Root=20=
(master)=0A=20=20+=20ElementA=20(utf-8)=0A=20=20+=20Parent=20(master)=0A=20=
=20=20=20+=20ElementB=20(integer)=0A=20=20+=20Parent=20(master)=0A=20=20=20=
=20+=20ElementB=20(integer)=0A=0A=0A=0ANotation=20and=20=
Conventions=0AThe=20key=20words=20"MUST",=20=
"MUST=20NOT",=20"REQUIRED",=20"SHALL",=20=
"SHALL=20NOT",=20"SHOULD",=20"SHOULD=20=
NOT",=20"RECOMMENDED",=20"NOT=20RECOMMENDED",=20=
"MAY",=20and=20"OPTIONAL"=20in=20this=20document=20=
are=20to=20be=20interpreted=20as=20described=20in=20BCP=2014=20=20=20when,=20=
and=20only=20when,=20they=20appear=20in=20all=20capitals,=20as=20shown=20=
here.=0AThis=20document=20defines=20specific=20terms=20in=20order=20=
to=20define=20the=20format=20and=20application=20of=20EBML.=20=
Specific=20terms=20are=20defined=20below:=0AEBML:=20=
Extensible=20Binary=20Meta=20Language=0AEBML=20Document=20=
Type:=20A=20name=20provided=20by=20an=20EBML=20Schema=20to=20=
designate=20a=20particular=20implementation=20of=20EBML=20for=20=
a=20data=20format=20(e.g.:=20matroska=20and=20webm).=0AEBML=20=
Schema:=20A=20standardized=20definition=20for=20the=20structure=20=
of=20an=20EBML=20Document=20Type.=0AEBML=20=
Document:=20A=20datastream=20comprised=20of=20only=20two=20=
components,=20an=20EBML=20Header=20and=20an=20EBML=20=
Body.=0AEBML=20Reader:=20A=20data=20parser=20that=20=
interprets=20the=20semantics=20of=20an=20EBML=20Document=20and=20=
creates=20a=20way=20for=20programs=20to=20use=20EBML.=0A=
EBML=20Stream:=20A=20file=20that=20consists=20of=20one=20or=20=
more=20EBML=20Documents=20that=20are=20concatenated=20=
together.=0AEBML=20Header:=20A=20declaration=20that=20=
provides=20processing=20instructions=20and=20identification=20of=20the=20=
EBML=20Body.=20The=20EBML=20Header=20is=20analogous=20=
to=20an=20XML=20Declaration=20=20(see=20section=202.8=20on=20=
Prolog=20and=20Document=20Type=20Declaration).=0AEBML=20=
Body:=20All=20data=20of=20an=20EBML=20Document=20following=20=
the=20EBML=20Header.=0AVariable=20Size=20=
Integer:=20A=20compact=20variable-length=20binary=20value=20which=20=
defines=20its=20own=20length.=0AVINT:=20Also=20known=20=
as=20Variable=20Size=20Integer.=0AEBML=20=
Element:=20A=20foundation=20block=20of=20data=20that=20contains=20=
three=20parts:=20an=20Element=20ID,=20an=20Element=20Data=20=
Size,=20and=20Element=20Data.=0AElement=20=
ID:=20The=20Element=20ID=20is=20a=20binary=20value,=20=
encoded=20as=20a=20Variable=20Size=20Integer,=20used=20to=20=
uniquely=20identify=20a=20defined=20EBML=20Element=20within=20a=20=
specific=20EBML=20Schema.=0AEBML=20Class:=20A=20=
representation=20of=20the=20octet=20length=20of=20an=20Element=20=
ID.=0AElement=20Data=20Size:=20An=20expression,=20=
encoded=20as=20a=20Variable=20Size=20Integer,=20of=20the=20=
length=20in=20octets=20of=20Element=20Data.=0A=
VINTMAX:=20The=20maximum=20possible=20value=20that=20can=20=
be=20stored=20as=20Element=20Data=20Size.=0A=
Unknown-Sized=20Element:=20An=20Element=20with=20an=20=
unknown=20Element=20Data=20Size.=0AElement=20=
Data:=20The=20value(s)=20of=20the=20EBML=20Element=20which=20=
is=20identified=20by=20its=20Element=20ID=20and=20Element=20=
Data=20Size.=20The=20form=20of=20the=20Element=20Data=20is=20=
defined=20by=20this=20document=20and=20the=20corresponding=20EBML=20=
Schema=20of=20the=20Element's=20EBML=20Document=20=
Type.=0ARoot=20Level:=20The=20starting=20level=20in=20=
the=20hierarchy=20of=20an=20EBML=20Document.=0ARoot=20=
Element:=20A=20mandatory,=20non-repeating=20EBML=20Element=20=
which=20occurs=20at=20the=20top=20level=20of=20the=20path=20hierarchy=20=
within=20an=20EBML=20Body=20and=20contains=20all=20other=20=
EBML=20Elements=20of=20the=20EBML=20Body,=20excepting=20=
optional=20Void=20Elements.=0ATop-Level=20=
Element:=20An=20EBML=20Element=20defined=20to=20only=20=
occur=20as=20a=20Child=20Element=20of=20the=20Root=20=
Element.=0AMaster=20Element:=20The=20Master=20=
Element=20contains=20zero,=20one,=20or=20many=20other=20EBML=20=
Elements.=0AChild=20Element:=20A=20Child=20=
Element=20is=20a=20relative=20term=20to=20describe=20the=20EBML=20=
Elements=20immediately=20contained=20within=20a=20Master=20=
Element.=0AParent=20Element:=20A=20relative=20term=20=
to=20describe=20the=20Master=20Element=20which=20contains=20a=20=
specified=20element.=20For=20any=20specified=20EBML=20Element=20=
that=20is=20not=20at=20Root=20Level,=20the=20Parent=20=
Element=20refers=20to=20the=20Master=20Element=20in=20=
which=20that=20EBML=20Element=20is=20contained.=0A=
Descendant=20Element:=20A=20relative=20term=20to=20describe=20=
any=20EBML=20Elements=20contained=20within=20a=20Master=20=
Element,=20including=20any=20of=20the=20Child=20Elements=20=
of=20its=20Child=20Elements,=20and=20so=20on.=0AVoid=20=
Element:=20A=20Void=20Element=20is=20an=20Element=20=
used=20to=20overwrite=20data=20or=20reserve=20space=20within=20a=20=
Master=20Element=20for=20later=20use.=0AElement=20=
Name:=20The=20human-readable=20name=20of=20the=20EBML=20=
Element.=0AElement=20Path:=20The=20hierarchy=20of=20=
Parent=20Element=20where=20the=20EBML=20Element=20is=20=
expected=20to=20be=20found=20in=20the=20EBML=20Body.=0A=
Empty=20Element:=20An=20EBML=20Element=20that=20has=20=
an=20Element=20Data=20Size=20with=20all=20VINT_DATA=20=
bits=20set=20to=20zero,=20which=20indicates=20that=20the=20Element=20=
Data=20of=20the=20Element=20is=20zero=20octets=20in=20=
length.=0A=0A=0AStructure=0AEBML=20uses=20a=20=
system=20of=20Elements=20to=20compose=20an=20EBML=20Document.=20EBML=20=
Elements=20incorporate=20three=20parts:=20an=20Element=20ID,=20an=20=
Element=20Data=20Size,=20and=20Element=20Data.=20The=20Element=20Data,=20=
which=20is=20described=20by=20the=20Element=20ID,=20includes=20either=20=
binary=20data,=20one=20or=20more=20other=20EBML=20Elements,=20or=20=
both.=0A=0A=0AVariable=20Size=20Integer=0A=
The=20Element=20ID=20and=20Element=20Data=20Size=20are=20both=20=
encoded=20as=20a=20Variable=20Size=20Integer.=20The=20Variable=20Size=20=
Integer=20is=20composed=20of=20a=20VINT_WIDTH,=20VINT_MARKER,=20and=20=
VINT_DATA,=20in=20that=20order.=20Variable=20Size=20Integers=20MUST=20=
left-pad=20the=20VINT_DATA=20value=20with=20zero=20bits=20so=20that=20=
the=20whole=20Variable=20Size=20Integer=20is=20octet-aligned.=20Variable=20=
Size=20Integer=20will=20be=20referred=20to=20as=20VINT=20for=20=
shorthand.=0A=0AVINT_WIDTH=0AEach=20Variable=20=
Size=20Integer=20begins=20with=20a=20VINT_WIDTH=20which=20consists=20of=20=
zero=20or=20many=20zero-value=20bits.=20The=20count=20of=20consecutive=20=
zero-values=20of=20the=20VINT_WIDTH=20plus=20one=20equals=20the=20length=20=
in=20octets=20of=20the=20Variable=20Size=20Integer.=20For=20example,=20a=20=
Variable=20Size=20Integer=20that=20starts=20with=20a=20VINT_WIDTH=20=
which=20contains=20zero=20consecutive=20zero-value=20bits=20is=20one=20=
octet=20in=20length=20and=20a=20Variable=20Size=20Integer=20that=20=
starts=20with=20one=20consecutive=20zero-value=20bit=20is=20two=20octets=20=
in=20length.=20The=20VINT_WIDTH=20MUST=20only=20contain=20zero-value=20=
bits=20or=20be=20empty.=0AWithin=20the=20EBML=20Header=20the=20=
VINT_WIDTH=20of=20a=20VINT=20MUST=20NOT=20exceed=20three=20bits=20in=20=
length=20(meaning=20that=20the=20Variable=20Size=20Integer=20MUST=20NOT=20=
exceed=20four=20octets=20in=20length)=20except=20if=20said=20VINT=20is=20=
used=20to=20express=20the=20Element=20Data=20Size=20of=20an=20EBML=20=
Element=20with=20Element=20Name=20EBML=20and=20Element=20ID=20=
0x1A45DFA3=20(see=20the=20=
definition=20of=20the=20EBML=20Element)=20in=20which=20case=20the=20=
VINT_WIDTH=20MUST=20NOT=20exceed=20seven=20bits=20in=20length.=20Within=20=
the=20EBML=20Body,=20when=20a=20VINT=20is=20used=20to=20express=20an=20=
Element=20ID,=20the=20maximum=20length=20allowed=20for=20the=20=
VINT_WIDTH=20is=20one=20less=20than=20the=20value=20set=20in=20the=20=
EBMLMaxIDLength=20Element.=20Within=20the=20EBML=20Body,=20when=20a=20=
VINT=20is=20used=20to=20express=20an=20Element=20Data=20Size,=20the=20=
maximum=20length=20allowed=20for=20the=20VINT_WIDTH=20is=20one=20less=20=
than=20the=20value=20set=20in=20the=20EBMLMaxSizeLength=20Element.=0A=
=0A=0AVINT_MARKER=
=0AThe=20VINT_MARKER=20serves=20as=20a=20separator=20between=20the=20=
VINT_WIDTH=20and=20VINT_DATA.=20Each=20Variable=20Size=20Integer=20MUST=20=
contain=20exactly=20one=20VINT_MARKER.=20The=20VINT_MARKER=20is=20one=20=
bit=20in=20length=20and=20contain=20a=20bit=20with=20a=20value=20of=20=
one.=20The=20first=20bit=20with=20a=20value=20of=20one=20within=20the=20=
Variable=20Size=20Integer=20is=20the=20VINT_MARKER.=0A=0A=0A=
VINT_DATA=0AThe=20=
VINT_DATA=20portion=20of=20the=20Variable=20Size=20Integer=20includes=20=
all=20data=20that=20follows=20(but=20not=20including)=20the=20=
VINT_MARKER=20until=20end=20of=20the=20Variable=20Size=20Integer=20whose=20=
length=20is=20derived=20from=20the=20VINT_WIDTH.=20The=20bits=20required=20=
for=20the=20VINT_WIDTH=20and=20the=20VINT_MARKER=20use=20one=20out=20of=20=
every=20eight=20bits=20of=20the=20total=20length=20of=20the=20Variable=20=
Size=20Integer.=20Thus=20a=20Variable=20Size=20Integer=20of=201=20octet=20=
length=20supplies=207=20bits=20for=20VINT_DATA,=20a=202=20octet=20length=20=
supplies=2014=20bits=20for=20VINT_DATA,=20and=20a=203=20octet=20length=20=
supplies=2021=20bits=20for=20VINT_DATA.=20If=20the=20number=20of=20bits=20=
required=20for=20VINT_DATA=20are=20less=20than=20the=20bit=20size=20of=20=
VINT_DATA,=20then=20VINT_DATA=20MUST=20be=20zero-padded=20to=20the=20=
left=20to=20a=20size=20that=20fits.=20The=20VINT_DATA=20value=20MUST=20=
be=20expressed=20as=20a=20big-endian=20unsigned=20integer.=0A=
=0A=0AVINT=20=
Examples=0AThis=20table=20shows=20examples=20of=20Variable=20=
Size=20Integers=20with=20lengths=20from=201=20to=205=20octets.=20The=20=
Usable=20Bits=20column=20refers=20to=20the=20number=20of=20bits=20that=20=
can=20be=20used=20in=20the=20VINT_DATA.=20The=20Representation=20column=20=
depicts=20a=20binary=20expression=20of=20Variable=20Size=20Integers=20=
where=20VINT_WIDTH=20is=20depicted=20by=200,=20the=20=
VINT_MARKER=20as=201,=20and=20the=20VINT_DATA=20as=20=
x.=0A=0A=0A=0A=0A=
=0ARepresentation=0A=
=0A=0A=0A=0A=0A=0A=0A1xxx=20xxxx=0A=0A=0A=0A=0A=
=0A01xx=20xxxx=20xxxx=20xxxx=0A=
=0A=0A=0A=0A=0A001x=20=
xxxx=20xxxx=20xxxx=20xxxx=20xxxx=0A=0A=0A=0A=0A=
=0A0001=20xxxx=20xxxx=20xxxx=20xxxx=20=
xxxx=20xxxx=20xxxx=0A=0A=0A=0A=0A=0A=
0000=201xxx=20xxxx=20xxxx=20xxxx=20xxxx=20xxxx=20=
xxxx=20xxxx=20xxxx=0A=0A=0A
Octet=20LengthUsable=20Bits
17
214
321
428
535
Data=20encoded=20=
as=20a=20Variable=20Size=20Integer=20may=20be=20rendered=20at=20octet=20=
lengths=20larger=20than=20needed=20to=20store=20the=20data=20in=20order=20=
to=20facilitate=20overwriting=20it=20at=20a=20later=20date,=20e.g.=20=
when=20its=20final=20size=20isn't=20known=20in=20advance.=20In=20this=20=
table=20a=20binary=20value=20of=200b10=20is=20shown=20encoded=20as=20=
different=20Variable=20Size=20Integers=20with=20lengths=20from=20one=20=
octet=20to=20four=20octets.=20All=20four=20encoded=20examples=20have=20=
identical=20semantic=20meaning=20though=20the=20VINT_WIDTH=20and=20the=20=
padding=20of=20the=20VINT_DATA=20vary.=0A=0A=0A=0A=
=0A=0AAs=20Represented=20in=20Variable=20Size=20Integer=0A=
=0A=0A=0A=0A=0A=0A=0A1000=200010=0A=0A=0A=0A=0A=
=0A0100=200000=200000=200010=0A=0A=
=0A=0A=0A=0A0010=200000=20=
0000=200000=200000=200010=0A=0A=0A=0A=0A=
=0A0001=200000=200000=200000=200000=20=
0000=200000=200010=0A=0A=0A
Binary=20ValueOctet=20Length
101
102
103
104
=0A=
=0A=0AElement=20=
ID=0AThe=20Element=20ID=20is=20encoded=20as=20a=20Variable=20=
Size=20Integer.=20By=20default,=20Element=20IDs=20are=20encoded=20in=20=
lengths=20from=20one=20octet=20to=20four=20octets,=20although=20Element=20=
IDs=20of=20greater=20lengths=20MAY=20be=20used=20if=20the=20=
EBMLMaxIDLength=20Element=20of=20the=20EBML=20Header=20is=20set=20to=20a=20=
value=20greater=20than=20four=20(see=20the=20section=20on=20the=20=
EBMLMaxIDLength=20Element).=20The=20VINT_DATA=20component=20of=20=
the=20Element=20ID=20MUST=20NOT=20be=20either=20defined=20or=20written=20=
as=20either=20all=20zero=20values=20or=20all=20one=20values.=20Any=20=
Element=20ID=20with=20the=20VINT_DATA=20component=20set=20as=20all=20=
zero=20values=20or=20all=20one=20values=20MUST=20be=20ignored.=20The=20=
VINT_DATA=20component=20of=20the=20Element=20ID=20MUST=20be=20encoded=20=
at=20the=20shortest=20valid=20length.=20For=20example,=20an=20Element=20=
ID=20with=20binary=20encoding=20of=201011=201111=20is=20valid,=20=
whereas=20an=20Element=20ID=20with=20binary=20encoding=20of=200100=20=
0000=200011=201111=20stores=20a=20semantically=20equal=20VINT_DATA=20=
but=20is=20invalid=20because=20a=20shorter=20VINT=20encoding=20is=20=
possible.=20Additionally,=20an=20Element=20ID=20with=20binary=20encoding=20=
of=201111=201111=20is=20invalid=20since=20the=20VINT_DATA=20=
section=20is=20set=20to=20all=20one=20values,=20whereas=20an=20Element=20=
ID=20with=20binary=20encoding=20of=200100=200000=200111=201111=20=
stores=20a=20semantically=20equal=20VINT_DATA=20and=20is=20the=20=
shortest=20possible=20VINT=20encoding.=0AThe=20following=20table=20=
details=20these=20specific=20examples=20further:=0A=0A=0A=
=0AVINT_WIDTH=0AVINT_MARKER=0AVINT_DATA=0A=
Element=20ID=20Status=0A=0A=0A=0A=
=0A=0A=0A1=0A0000000=0AInvalid:=20VINT_DATA=20MUST=20NOT=20be=20set=20to=20all=20=
0=0A=0A=0A=0A0=0A1=0A00000000000000=0AInvalid:=20VINT_DATA=20MUST=20NOT=20be=20set=20to=20all=20=
0=0A=0A=0A=0A=0A1=0A0000001=0AValid=0A=0A=0A=0A0=
=0A1=0A00000000000001=0AInvalid:=20A=20=
shorter=20VINT_DATA=20encoding=20is=20available.=0A=0A=0A=0A=
=0A1=0A0111111=0AValid=0A=0A=
=0A=0A0=0A1=0A=
00000000111111=0AInvalid:=20=
A=20shorter=20VINT_DATA=20encoding=20is=20available.=0A=0A=0A=
=0A=0A1=0A1111111=0AInvalid:=20VINT_DATA=20=
MUST=20NOT=20be=20set=20to=20all=201=0A=0A=0A=0A0=0A1=0A00000001111111=0AValid=0A=
=0A=0A
The=20octet=20length=20of=20an=20Element=20=
ID=20determines=20its=20EBML=20Class.=0A=0A=0A=0A=
EBML=20Class=0ALength=0APossible=20=
IDs=0ANumber=20of=20IDs=0A=0A=
=0A=0A=0A=0AClass=20A=0A=
1=0A0x81=20-=20=
0xFE=0A126=0A=0A=0A=0AClass=20B=0A2=0A0x407F=20-=200x7FFE=0A16,256=0A=0A=0A=0AClass=20C=0A3=0A0x203FFF=20-=200x3FFFFE=0A2,080,768=0A=0A=0A=0AClass=20D=0A4=0A0x101FFFFF=20-=200x1FFFFFFE=0A268,338,304=0A=0A=0A
=0A=
=0AElement=20Data=20=
Size=0A=0AData=20=
Size=20Format=0AThe=20Element=20Data=20Size=20expresses=20the=20=
length=20in=20octets=20of=20Element=20Data.=20The=20Element=20Data=20=
Size=20itself=20is=20encoded=20as=20a=20Variable=20Size=20Integer.=20By=20=
default,=20Element=20Data=20Sizes=20can=20be=20encoded=20in=20lengths=20=
from=20one=20octet=20to=20eight=20octets,=20although=20Element=20Data=20=
Sizes=20of=20greater=20lengths=20MAY=20be=20used=20if=20the=20octet=20=
length=20of=20the=20longest=20Element=20Data=20Size=20of=20the=20EBML=20=
Document=20is=20declared=20in=20the=20EBMLMaxSizeLength=20Element=20of=20=
the=20EBML=20Header=20(see=20the=20section=20on=20the=20=
EBMLMaxSizeLength=20Element).=20Unlike=20the=20VINT_DATA=20of=20=
the=20Element=20ID,=20the=20VINT_DATA=20component=20of=20the=20Element=20=
Data=20Size=20is=20not=20mandated=20to=20be=20encoded=20at=20the=20=
shortest=20valid=20length.=20For=20example,=20an=20Element=20Data=20Size=20=
with=20binary=20encoding=20of=201011=201111=20or=20a=20binary=20encoding=20=
of=200100=200000=200011=201111=20are=20both=20valid=20Element=20Data=20=
Sizes=20and=20both=20store=20a=20semantically=20equal=20value=20(both=20=
0b00000000111111=20and=200b0111111,=20the=20VINT_DATA=20sections=20of=20=
the=20examples,=20represent=20the=20integer=2063).=0AAlthough=20=
an=20Element=20ID=20with=20all=20VINT_DATA=20bits=20set=20to=20zero=20is=20=
invalid,=20an=20Element=20Data=20Size=20with=20all=20VINT_DATA=20bits=20=
set=20to=20zero=20is=20allowed=20for=20EBML=20Element=20Types=20which=20=
do=20not=20mandate=20a=20non-zero=20length=20(see=20the=20section=20on=20EBML=20Element=20=
Types).=20An=20Element=20Data=20Size=20with=20all=20VINT_DATA=20=
bits=20set=20to=20zero=20indicates=20that=20the=20Element=20Data=20is=20=
zero=20octets=20in=20length.=20Such=20an=20EBML=20Element=20is=20=
referred=20to=20as=20an=20Empty=20Element.=20If=20an=20Empty=20Element=20=
has=20a=20default=20value=20declared=20then=20the=20EBML=20Reader=20MUST=20=
interpret=20the=20value=20of=20the=20Empty=20Element=20as=20the=20=
default=20value.=20If=20an=20Empty=20Element=20has=20no=20default=20=
value=20declared=20then=20the=20EBML=20Reader=20MUST=20use=20the=20value=20=
of=20the=20Empty=20Element=20for=20the=20corresponding=20EBML=20Element=20=
Type=20of=20the=20Element=20ID,=200=20for=20numbers=20and=20an=20empty=20=
string=20for=20strings.=0A=0A=0AUnknown=20Data=20Size=0AAn=20=
Element=20Data=20Size=20with=20all=20VINT_DATA=20bits=20set=20to=20one=20=
is=20reserved=20as=20an=20indicator=20that=20the=20size=20of=20the=20=
EBML=20Element=20is=20unknown.=20The=20only=20reserved=20value=20for=20=
the=20VINT_DATA=20of=20Element=20Data=20Size=20is=20all=20bits=20set=20=
to=20one.=20An=20EBML=20Element=20with=20an=20unknown=20Element=20Data=20=
Size=20is=20referred=20to=20as=20an=20Unknown-Sized=20Element.=20A=20=
Master=20Element=20MAY=20be=20an=20Unknown-Sized=20Element;=20however=20=
an=20EBML=20Element=20that=20is=20not=20a=20Master=20Element=20MUST=20=
NOT=20be=20an=20Unknown-Sized=20Element.=20Master=20Elements=20MUST=20=
NOT=20use=20an=20unknown=20size=20unless=20the=20unknownsizeallowed=20=
attribute=20of=20their=20EBML=20Schema=20is=20set=20to=20true=20(see=20=
the=20section=20on=20the=20=
unknownsizeallowed=20attribute).=0AThe=20use=20of=20=
Unknown-Sized=20Elements=20allows=20for=20an=20EBML=20Element=20to=20be=20=
written=20and=20read=20before=20the=20size=20of=20the=20EBML=20Element=20=
is=20known.=20Unknown-Sized=20Element=20MUST=20NOT=20be=20used=20or=20=
defined=20unnecessarily;=20however=20if=20the=20Element=20Data=20Size=20=
is=20not=20known=20before=20the=20Element=20Data=20is=20written,=20such=20=
as=20in=20some=20cases=20of=20data=20streaming,=20then=20Unknown-Sized=20=
Elements=20MAY=20be=20used.=20The=20end=20of=20an=20Unknown-Sized=20=
Element=20is=20determined=20by=20whichever=20comes=20first:=0A=0A=

    =0A
  • Any=20EBML=20Element=20that=20is=20a=20valid=20Parent=20=
Element=20of=20the=20Unknown-Sized=20Element=20according=20to=20the=20=
EBML=20Schema,=20Global=20=
Elements=20excluded.=0A
    • =0A
  • Any=20valid=20EBML=20=
Element=20according=20to=20the=20EBML=20Schema,=20Global=20Elements=20excluded,=20that=20=
is=20not=20a=20Descendant=20Element=20of=20the=20Unknown-Sized=20Element=20=
but=20share=20a=20common=20direct=20parent,=20such=20as=20a=20Top-Level=20=
Element.=0A
    • =0A
  • Any=20EBML=20Element=20that=20is=20a=20=
valid=20Root=20Element=20according=20to=20the=20EBML=20Schema,=20Global=20Elements=20excluded.=0A=

    • =0A
  • The=20end=20of=20the=20Parent=20Element=20with=20a=20=
known=20size=20has=20been=20reached.=0A
    • =0A
  • The=20end=20of=20=
the=20EBML=20Document,=20either=20when=20reaching=20the=20end=20of=20the=20=
file=20or=20because=20a=20new=20EBML=20Header=20started.=0A
    • =0A=

=0AConsider=20an=20Unknown-Sized=20Element=20which=20EBML=20path=20=
is=20\root\level1\level2\elt.=20When=20reading=20a=20new=20=
Element=20ID,=20assuming=20the=20EBML=20Path=20of=20that=20new=20Element=20=
is=20valid,=20here=20are=20some=20possible=20and=20impossible=20ways=20=
that=20this=20new=20Element=20is=20ending=20elt:=0A=0A=
=0A=0AEBML=20Path=20of=20new=20=
element=0AStatus=0A=0A=0A=0A=
=0A=0A\root\level1\level2=0A=
Ends=20the=20Unknown-Sized=20Element,=20as=20it=20=
is=20a=20new=20Parent=20Element=0A=0A=0A=0A\root\level1=0AEnds=20=
the=20Unknown-Sized=20Element,=20as=20it=20is=20a=20new=20Parent=20=
Element=0A=0A=0A=0A\root=0A=
Ends=20the=20Unknown-Sized=20Element,=20as=20it=20=
is=20a=20new=20Root=20Element=0A=0A=0A=0A\root2=0AEnds=20the=20=
Unknown-Sized=20Element,=20as=20it=20is=20a=20new=20Root=20Element=0A=
=0A=0A=0A\root\level1\level2\other=0AEnds=20the=20Unknown-Sized=20Element,=20as=20they=20share=20=
the=20same=20parent=0A=0A=0A=0A\root\level1\level2\elt=0AEnds=20the=20Unknown-Sized=20Element,=20as=20they=20share=20=
the=20same=20parent=0A=0A=0A=0A\root\level1\level2\elt\inside=0ADoesn't=20end=20the=20Unknown-Sized=20Element,=20it's=20a=20=
child=20of=20elt=0A=0A=0A=0A\root\level1\level2\elt\<global>=0A=
Global=20Element=20is=20valid,=20it's=20a=20child=20=
of=20elt=0A=0A=0A=0A\root\level1\level2\<global>=0AGlobal=20Element=20cannot=20be=20assumed=20to=20have=20=
this=20path,=20while=20parsing=20elt=20it=20can=20only=20be=20a=20=
child=20of=20elt=0A=0A=0A
=0A=
=0AData=20Size=20=
Values=0AFor=20Element=20Data=20Sizes=20encoded=20at=20octet=20=
lengths=20from=20one=20to=20eight,=20this=20table=20depicts=20the=20=
range=20of=20possible=20values=20that=20can=20be=20encoded=20as=20an=20=
Element=20Data=20Size.=20An=20Element=20Data=20Size=20with=20an=20octet=20=
length=20of=208=20is=20able=20to=20express=20a=20size=20of=202^56-2=20or=20=
72,057,594,037,927,934=20octets=20(or=20about=2072=20petabytes).=20The=20=
maximum=20possible=20value=20that=20can=20be=20stored=20as=20Element=20=
Data=20Size=20is=20referred=20to=20as=20VINTMAX.=0A=0A=0A=
=0A=0A=0A=
=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A
Octet=20LengthPossible=20Value=20Range
10=20to=20=20=
27-2
20=20to=20=
214-2
30=20to=20=
221-2
40=20to=20=
228-2
50=20to=20=
235-2
60=20to=20=
242-2
70=20to=20=
249-2
80=20to=20=
256-2
If=20the=20length=20=
of=20Element=20Data=20equals=202^(n*7)-1=20then=20the=20octet=20length=20=
of=20the=20Element=20Data=20Size=20MUST=20be=20at=20least=20n+1.=20This=20=
rule=20prevents=20an=20Element=20Data=20Size=20from=20being=20expressed=20=
as=20the=20unknown=20size=20value.=20The=20following=20table=20clarifies=20=
this=20rule=20by=20showing=20a=20valid=20and=20invalid=20expression=20of=20=
an=20Element=20Data=20Size=20with=20a=20VINT_DATA=20of=20127=20(which=20=
is=20equal=20to=202^(1*7)-1)=20and=2016,383=20(which=20is=20equal=20to=20=
2(2*7)-1).=0A=0A=0A=0AVINT_WIDTH=0AVINT_MARKER=0A=
VINT_DATA=0A=0A=0A=0A=0A=0A=0A=0A1=0A1111111=0A=0A=
=0A=0A=0A0=0A1=0A00000001111111=0A=
=0A=0A=0A=0A00=0A1=0A000000000000001111111=0A=0A=0A=0A=0A0=0A1=0A11111111111111=0A=
=0A=0A=0A=0A00=0A1=0A000000011111111111111=0A=0A=0A=0A
Element=20Data=20Size=20=
Status
Reserved=20(meaning=20Unknown)
Valid=20(meaning=20127=20octets)
Valid=20(meaning=20127=20=
octets)
Reserved=20(meaning=20Unknown)
Valid=20(16,383=20=
octets)
=0A=0A=0A=
EBML=20Element=20=
Types=0AEBML=20Elements=20are=20defined=20by=20an=20EBML=20=
Schema=20(see=20)=20which=20MUST=20=
declare=20one=20of=20the=20following=20EBML=20Element=20Types=20for=20=
each=20EBML=20Element.=20An=20EBML=20Element=20Type=20defines=20a=20=
concept=20of=20storing=20data=20within=20an=20EBML=20Element=20that=20=
describes=20such=20characteristics=20as=20length,=20endianness,=20and=20=
definition.=0AEBML=20Elements=20which=20are=20defined=20as=20a=20=
Signed=20Integer=20Element,=20Unsigned=20Integer=20Element,=20Float=20=
Element,=20or=20Date=20Element=20use=20big=20endian=20storage.=0A=0A=
Signed=20Integer=20=
Element=0AA=20Signed=20Integer=20Element=20MUST=20declare=20a=20=
length=20from=20zero=20to=20eight=20octets.=20If=20the=20EBML=20Element=20=
is=20not=20defined=20to=20have=20a=20default=20value,=20then=20a=20=
Signed=20Integer=20Element=20with=20a=20zero-octet=20length=20represents=20=
an=20integer=20value=20of=20zero.=0AA=20Signed=20Integer=20=
Element=20stores=20an=20integer=20(meaning=20that=20it=20can=20be=20=
written=20without=20a=20fractional=20component)=20which=20could=20be=20=
negative,=20positive,=20or=20zero.=20Signed=20Integers=20are=20stored=20=
with=20two's=20complement=20notation=20with=20the=20leftmost=20bit=20=
being=20the=20sign=20bit.=20Because=20EBML=20limits=20Signed=20Integers=20=
to=208=20octets=20in=20length=20a=20Signed=20Integer=20Element=20stores=20=
a=20number=20from=20=E2=88=929,223,372,036,854,775,808=20to=20=
+9,223,372,036,854,775,807.=0A=0A=0AUnsigned=20Integer=20=
Element=0AAn=20Unsigned=20Integer=20Element=20MUST=20declare=20=
a=20length=20from=20zero=20to=20eight=20octets.=20If=20the=20EBML=20=
Element=20is=20not=20defined=20to=20have=20a=20default=20value,=20then=20=
an=20Unsigned=20Integer=20Element=20with=20a=20zero-octet=20length=20=
represents=20an=20integer=20value=20of=20zero.=0AAn=20Unsigned=20=
Integer=20Element=20stores=20an=20integer=20(meaning=20that=20it=20can=20=
be=20written=20without=20a=20fractional=20component)=20which=20could=20=
be=20positive=20or=20zero.=20Because=20EBML=20limits=20Unsigned=20=
Integers=20to=208=20octets=20in=20length=20an=20Unsigned=20Integer=20=
Element=20stores=20a=20number=20from=200=20to=20=
18,446,744,073,709,551,615.=0A=0A=0AFloat=20Element=0AA=20Float=20=
Element=20MUST=20declare=20a=20length=20of=20either=20zero=20octet=20(0=20=
bit),=20four=20octets=20(32=20bit)=20or=20eight=20octets=20(64=20bit).=20=
If=20the=20EBML=20Element=20is=20not=20defined=20to=20have=20a=20default=20=
value,=20then=20a=20Float=20Element=20with=20a=20zero-octet=20length=20=
represents=20a=20numerical=20value=20of=20zero.=0AA=20Float=20=
Element=20stores=20a=20floating-point=20number=20as=20defined=20in=20=
.=0A=0A=0AString=20Element=0AA=20String=20=
Element=20MUST=20declare=20a=20length=20in=20octets=20from=20zero=20to=20=
VINTMAX.=20If=20the=20EBML=20Element=20is=20not=20defined=20to=20have=20=
a=20default=20value,=20then=20a=20String=20Element=20with=20a=20=
zero-octet=20length=20represents=20an=20empty=20string.=0AA=20=
String=20Element=20MUST=20either=20be=20empty=20(zero-length)=20or=20=
contain=20printable=20ASCII=20characters=20=20in=20the=20range=20of=200x20=20to=200x7E,=20=
with=20an=20exception=20made=20for=20termination=20(see=20the=20section=20on=20the=20Terminating=20=
Elements).=0A=0A=0AUTF-8=20Element=0AA=20UTF-8=20=
Element=20MUST=20declare=20a=20length=20in=20octets=20from=20zero=20to=20=
VINTMAX.=20If=20the=20EBML=20Element=20is=20not=20defined=20to=20have=20=
a=20default=20value,=20then=20a=20UTF-8=20Element=20with=20a=20=
zero-octet=20length=20represents=20an=20empty=20string.=0AA=20=
UTF-8=20Element=20contains=20only=20a=20valid=20Unicode=20string=20as=20=
defined=20in=20,=20with=20an=20=
exception=20made=20for=20termination=20(see=20the=20section=20on=20the=20Terminating=20=
Elements).=0A=0A=0ADate=20Element=0AA=20Date=20=
Element=20MUST=20declare=20a=20length=20of=20either=20zero=20octets=20or=20=
eight=20octets.=20If=20the=20EBML=20Element=20is=20not=20defined=20to=20=
have=20a=20default=20value,=20then=20a=20Date=20Element=20with=20a=20=
zero-octet=20length=20represents=20a=20timestamp=20of=20=
2001-01-01T00:00:00.000000000=20UTC=20.=0AThe=20Date=20Element=20stores=20an=20=
integer=20in=20the=20same=20format=20as=20the=20Signed=20Integer=20=
Element=20that=20expresses=20a=20point=20in=20time=20referenced=20in=20=
nanoseconds=20from=20the=20precise=20beginning=20of=20the=20third=20=
millennium=20of=20the=20Gregorian=20Calendar=20in=20Coordinated=20=
Universal=20Time=20(also=20known=20as=202001-01-01T00:00:00.000000000=20=
UTC).=20This=20provides=20a=20possible=20expression=20of=20time=20from=20=
1708-09-11T00:12:44.854775808=20UTC=20to=202293-04-11T11:47:16.854775807=20=
UTC.=0A=0A=0AMaster=20Element=0AA=20Master=20=
Element=20MUST=20declare=20a=20length=20in=20octets=20from=20zero=20to=20=
VINTMAX.=20The=20Master=20Element=20MAY=20also=20use=20an=20unknown=20=
length.=20See=20the=20section=20on=20=
Element=20Data=20Size=20for=20rules=20that=20apply=20to=20=
elements=20of=20unknown=20length.=0AThe=20Master=20Element=20=
contains=20zero,=20one,=20or=20many=20other=20elements.=20EBML=20=
Elements=20contained=20within=20a=20Master=20Element=20MUST=20have=20the=20=
EBMLParentPath=20of=20their=20Element=20Path=20equal=20to=20the=20=
EBMLMasterPath=20of=20the=20Master=20Element=20Element=20Path=20(see=20=
the=20section=20on=20the=20EBML=20Path).=20=
Element=20Data=20stored=20within=20Master=20Elements=20SHOULD=20only=20=
consist=20of=20EBML=20Elements=20and=20SHOULD=20NOT=20contain=20any=20=
data=20that=20is=20not=20part=20of=20an=20EBML=20Element.=20The=20EBML=20=
Schema=20identifies=20what=20Element=20IDs=20are=20valid=20within=20the=20=
Master=20Elements=20for=20that=20version=20of=20the=20EBML=20Document=20=
Type.=20Any=20data=20contained=20within=20a=20Master=20Element=20that=20=
is=20not=20part=20of=20a=20Child=20Element=20MUST=20be=20ignored.=0A=
=0A=0ABinary=20=
Element=0AA=20Binary=20Element=20MUST=20declare=20a=20length=20=
in=20octets=20from=20zero=20to=20VINTMAX.=0AThe=20contents=20of=20=
a=20Binary=20Element=20should=20not=20be=20interpreted=20by=20the=20EBML=20=
Reader.=0A=0A=0A=0AEBML=20Document=0AAn=20EBML=20=
Document=20is=20comprised=20of=20only=20two=20components,=20an=20EBML=20=
Header=20and=20an=20EBML=20Body.=20An=20EBML=20Document=20MUST=20start=20=
with=20an=20EBML=20Header=20that=20declares=20significant=20=
characteristics=20of=20the=20entire=20EBML=20Body.=20An=20EBML=20=
Document=20consists=20of=20EBML=20Elements=20and=20MUST=20NOT=20contain=20=
any=20data=20that=20is=20not=20part=20of=20an=20EBML=20Element.=0A=0A=
EBML=20Header=0AThe=20=
EBML=20Header=20is=20a=20declaration=20that=20provides=20processing=20=
instructions=20and=20identification=20of=20the=20EBML=20Body.=20The=20=
EBML=20Header=20of=20an=20EBML=20Document=20is=20analogous=20to=20the=20=
XML=20Declaration=20of=20an=20XML=20Document.=0AThe=20EBML=20=
Header=20documents=20the=20EBML=20Schema=20(also=20known=20as=20the=20=
EBML=20DocType)=20that=20is=20used=20to=20semantically=20interpret=20the=20=
structure=20and=20meaning=20of=20the=20EBML=20Document.=20Additionally=20=
the=20EBML=20Header=20documents=20the=20versions=20of=20both=20EBML=20=
and=20the=20EBML=20Schema=20that=20were=20used=20to=20write=20the=20EBML=20=
Document=20and=20the=20versions=20required=20to=20read=20the=20EBML=20=
Document.=0AThe=20EBML=20Header=20MUST=20contain=20a=20single=20=
Master=20Element=20with=20an=20Element=20Name=20of=20EBML=20and=20=
Element=20ID=20of=200x1A45DFA3=20(see=20the=20definition=20of=20the=20EBML=20=
Element)=20and=20any=20number=20of=20additional=20EBML=20Elements=20=
within=20it.=20The=20EBML=20Header=20of=20an=20EBML=20Document=20that=20=
uses=20an=20EBMLVersion=20of=201=20MUST=20only=20contain=20EBML=20=
Elements=20that=20are=20defined=20as=20part=20of=20this=20document.=0A=
=0A=0AEBML=20Body=0A=
All=20data=20of=20an=20EBML=20Document=20following=20the=20EBML=20=
Header=20is=20the=20EBML=20Body.=20The=20end=20of=20the=20EBML=20Body,=20=
as=20well=20as=20the=20end=20of=20the=20EBML=20Document=20that=20=
contains=20the=20EBML=20Body,=20is=20reached=20at=20whichever=20comes=20=
first:=20the=20beginning=20of=20a=20new=20EBML=20Header=20at=20the=20=
Root=20Level=20or=20the=20end=20of=20the=20file.=20The=20EBML=20Body=20=
MUST=20NOT=20contain=20any=20data=20that=20is=20not=20part=20of=20an=20=
EBML=20Element.=20This=20document=20defines=20precisely=20which=20EBML=20=
Elements=20are=20to=20be=20used=20within=20the=20EBML=20Header,=20but=20=
does=20not=20name=20or=20define=20which=20EBML=20Elements=20are=20to=20=
be=20used=20within=20the=20EBML=20Body.=20The=20definition=20of=20which=20=
EBML=20Elements=20are=20to=20be=20used=20within=20the=20EBML=20Body=20is=20=
defined=20by=20an=20EBML=20Schema.=0A=0A=0A=0A=
EBML=20Stream=0AAn=20=
EBML=20Stream=20is=20a=20file=20that=20consists=20of=20one=20or=20more=20=
EBML=20Documents=20that=20are=20concatenated=20together.=20An=20=
occurrence=20of=20a=20EBML=20Header=20at=20the=20Root=20Level=20marks=20=
the=20beginning=20of=20an=20EBML=20Document.=0A=0A=0A=
EBML=20Versioning=0A=
An=20EBML=20Document=20handles=202=20different=20versions:=20the=20=
version=20of=20the=20EBML=20Header=20and=20the=20version=20of=20the=20=
EBML=20Body.=20Both=20versions=20are=20meant=20to=20be=20backward=20=
compatible.=0A=0AEBML=20=
Header=20Version=0AThe=20version=20of=20the=20EBML=20Header=20=
is=20found=20in=20EBMLVersion.=20An=20EBML=20parser=20can=20read=20an=20=
EBML=20Header=20if=20it=20can=20read=20either=20the=20EBMLVersion=20=
version=20or=20a=20version=20equal=20or=20higher=20than=20the=20one=20=
found=20in=20EBMLReadVersion.=0A=0A=0AEBML=20Document=20Version=0A=
The=20version=20of=20the=20EBML=20Body=20is=20found=20in=20=
EBMLDocTypeVersion.=20A=20parser=20for=20the=20particular=20DocType=20=
format=20can=20read=20the=20EBML=20Document=20if=20it=20can=20read=20=
either=20the=20EBMLDocTypeVersion=20version=20of=20that=20format=20or=20=
a=20version=20equal=20or=20higher=20than=20the=20one=20found=20in=20=
EBMLDocTypeReadVersion.=0A=0A=0A=0AElements=20semantic=0A=0A=
EBML=20Schema=0AAn=20=
EBML=20Schema=20is=20a=20well-formed=20XML=20Document=20=20that=20defines=20the=20=
properties,=20arrangement,=20and=20usage=20of=20EBML=20Elements=20that=20=
compose=20a=20specific=20EBML=20Document=20Type.=20The=20relationship=20=
of=20an=20EBML=20Schema=20to=20an=20EBML=20Document=20is=20analogous=20=
to=20the=20relationship=20of=20an=20XML=20Schema=20=20to=20an=20XML=20=
Document=20.=20An=20EBML=20=
Schema=20MUST=20be=20clearly=20associated=20with=20one=20or=20more=20=
EBML=20Document=20Types.=20An=20EBML=20Document=20Type=20is=20identified=20=
by=20a=20string=20stored=20within=20the=20EBML=20Header=20in=20the=20=
DocType=20Element;=20for=20example=20matroska=20or=20webm=20(see=20the=20definition=20of=20the=20DocType=20=
Element).=20The=20DocType=20value=20for=20an=20EBML=20Document=20=
Type=20MUST=20be=20unique=20and=20persistent.=0AAn=20EBML=20=
Schema=20MUST=20declare=20exactly=20one=20EBML=20Element=20at=20Root=20=
Level=20(referred=20to=20as=20the=20Root=20Element)=20that=20occurs=20=
exactly=20once=20within=20an=20EBML=20Document.=20The=20Void=20Element=20=
MAY=20also=20occur=20at=20Root=20Level=20but=20is=20not=20a=20Root=20=
Element=20(see=20the=20definition=20of=20=
the=20Void=20Element).=0AThe=20EBML=20Schema=20MUST=20=
document=20all=20Elements=20of=20the=20EBML=20Body.=20The=20EBML=20=
Schema=20does=20not=20document=20Global=20Elements=20that=20are=20=
defined=20by=20this=20document=20(namely=20the=20Void=20Element=20and=20=
the=20CRC-32=20Element).=0AThe=20EBML=20Schema=20MUST=20NOT=20use=20=
the=20Element=20ID=200x1A45DFA3=20which=20is=20reserved=20for=20=
the=20EBML=20Header=20for=20resynchronization=20purpose.=0AAn=20=
EBML=20Schema=20MAY=20constrain=20the=20use=20of=20EBML=20Header=20=
Elements=20(see=20EBML=20Header=20=
Elements)=20by=20adding=20or=20constraining=20that=20Element's=20=
range=20attribute.=20For=20example,=20an=20EBML=20Schema=20MAY=20=
constrain=20the=20EBMLMaxSizeLength=20to=20a=20maximum=20value=20of=20=
8=20or=20MAY=20constrain=20the=20EBMLVersion=20to=20only=20=
support=20a=20value=20of=201.=20If=20an=20EBML=20Schema=20=
adopts=20the=20EBML=20Header=20Element=20as-is,=20then=20it=20is=20not=20=
required=20to=20document=20that=20Element=20within=20the=20EBML=20=
Schema.=20If=20an=20EBML=20Schema=20constrains=20the=20range=20of=20an=20=
EBML=20Header=20Element,=20then=20that=20Element=20MUST=20be=20=
documented=20within=20an=20<element>=20node=20of=20the=20=
EBML=20Schema.=20This=20document=20provides=20an=20example=20of=20an=20=
EBML=20Schema,=20see=20EBML=20=
Schema=20Example.=0A=0AEBML=20Schema=20Example=0A=0A=
<?xml=20version=3D"1.0"=20=
encoding=3D"utf-8"?>=0A<EBMLSchema=20=
xmlns=3D"https://ietf.org/cellar/ebml"=0A=20=20=
docType=3D"files-in-ebml-demo"=20version=3D"1">=0A=
=20<!--=20constraints=20to=20the=20range=20of=20two=20EBML=20Header=20=
Elements=20-->=0A=20<element=20name=3D"EBMLReadVersion"=20=
path=3D"1*1(\EBML\EBMLReadVersion)"=0A=20=20=20=
id=3D"0x42F7"=20minOccurs=3D"1"=20=
maxOccurs=3D"1"=20range=3D"1"=20=
default=3D"1"=0A=20=20=20type=3D"uinteger"/>=0A=20=
<element=20name=3D"EBMLMaxSizeLength"=0A=20=20=20=
path=3D"1*1(\EBML\EBMLMaxSizeLength)"=20id=3D"0x42F3"=20=
minOccurs=3D"1"=0A=20=20=20maxOccurs=3D"1"=20=
range=3D"8"=20default=3D"8"=20=
type=3D"uinteger"/>=0A=20<!--=20Root=20Element-->=0A=20=
<element=20name=3D"Files"=20path=3D"*1(\Files)"=20=
id=3D"0x1946696C"=0A=20=20=20type=3D"master">=0A=20=
=20<documentation=20lang=3D"en"=20=
purpose=3D"definition">Container=20of=20data=20and=0A=20=20=
attributes=20representing=20one=20or=20many=20=
files.</documentation>=0A=20</element>=0A=20<element=20=
name=3D"File"=20path=3D"1*(\Files\File)"=20=
id=3D"0x6146"=0A=20=20=20type=3D"master"=20=
minOccurs=3D"1">=0A=20=20<documentation=20=
lang=3D"en"=20purpose=3D"definition">=0A=20=20=20=20=
An=20attached=20file.=0A=20=20</documentation>=0A=20=
</element>=0A=20<element=20name=3D"FileName"=20=
path=3D"1*1(\Files\File\FileName)"=0A=20=20=20=
id=3D"0x614E"=20type=3D"utf-8"=0A=20=20=20=
minOccurs=3D"1">=0A=20=20<documentation=20=
lang=3D"en"=20purpose=3D"definition">=0A=20=20=20=20=
Filename=20of=20the=20attached=20file.=0A=20=20</documentation>=0A=20=
</element>=0A=20<element=20name=3D"MimeType"=20=
path=3D"1*1(\Files\File\MimeType)"=0A=20=20=20=
id=3D"0x464D"=20type=3D"string"=0A=20=20=20=20=20=
minOccurs=3D"1">=0A=20=20<documentation=20=
lang=3D"en"=20purpose=3D"definition">=0A=20=20=20=20=
MIME=20type=20of=20the=20file.=0A=20=20</documentation>=0A=20=
</element>=0A=20<element=20=
name=3D"ModificationTimestamp"=0A=20=20=20=
path=3D"1*1(\Files\File\ModificationTimestamp)"=20=
id=3D"0x4654"=0A=20=20=20type=3D"date"=20=
minOccurs=3D"1">=0A=20=20<documentation=20=
lang=3D"en"=20purpose=3D"definition">=0A=20=20=20=20=
Modification=20timestamp=20of=20the=20file.=0A=20=20=
</documentation>=0A=20</element>=0A=20<element=20=
name=3D"Data"=20path=3D"1*1(\Files\File\Data)"=20=
id=3D"0x4664"=20=0A=20=20=20type=3D"binary"=20=
minOccurs=3D"1">=0A=20=20<documentation=20=
lang=3D"en"=20purpose=3D"definition">=0A=20=20=20=20=
The=20data=20of=20the=20file.=0A=20=20</documentation>=0A=20=
</element>=0A</EBMLSchema>=0A=0A=0A=0A=
<EBMLSchema>=20=
Element=0AAs=20an=20XML=20Document,=20the=20EBML=20Schema=20=
MUST=20use=20<EBMLSchema>=20as=20the=20top=20level=20=
element.=20The=20<EBMLSchema>=20element=20can=20contain=20=
<element>=20sub-elements.=0A=0A=0A<EBMLSchema>=20=
Attributes=0AWithin=20an=20EBML=20Schema=20the=20=
<EBMLSchema>=20element=20uses=20the=20following=20=
attributes:=0A=0AdocType=0A=
The=20docType=20lists=20the=20official=20name=20of=20the=20EBML=20=
Document=20Type=20that=20is=20defined=20by=20the=20EBML=20Schema;=20for=20=
example,=20<EBMLSchema=20=
docType=3D"matroska">.=0AThe=20docType=20=
attribute=20is=20REQUIRED=20within=20the=20<EBMLSchema>=20=
Element.=0A=0A=0Aversion=0AThe=20version=20lists=20a=20=
non-negative=20integer=20that=20specifies=20the=20version=20of=20the=20=
docType=20documented=20by=20the=20EBML=20Schema.=20Unlike=20XML=20=
Schemas,=20an=20EBML=20Schema=20documents=20all=20versions=20of=20a=20=
docType's=20definition=20rather=20than=20using=20separate=20EBML=20=
Schemas=20for=20each=20version=20of=20a=20docType.=20EBML=20Elements=20=
may=20be=20introduced=20and=20deprecated=20by=20using=20the=20minver=20=
and=20maxver=20attributes=20of=20<element>.=0AThe=20=
version=20attribute=20is=20REQUIRED=20within=20the=20=
<EBMLSchema>=20Element.=0A=0A=0A=0A=
<element>=20=
Element=0AEach=20<element>=20defines=20one=20=
EBML=20Element=20through=20the=20use=20of=20several=20attributes=20that=20=
are=20defined=20in=20EBML=20=
Schema=20Element=20Attributes.=20EBML=20Schemas=20MAY=20contain=20=
additional=20attributes=20to=20extend=20the=20semantics=20but=20MUST=20=
NOT=20conflict=20with=20the=20definitions=20of=20the=20=
<element>=20attributes=20defined=20within=20this=20=
document.=0AThe=20<element>=20nodes=20contain=20a=20=
description=20of=20the=20meaning=20and=20use=20of=20the=20EBML=20Element=20=
stored=20within=20one=20or=20more=20<documentation>=20=
sub-elements,=20followed=20by=20optional=20=
<implementation_note>=20sub-elements,=20followed=20by=20=
zero=20or=20one=20<restriction>=20sub-element,=20followed=20=
by=20optional=20<extension>=20sub-elements.=20All=20=
<element>=20nodes=20MUST=20be=20sub-elements=20of=20the=20=
<EBMLSchema>.=0A=0A=0A<element>=20Attributes=0A=
Within=20an=20EBML=20Schema=20the=20<element>=20uses=20=
the=20following=20attributes=20to=20define=20an=20EBML=20Element:=0A=0A=
name=0AThe=20name=20provides=20=
the=20human-readable=20name=20of=20the=20EBML=20Element.=20The=20value=20=
of=20the=20name=20MUST=20be=20in=20the=20form=20of=20characters=20=
"A"=20to=20"Z",=20"a"=20to=20=
"z",=20"0"=20to=20"9",=20"-"=20=
and=20".".=0AThe=20name=20attribute=20is=20=
REQUIRED.=0A=0A=0Apath=0AThe=20path=20defines=20the=20=
allowed=20storage=20locations=20of=20the=20EBML=20Element=20within=20an=20=
EBML=20Document.=20This=20path=20MUST=20be=20defined=20with=20the=20full=20=
hierarchy=20of=20EBML=20Elements=20separated=20with=20a=20\.=20=
The=20top=20EBML=20Element=20in=20the=20path=20hierarchy=20being=20the=20=
first=20in=20the=20value.=20The=20syntax=20of=20the=20path=20attribute=20=
is=20defined=20using=20this=20Augmented=20Backus-Naur=20Form=20(ABNF)=20=
=20with=20the=20case=20sensitive=20=
update=20=20notation:=0AThe=20=
path=20attribute=20is=20REQUIRED.=0A=0AEBMLFullPath=20=20=20=
=20=20=20=20=20=20=20=20=20=20=3D=20EBMLEltOccurrence=20"("=20=
EBMLMasterPath=20")"=0AEBMLMasterPath=20=20=20=20=20=20=20=20=20=
=20=20=3D=20[EBMLParentPath]=20EBMLElementPath=0AEBMLParentPath=20=20=20=20=
=20=20=20=20=20=20=20=3D=20EBMLFixedParent=20EBMLLastParent=0A=
EBMLFixedParent=20=20=20=20=20=20=20=20=20=20=3D=20*(EBMLPathAtom)=0A=
EBMLElementPath=20=20=20=20=20=20=20=20=20=20=3D=20EBMLPathAtom=20/=20=
EBMLPathAtomRecursive=0AEBMLPathAtom=20=20=20=20=20=20=20=20=20=20=20=20=20=
=3D=20PathDelimiter=20EBMLAtomName=0AEBMLPathAtomRecursive=20=20=20=20=3D=20=
"(1*("=20EBMLPathAtom=20"))"=0AEBMLLastParent=20=20=20=
=20=20=20=20=20=20=20=20=3D=20EBMLPathAtom=20/=20EBMLGlobalParent=0A=
EBMLGlobalParent=20=20=20=20=20=20=20=20=20=3D=20"("=20=
GlobalParentOccurence=20"\)"=0AEBMLAtomName=20=20=20=20=20=20=20=
=20=20=20=20=20=20=3D=201*(EBMLNameChar)=0AEBMLNameChar=20=20=20=20=20=20=
=20=20=20=20=20=20=20=3D=20ALPHA=20/=20DIGIT=20/=20"-"=20/=20=
"."=0APathDelimiter=20=20=20=20=20=20=20=20=20=20=20=20=3D=20=
"\"=0AEBMLEltOccurrence=20=20=20=20=20=20=20=20=3D=20=
[EBMLMinOccurrence]=20"*"=20[EBMLMaxOccurrence]=0A=
EBMLMinOccurrence=20=20=20=20=20=20=20=20=3D=201*DIGIT=20;=20no=20upper=20=
limit=0AEBMLMaxOccurrence=20=20=20=20=20=20=20=20=3D=201*DIGIT=20;=20no=20=
upper=20limit=0AGlobalParentOccurence=20=20=20=20=3D=20=
[PathMinOccurrence]=20"*"=20[PathMaxOccurrence]=0A=
PathMinOccurrence=20=20=20=20=20=20=20=20=3D=201*DIGIT=20;=20no=20upper=20=
limit=0APathMaxOccurrence=20=20=20=20=20=20=20=20=3D=201*DIGIT=20;=20no=20=
upper=20limit=0A=0AThe=20*,=20(=20and=20=
)=20symbols=20are=20interpreted=20as=20defined=20in=20.=0AThe=20EBMLPathAtom=20part=20of=20=
the=20EBMLElementPath=20MUST=20be=20equal=20to=20the=20name=20attribute=20=
of=20the=20EBML=20Schema.=0AThe=20starting=20PathDelimiter=20of=20=
the=20path=20corresponds=20to=20the=20root=20of=20the=20EBML=20=
Document.=0AThe=20EBMLEltOccurrence=20part=20is=20interpreted=20=
as=20an=20ABNF=20Variable=20Repetition.=20The=20repetition=20amounts=20=
correspond=20to=20how=20many=20times=20the=20EBML=20Element=20can=20be=20=
found=20in=20its=20Parent=20Element.=0AThe=20EBMLMinOccurrence=20=
represents=20the=20minimum=20permitted=20number=20of=20occurrences=20of=20=
this=20EBML=20Element=20within=20its=20Parent=20Element.=20Each=20=
instance=20of=20the=20Parent=20Element=20MUST=20contain=20at=20least=20=
this=20many=20instances=20of=20this=20EBML=20Element.=20If=20the=20EBML=20=
Element=20has=20an=20empty=20EBMLParentPath=20then=20EBMLMinOccurrence=20=
refers=20to=20constraints=20on=20the=20occurrence=20of=20the=20EBML=20=
Element=20within=20the=20EBML=20Document.=20If=20EBMLMinOccurrence=20is=20=
not=20present=20then=20that=20EBML=20Element=20has=20an=20=
EBMLMinOccurrence=20value=20of=200.=20The=20semantic=20meaning=20of=20=
EBMLMinOccurrence=20within=20an=20EBML=20Schema=20is=20analogous=20to=20=
the=20meaning=20of=20minOccurs=20within=20an=20XML=20Schema.=20EBML=20=
Elements=20with=20EBMLMinOccurrence=20set=20to=20"1"=20that=20=
also=20have=20a=20default=20value=20(see=20default)=20declared=20are=20not=20REQUIRED=20=
to=20be=20stored=20but=20are=20REQUIRED=20to=20be=20interpreted,=20see=20=
Note=20on=20the=20Use=20of=20default=20attributes=20to=20=
define=20Mandatory=20EBML=20Elements.=20An=20EBML=20Element=20=
defined=20with=20a=20EBMLMinOccurrence=20value=20greater=20than=20zero=20=
is=20called=20a=20Mandatory=20EBML=20Element.=0AThe=20=
EBMLMaxOccurrence=20represents=20the=20maximum=20permitted=20number=20of=20=
occurrences=20of=20this=20EBML=20Element=20within=20its=20Parent=20=
Element.=20Each=20instance=20of=20the=20Parent=20Element=20MUST=20=
contain=20at=20most=20this=20many=20instances=20of=20this=20EBML=20=
Element.=20If=20the=20EBML=20Element=20has=20an=20empty=20EBMLParentPath=20=
then=20EBMLMaxOccurrence=20refers=20to=20constraints=20on=20the=20=
occurrence=20of=20the=20EBML=20Element=20within=20the=20EBML=20Document.=20=
If=20EBMLMaxOccurrence=20is=20not=20present=20then=20there=20is=20no=20=
upper=20bound=20for=20the=20permitted=20number=20of=20occurrences=20of=20=
this=20EBML=20Element=20within=20its=20Parent=20Element=20resp.=20within=20=
the=20EBML=20Document=20depending=20on=20whether=20the=20EBMLParentPath=20=
of=20the=20EBML=20Element=20is=20empty=20or=20not.=20The=20semantic=20=
meaning=20of=20EBMLMaxOccurrence=20within=20an=20EBML=20Schema=20path=20=
is=20analogous=20to=20the=20meaning=20of=20maxOccurs=20within=20an=20XML=20=
Schema.=0AIn=20some=20cases=20the=20EBMLLastParent=20part=20of=20=
the=20path=20is=20an=20EBMLGlobalParent.=20A=20path=20with=20a=20=
EBMLGlobalParent=20defines=20a=20Global=20Element.=20Any=20path=20that=20=
starts=20with=20the=20EBMLFixedParent=20of=20the=20Global=20Element=20=
and=20matches=20the=20occurrences=20found=20in=20the=20=
GlobalParentOccurence=20is=20a=20valid=20path=20for=20the=20Global=20=
Element.=0AThe=20GlobalParentOccurence=20part=20is=20interpreted=20=
as=20an=20ABNF=20Variable=20Repetition.=20The=20repetition=20amounts=20=
correspond=20to=20the=20amount=20of=20unspecified=20Parent=20Element=20=
levels=20there=20can=20be=20between=20the=20EBMLFixedParent=20and=20the=20=
actual=20EBMLElementPath.=0APathMinOccurrence=20represents=20the=20=
minimum=20number=20of=20element=20path=20required=20between=20the=20=
EBMLFixedParent=20and=20the=20Global=20Element=20EBMLElementPath.=20For=20=
example=200=20means=20the=20EBMLElementPath=20can=20be=20right=20after=20=
the=20EBMLFixedParent,=201=20means=20there=20has=20to=20be=20at=20least=20=
an=20element=20between=20the=20EBMLFixedParent=20and=20the=20=
EBMLElementPath.=20If=20PathMinOccurrence=20is=20not=20present=20then=20=
that=20EBML=20Element=20has=20an=20PathMinOccurrence=20value=20of=20=
0.=0APathMaxOccurrence=20represents=20the=20maximum=20number=20of=20=
element=20path=20possible=20between=20the=20EBMLFixedParent=20and=20the=20=
Global=20Element=20EBMLElementPath.=20It=20cannot=20have=20the=20value=20=
0=20as=20it=20would=20be=20the=20Global=20Element=20can=20only=20be=20=
found=20right=20after=20the=20EBMLFixedParent,=20in=20which=20case=20=
it's=20not=20a=20Global=20Element=20anymore.=20If=20PathMaxOccurrence=20=
is=20not=20present=20then=20there=20is=20no=20upper=20bound=20for=20the=20=
permitted=20number=20of=20occurrences=20of=20element=20path=20possible=20=
between=20the=20EBMLFixedParent=20and=20the=20Global=20Element=20=
EBMLElementPath.=0AIf=20the=20path=20contains=20an=20=
EBMLPathAtomRecursive=20part,=20the=20EBML=20Element=20can=20occur=20=
within=20itself=20recursively=20(see=20the=20recursive=20attribute).=0AAs=20an=20=
example,=20a=20path=20of=201*(\Segment\Info)=20means=20=
the=20element=20Info=20is=20found=20inside=20the=20Segment=20elements=20=
at=20least=20once=20and=20with=20no=20maximum=20iteration.=20An=20=
element=20SeekHead=20with=20path=200*2(\Segment\SeekHead)=20may=20=
not=20be=20found=20at=20all=20in=20its=20Segment=20parent,=20once=20or=20=
twice=20but=20no=20more=20than=20that.=0A=0A=0Aid=0AThe=20Element=20ID=20encoded=20as=20a=20=
Variable=20Size=20Integer=20expressed=20in=20hexadecimal=20notation=20=
prefixed=20by=20a=200x=20that=20is=20read=20and=20stored=20in=20=
big-endian=20order.=20To=20reduce=20the=20risk=20of=20false=20positives=20=
while=20parsing=20EBML=20Streams,=20the=20Element=20IDs=20of=20the=20=
Root=20Element=20and=20Top-Level=20Elements=20SHOULD=20be=20at=20least=20=
4=20octets=20in=20length.=20Element=20IDs=20defined=20for=20use=20at=20=
Root=20Level=20or=20directly=20under=20the=20Root=20Level=20MAY=20use=20=
shorter=20octet=20lengths=20to=20facilitate=20padding=20and=20optimize=20=
edits=20to=20EBML=20Documents;=20for=20instance,=20the=20Void=20Element=20=
uses=20an=20Element=20ID=20with=20a=20one=20octet=20length=20to=20allow=20=
its=20usage=20in=20more=20writing=20and=20editing=20scenarios.=0A=
The=20id=20attribute=20is=20REQUIRED.=0A=0A=0AminOccurs=0AAn=20integer=20=
expressing=20the=20minimum=20permitted=20number=20of=20occurrences=20of=20=
this=20EBML=20Element=20within=20its=20Parent=20Element.=20The=20=
minOccurs=20value=20MUST=20be=20equal=20to=20the=20EBMLMinOccurrence=20=
value=20of=20the=20path.=0AThe=20minOccurs=20attribute=20is=20=
OPTIONAL.=20If=20the=20minOccurs=20attribute=20is=20not=20present=20then=20=
that=20EBML=20Element=20has=20a=20minOccurs=20value=20of=200.=0A=
=0A=0AmaxOccurs=0A=
An=20integer=20expressing=20the=20maximum=20permitted=20number=20of=20=
occurrences=20of=20this=20EBML=20Element=20within=20its=20Parent=20=
Element.=20The=20maxOccurs=20value=20MUST=20be=20equal=20to=20the=20=
EBMLMaxOccurrence=20value=20of=20the=20path.=0AThe=20maxOccurs=20=
attribute=20is=20OPTIONAL.=20If=20the=20maxOccurs=20attribute=20is=20not=20=
present=20then=20that=20EBML=20Element=20has=20no=20maximum=20=
occurrence,=20similar=20to=20unbounded=20in=20the=20XML=20world.=0A=
=0A=0Arange=0AA=20=
numerical=20range=20for=20EBML=20Elements=20which=20are=20of=20numerical=20=
types=20(Unsigned=20Integer,=20Signed=20Integer,=20Float,=20and=20Date).=20=
If=20specified=20the=20value=20of=20the=20EBML=20Element=20MUST=20be=20=
within=20the=20defined=20range.=20See=20section=20of=20Expressions=20of=20=
range=20for=20rules=20applied=20to=20expression=20of=20range=20=
values.=0AThe=20range=20attribute=20is=20OPTIONAL.=20If=20the=20=
range=20attribute=20is=20not=20present=20then=20any=20value=20legal=20=
for=20the=20type=20attribute=20is=20valid.=0A=0AExpression=20of=20range=0A=
The=20range=20attribute=20MUST=20only=20be=20used=20with=20EBML=20=
Elements=20that=20are=20either=20signed=20integer,=20unsigned=20integer,=20=
float,=20or=20date.=20The=20expression=20defines=20the=20upper,=20lower,=20=
exact=20or=20excluded=20value=20of=20the=20EBML=20Element=20and=20=
optionally=20an=20upper=20boundary=20value=20combined=20with=20a=20lower=20=
boundary.=20The=20range=20expression=20may=20contain=20whitespace=20=
(using=20the=20ASCII=200x20=20character)=20for=20readability=20but=20=
whitespace=20within=20a=20range=20expression=20MUST=20NOT=20convey=20=
meaning.=0ATo=20set=20a=20fixed=20value=20for=20the=20range,=20=
the=20value=20is=20used=20as=20the=20attribute=20value.=20For=20example=20=
1234=20means=20the=20EBML=20element=20always=20has=20the=20=
value=201234.=20The=20value=20can=20be=20prefixed=20with=20not=20=
to=20indicate=20that=20the=20fixed=20value=20MUST=20NOT=20be=20used=20=
for=20that=20Element.=20For=20example=20not=201234=20means=20=
the=20Element=20can=20use=20all=20values=20of=20its=20type=20except=20=
1234.=0AFor=20an=20exclusive=20lower=20boundary=20the=20=
>=20sign=20is=20used=20and=20the=20>=3D=20sign=20=
is=20used=20for=20an=20inclusive=20lower=20boundary.=20For=20example=20=
>3=20meaning=20the=20Element=20value=20MUST=20be=20greater=20=
than=203=20or=20>=3D0x1p+0=20meaning=20the=20Element=20value=20=
MUST=20be=20greater=20than=20or=20equal=20to=20the=20floating=20value=20=
1.0,=20see=20textual=20=
expression=20of=20floats.=0AFor=20an=20exclusive=20upper=20=
boundary=20the=20<=20sign=20is=20used=20and=20the=20=
<=3D=20sign=20is=20used=20for=20an=20inclusive=20upper=20=
boundary.=20For=20example=20<-2=20meaning=20the=20Element=20=
value=20MUST=20be=20less=20than=20-2=20or=20<=3D10=20meaning=20=
the=20Element=20value=20MUST=20be=20less=20than=20or=20equal=20to=20the=20=
10.=0AThe=20lower=20and=20upper=20bounds=20can=20be=20combined=20=
into=20an=20expression=20to=20form=20a=20closed=20boundary.=20The=20=
lower=20boundary=20coming=20first=20followed=20by=20the=20upper=20=
boundary,=20separated=20by=20a=20comma.=20For=20example=20=
>3,<=3D=2020=20means=20the=20Element=20value=20MUST=20be=20=
greater=20than=203=20and=20less=20than=20or=20equal=20to=2020.=0A=
A=20special=20form=20of=20lower=20and=20upper=20bounds=20using=20the=20=
-=20separator=20is=20possible,=20meaning=20the=20Element=20=
value=20MUST=20be=20greater=20than=20or=20to=20the=20first=20value=20and=20=
MUST=20be=20less=20than=20or=20equal=20to=20the=20second=20value.=20For=20=
example=201-10=20is=20equivalent=20to=20=
>=3D1,<=3D10.=20If=20the=20upper=20boundary=20is=20=
negative,=20only=20the=20latter=20form=20MUST=20be=20used.=0A=
=0A=0A=0Alength=0AA=20value=20to=20express=20=
the=20valid=20length=20of=20the=20Element=20Data=20as=20written=20=
measured=20in=20octets.=20The=20length=20provides=20a=20constraint=20in=20=
addition=20to=20the=20Length=20value=20of=20the=20definition=20of=20the=20=
corresponding=20EBML=20Element=20Type.=20This=20length=20MUST=20be=20=
expressed=20as=20either=20a=20non-negative=20integer=20or=20a=20range=20=
(see=20expression=20of=20=
range)=20that=20consists=20of=20only=20non-negative=20integers=20=
and=20valid=20operators.=0AThe=20length=20attribute=20is=20=
OPTIONAL.=20If=20the=20length=20attribute=20is=20not=20present=20for=20=
that=20EBML=20Element=20then=20that=20EBML=20Element=20is=20only=20=
limited=20in=20length=20by=20the=20definition=20of=20the=20associated=20=
EBML=20Element=20Type.=0A=0A=0Adefault=0AIf=20an=20Element=20is=20=
mandatory=20(has=20a=20EBMLMinOccurrence=20value=20greater=20than=20=
zero)=20but=20not=20written=20within=20its=20Parent=20Element=20or=20=
stored=20as=20an=20Empty=20Element,=20then=20the=20EBML=20Reader=20of=20=
the=20EBML=20Document=20MUST=20semantically=20interpret=20the=20EBML=20=
Element=20as=20present=20with=20this=20specified=20default=20value=20for=20=
the=20EBML=20Element.=20EBML=20Elements=20that=20are=20Master=20Elements=20=
MUST=20NOT=20declare=20a=20default=20value.=20EBML=20Elements=20with=20a=20=
minOccurs=20value=20greater=20than=201=20MUST=20NOT=20declare=20a=20=
default=20value.=0AThe=20default=20attribute=20is=20OPTIONAL.=0A=
=0A=0Atype=0AThe=20=
type=20MUST=20be=20set=20to=20one=20of=20the=20following=20values:=20=
integer=20(signed=20integer),=20uinteger=20(unsigned=20=
integer),=20float,=20string,=20date,=20=
utf-8,=20master,=20or=20binary.=20The=20=
content=20of=20each=20type=20is=20defined=20within=20section=20on=20EBML=20Element=20=
Types.=0AThe=20type=20attribute=20is=20REQUIRED.=0A=
=0A=0Aunknownsizeallowed=0AA=20=
boolean=20to=20express=20if=20an=20EBML=20Element=20is=20permitted=20to=20=
be=20Unknown-Sized=20Element=20(having=20all=20VINT_DATA=20bits=20of=20=
Element=20Data=20Size=20set=20to=201).=20EBML=20Elements=20that=20are=20=
not=20Master=20Elements=20MUST=20NOT=20set=20unknownsizeallowed=20to=20=
true.=20An=20EBML=20Element=20that=20is=20defined=20with=20an=20=
unknownsizeallowed=20attribute=20set=20to=201=20MUST=20also=20have=20the=20=
unknownsizeallowed=20attribute=20of=20its=20Parent=20Element=20set=20to=20=
1.=0AAn=20EBML=20Element=20with=20the=20unknownsizeallowed=20=
attribute=20set=20to=201=20MUST=20NOT=20have=20its=20recursive=20=
attribute=20set=20to=201.=0AThe=20unknownsizeallowed=20attribute=20=
is=20OPTIONAL.=20If=20the=20unknownsizeallowed=20attribute=20is=20not=20=
used=20then=20that=20EBML=20Element=20is=20not=20allowed=20to=20use=20an=20=
unknown=20Element=20Data=20Size.=0A=0A=0Arecursive=0AA=20boolean=20to=20=
express=20if=20an=20EBML=20Element=20is=20permitted=20to=20be=20stored=20=
recursively.=20In=20this=20case=20the=20EBML=20Element=20MAY=20be=20=
stored=20within=20another=20EBML=20Element=20that=20has=20the=20same=20=
Element=20ID.=20Which=20itself=20can=20be=20stored=20in=20an=20EBML=20=
Element=20that=20has=20the=20same=20Element=20ID,=20and=20so=20on.=20=
EBML=20Elements=20that=20are=20not=20Master=20Elements=20MUST=20NOT=20=
set=20recursive=20to=20true.=0AIf=20the=20path=20contains=20an=20=
EBMLPathAtomRecursive=20part=20then=20the=20recursive=20value=20MUST=20=
be=20true=20and=20false=20otherwise.=0AAn=20EBML=20Element=20with=20=
the=20recursive=20attribute=20set=20to=201=20MUST=20NOT=20have=20its=20=
unknownsizeallowed=20attribute=20set=20to=201.=0AThe=20recursive=20=
attribute=20is=20OPTIONAL.=20If=20the=20recursive=20attribute=20is=20not=20=
present=20then=20the=20EBML=20Element=20MUST=20NOT=20be=20used=20=
recursively.=0A=0A=0Arecurring=0AA=20boolean=20to=20=
express=20if=20an=20EBML=20Element=20is=20defined=20as=20an=20=
Identically=20Recurring=20Element=20or=20not.=0AThe=20recurring=20=
attribute=20is=20OPTIONAL.=20If=20the=20recurring=20attribute=20is=20not=20=
present=20then=20the=20EBML=20Element=20is=20not=20an=20Identically=20=
Recurring=20Element.=0A=0A=0Aminver=0AThe=20minver=20(minimum=20=
version)=20attribute=20stores=20a=20non-negative=20integer=20that=20=
represents=20the=20first=20version=20of=20the=20docType=20to=20support=20=
the=20EBML=20Element.=0AThe=20minver=20attribute=20is=20OPTIONAL.=20=
If=20the=20minver=20attribute=20is=20not=20present,=20then=20the=20EBML=20=
Element=20has=20a=20minimum=20version=20of=20"1".=0A=
=0A=0Amaxver=0A=
The=20maxver=20(maximum=20version)=20attribute=20stores=20a=20=
non-negative=20integer=20that=20represents=20the=20last=20or=20most=20=
recent=20version=20of=20the=20docType=20to=20support=20the=20element.=20=
maxver=20MUST=20be=20greater=20than=20or=20equal=20to=20minver.=0A=
The=20maxver=20attribute=20is=20OPTIONAL.=20If=20the=20maxver=20=
attribute=20is=20not=20present=20then=20the=20EBML=20Element=20has=20a=20=
maximum=20version=20equal=20to=20the=20value=20stored=20in=20the=20=
version=20attribute=20of=20<EBMLSchema>.=0A=0A=
=0A=0A<documentation>=20=
Element=0AThe=20<documentation>=20element=20=
provides=20additional=20information=20about=20the=20EBML=20Element.=20=
Within=20the=20<documentation>=20element=20the=20=
following=20XHTML=20=20elements=20MAY=20be=20=
used:=20<a>,=20<br>,=20=
<strong>.=0A=0A=0A<documentation>=20=
Attributes=0A=0Alang=0A=
A=20lang=20attribute=20which=20is=20set=20to=20the=20=20value=20of=20the=20language=20of=20the=20=
element's=20documentation.=0AThe=20lang=20attribute=20is=20=
OPTIONAL.=0A=0A=0Apurpose=0AA=20purpose=20attribute=20=
distinguishes=20the=20meaning=20of=20the=20documentation.=20Values=20for=20=
the=20<documentation>=20sub-element's=20purpose=20=
attribute=20MUST=20include=20one=20of=20the=20following:=20=
definition,=20rationale,=20usage=20notes,=20=
and=20references.=0AThe=20purpose=20attribute=20is=20=
REQUIRED.=0A=0A=0A=0A<implementation_note>=20=
Element=0AIn=20some=20cases=20within=20an=20EBML=20Document=20=
Type,=20the=20attributes=20of=20the=20<element>=20element=20=
are=20not=20sufficient=20to=20clearly=20communicate=20how=20the=20=
defined=20EBML=20Element=20is=20intended=20to=20be=20implemented.=0AFor=20=
instance,=20one=20EBML=20Element=20might=20only=20be=20mandatory=20if=20=
another=20EBML=20Element=20is=20present,=20or=20as=20another=20example,=20=
the=20default=20value=20of=20an=20EBML=20Element=20might=20derive=20from=20=
a=20related=20Element's=20content.=0AIn=20these=20cases=20where=20the=20=
Element's=20definition=20is=20conditional=20or=20advanced=20=
implementation=20notes=20are=20needed,=20one=20or=20many=20=
<implementation_note>=20elements=20can=20be=20used=20to=20=
store=20that=20information.=0AThe=20<implementation_note>=20=
refer=20to=20a=20specific=20attribute=20of=20the=20parent=20=
<element>=20as=20expressed=20by=20the=20=
note_attribute=20attribute=20.=0A=0A=0A<implementation_note>=
;=20Attributes=0A=0Anote_attribute=0AThe=20=
note_attribute=20attribute=20references=20which=20of=20the=20=
<element>'s=20attributes=20that=20the=20=
implementation_note=20is=20in=20regards=20to.=0AThe=20note_attribute=20=
attribute=20MUST=20be=20set=20to=20one=20of=20the=20following=20values=20=
(corresponding=20to=20that=20attribute=20of=20the=20parent=20=
<element>):=20minOccurs,=20maxOccurs,=20=
range,=20length,=20default,=20=
minver,=20or=20maxver.=0AThe=20=
<implementation_note>=20SHALL=20supersede=20the=20parent=20=
<element>'s=20attribute=20that=20is=20named=20in=20the=20=
note_attribute=20attribute.=0AAn=20<element>=20=
SHALL=20NOT=20have=20more=20than=20one=20=
<implementation_note>=20of=20the=20same=20=
note_attribute.=0AThe=20note_attribute=20attribute=20is=20=
REQUIRED.=0A=0A=0A=0A<restriction>=20=
Element=0AThe=20<restriction>=20element=20=
provides=20information=20about=20restrictions=20to=20the=20allowable=20=
values=20for=20the=20EBML=20Element=20which=20are=20listed=20in=20=
<enum>=20elements.=0A=0A=0A<enum>=20Element=0AThe=20=
<enum>=20element=20stores=20a=20list=20of=20values=20=
allowed=20for=20storage=20in=20the=20EBML=20Element.=20The=20values=20=
MUST=20match=20the=20type=20of=20the=20EBML=20Element=20(for=20example=20=
<enum=20value=3D"Yes">=20cannot=20be=20a=20=
valid=20value=20for=20a=20EBML=20Element=20that=20is=20defined=20as=20an=20=
unsigned=20integer).=20An=20<enum>=20element=20MAY=20also=20=
store=20<documentation>=20elements=20to=20further=20=
describe=20the=20<enum>.=0A=0A=0A<enum>=20Attributes=0A=0A=
label=0AThe=20label=20=
provides=20a=20concise=20expression=20for=20human=20consumption=20that=20=
describes=20what=20the=20value=20of=20the=20<enum>=20=
represents.=0AThe=20label=20attribute=20is=20OPTIONAL.=0A=
=0A=0Avalue=0AThe=20=
value=20represents=20data=20that=20MAY=20be=20stored=20within=20the=20=
EBML=20Element.=0AThe=20value=20attribute=20is=20REQUIRED.=0A=
=0A=0A=0A<extension>=20Element=0A=
The=20<extension>=20element=20provides=20an=20=
unconstrained=20element=20to=20contain=20information=20about=20the=20=
associated=20EBML=20<element>=20which=20is=20undefined=20=
by=20this=20document=20but=20MAY=20be=20defined=20by=20the=20associated=20=
EBML=20Document=20Type.=20The=20<extension>=20element=20=
MUST=20contain=20a=20type=20attribute=20and=20also=20MAY=20=
contain=20any=20other=20attribute=20or=20sub-element=20as=20long=20as=20=
the=20EBML=20Schema=20remains=20as=20a=20well-formed=20XML=20Document.=20=
All=20<extension>=20elements=20MUST=20be=20sub-elements=20=
of=20the=20<element>.=0A=0A=0A<extension>=20=
Attributes=0A=0Atype=0A=
The=20type=20attribute=20should=20reference=20a=20name=20or=20=
identifier=20of=20the=20project=20or=20authority=20associated=20with=20=
the=20contents=20of=20the=20<extension>=20element.=0A=
The=20type=20attribute=20is=20REQUIRED.=0A=0A=0A=
=0AXML=20Schema=20=
for=20EBML=20Schema=0AThis=20following=20provides=20an=20XML=20=
Schema=20=20for=20=
facilitating=20verification=20of=20an=20EBML=20Schema=20to=20the=20=
definition=20described=20in=20.=0A=
=0A<?xml=20version=3D"1.0"=20=
encoding=3D"UTF-8"?>=0A<xs:schema=20=
xmlns=3D"https://ietf.org/cellar/ebml"=0A=20=20=
targetNamespace=3D"https://ietf.org/cellar/ebml"=0A=20=20=
xmlns:xs=3D"http://www.w3.org/2001/XMLSchema"=0A=20=20=
xmlns:xhtml=3D"http://www.w3.org/1999/xhtml"=0A=20=20=
elementFormDefault=3D"qualified"=20version=3D"01">=0A=
=0A=20=20<!--=20for=20HTML=20in=20comments=20-->=0A=20=20=
<xs:import=20namespace=3D"http://www.w3.org/1999/xhtml"=0A=20=
=20=20=20=
schemaLocation=3D"http://www.w3.org/MarkUp/SCHEMA/xhtml11.xsd"/&=
gt;=0A=0A=20=20<xs:element=20name=3D"EBMLSchema"=20=
type=3D"EBMLSchemaType"/>=0A=0A=20=20<xs:complexType=20=
name=3D"EBMLSchemaType">=0A=20=20=20=20<xs:sequence>=0A=
=20=20=20=20=20=20<xs:element=20name=3D"element"=20=
type=3D"elementType"=0A=20=20=20=20=20=20=20=20=
minOccurs=3D"0"=20maxOccurs=3D"unbounded"/>=0A=20=20=
=20=20</xs:sequence>=0A=20=20=20=20<xs:attribute=20=
name=3D"docType"=20use=3D"required"/>=0A=20=20=20=20=
<xs:attribute=20name=3D"version"=20=
use=3D"required"/>=0A=20=20</xs:complexType>=0A=0A=20=20=
<xs:complexType=20name=3D"elementType">=0A=20=20=20=20=
<xs:sequence>=0A=20=20=20=20=20=20<xs:element=20=
name=3D"documentation"=20type=3D"documentationType"=0A=
=20=20=20=20=20=20=20=20minOccurs=3D"0"=20=
maxOccurs=3D"unbounded"/>=0A=20=20=20=20=20=20=
<xs:element=20name=3D"implementation_note"=20=
type=3D"noteType"=0A=20=20=20=20=20=20=20=20=
minOccurs=3D"0"=20maxOccurs=3D"unbounded"/>=0A=20=20=
=20=20=20=20<xs:element=20name=3D"restriction"=20=
type=3D"restrictionType"=0A=20=20=20=20=20=20=20=20=
minOccurs=3D"0"=20maxOccurs=3D"1"/>=0A=20=20=20=20=
=20=20<xs:element=20name=3D"extension"=20=
type=3D"extensionType"=0A=20=20=20=20=20=20=20=20=
minOccurs=3D"0"=20maxOccurs=3D"unbounded"/>=0A=20=20=
=20=20</xs:sequence>=0A=20=20=20=20<xs:attribute=20=
name=3D"name"=20use=3D"required"/>=0A=20=20=20=20=
<xs:attribute=20name=3D"path"=20=
use=3D"required"/>=0A=20=20=20=20<xs:attribute=20=
name=3D"id"=20use=3D"required"/>=0A=20=20=20=20=
<xs:attribute=20name=3D"minOccurs"=20=
default=3D"0"/>=0A=20=20=20=20<xs:attribute=20=
name=3D"maxOccurs"=20default=3D"1"/>=0A=20=20=20=20=
<xs:attribute=20name=3D"range"/>=0A=20=20=20=20=
<xs:attribute=20name=3D"length"/>=0A=20=20=20=20=
<xs:attribute=20name=3D"default"/>=0A=20=20=20=20=
<xs:attribute=20name=3D"type"=20=
use=3D"required"/>=0A=20=20=20=20<xs:attribute=20=
name=3D"unknownsizeallowed"/>=0A=20=20=20=20=
<xs:attribute=20name=3D"recurring"/>=0A=20=20=20=20=
<xs:attribute=20name=3D"minver"=20=
default=3D"1"/>=0A=20=20=20=20<xs:attribute=20=
name=3D"maxver"/>=0A=20=20</xs:complexType>=0A=0A=20=20=
<xs:complexType=20name=3D"restrictionType">=0A=20=20=20=20=
<xs:sequence>=0A=20=20=20=20=20=20<xs:element=20=
name=3D"enum"=20type=3D"enumType"=0A=20=20=20=20=20=20=
=20=20minOccurs=3D"0"=20maxOccurs=3D"unbounded"/>=0A=
=20=20=20=20</xs:sequence>=0A=20=20</xs:complexType>=0A=0A=20=
=20<xs:complexType=20name=3D"extensionType">=0A=20=20=20=20=
<xs:sequence>=0A=20=20=20=20=20=20<xs:any=20=
processContents=3D"skip"=0A=20=20=20=20=20=20=20=20=
minOccurs=3D"0"=20maxOccurs=3D"unbounded"/>=0A=20=20=
=20=20</xs:sequence>=0A=20=20=20=20<xs:attribute=20=
name=3D"type"=20use=3D"required"/>=0A=20=20=20=20=
<xs:anyAttribute=20processContents=3D"skip"/>=0A=20=20=
</xs:complexType>=0A=0A=20=20<xs:complexType=20=
name=3D"enumType">=0A=20=20=20=20<xs:sequence>=0A=20=20=
=20=20=20=20<xs:element=20name=3D"documentation"=20=
type=3D"documentationType"=0A=20=20=20=20=20=20=20=20=
minOccurs=3D"0"=20maxOccurs=3D"unbounded"/>=0A=20=20=
=20=20</xs:sequence>=0A=20=20=20=20<xs:attribute=20=
name=3D"label"/>=0A=20=20=20=20<xs:attribute=20=
name=3D"value"=20use=3D"required"/>=0A=20=20=
</xs:complexType>=0A=0A=20=20<xs:complexType=20=
name=3D"documentationType"=20mixed=3D"true">=0A=20=
=20=20=20<xs:sequence>=0A=20=20=20=20=20=20<xs:element=20=
name=3D"a"=20=20=20=20=20=20=
type=3D"xhtml:xhtml.a.type"=20=0A=20=20=20=20=20=20=20=20=
minOccurs=3D"0"=20maxOccurs=3D"unbounded"/>=0A=20=20=
=20=20=20=20<xs:element=20name=3D"br"=20=20=20=20=20=
type=3D"xhtml:xhtml.br.type"=0A=20=20=20=20=20=20=20=20=
minOccurs=3D"0"=20maxOccurs=3D"unbounded"/>=0A=20=20=
=20=20=20=20<xs:element=20name=3D"strong"=20=
type=3D"xhtml:xhtml.strong.type"=0A=20=20=20=20=20=20=20=20=
minOccurs=3D"0"=20maxOccurs=3D"unbounded"/>=0A=20=20=
=20=20</xs:sequence>=0A=20=20=20=20<xs:attribute=20=
name=3D"lang"/>=0A=20=20=20=20<xs:attribute=20=
name=3D"purpose"=20use=3D"required">=0A=20=20=20=20=
=20=20<xs:simpleType>=0A=20=20=20=20=20=20=20=20<xs:restriction=20=
base=3D"xs:string">=0A=20=20=20=20=20=20=20=20=20=20=
<xs:enumeration=20value=3D"definition"/>=0A=20=20=20=20=20=
=20=20=20=20=20<xs:enumeration=20value=3D"rationale"/>=0A=
=20=20=20=20=20=20=20=20=20=20<xs:enumeration=20=
value=3D"references"/>=0A=20=20=20=20=20=20=20=20=20=20=
<xs:enumeration=20value=3D"usage=20notes"/>=0A=20=20=20=20=
=20=20=20=20</xs:restriction>=0A=20=20=20=20=20=20=
</xs:simpleType>=0A=20=20=20=20</xs:attribute>=0A=20=20=
</xs:complexType>=0A=0A=20=20<xs:complexType=20=
name=3D"noteType">=0A=20=20=20=20<xs:simpleContent>=0A=
=20=20=20=20=20=20<xs:extension=20base=3D"xs:string">=0A=20=
=20=20=20=20=20=20=20<xs:attribute=20name=3D"note_attribute"=20=
use=3D"required">=0A=20=20=20=20=20=20=20=20=20=20=
<xs:simpleType>=0A=20=20=20=20=20=20=20=20=20=20=20=20=
<xs:restriction=20base=3D"xs:string">=0A=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20<xs:enumeration=20=
value=3D"minOccurs"/>=0A=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20<xs:enumeration=20value=3D"maxOccurs"/>=0A=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20<xs:enumeration=20=
value=3D"range"/>=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
<xs:enumeration=20value=3D"length"/>=0A=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20<xs:enumeration=20=
value=3D"default"/>=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20<xs:enumeration=20value=3D"minver"/>=0A=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20<xs:enumeration=20=
value=3D"maxver"/>=0A=20=20=20=20=20=20=20=20=20=20=20=20=
</xs:restriction>=0A=20=20=20=20=20=20=20=20=20=20=
</xs:simpleType>=0A=20=20=20=20=20=20=20=20</xs:attribute>=0A=
=20=20=20=20=20=20</xs:extension>=0A=20=20=20=20=
</xs:simpleContent>=0A=20=20</xs:complexType>=0A=
</xs:schema>=0A=0A=0A=0AIdentically=20Recurring=20=
Elements=0AAn=20Identically=20Recurring=20Element=20is=20an=20=
EBML=20Element=20that=20MAY=20occur=20within=20its=20Parent=20Element=20=
more=20than=20once=20but=20that=20each=20recurrence=20within=20that=20=
Parent=20Element=20MUST=20be=20identical=20both=20in=20storage=20and=20=
semantics.=20Identically=20Recurring=20Elements=20are=20permitted=20to=20=
be=20stored=20multiple=20times=20within=20the=20same=20Parent=20Element=20=
in=20order=20to=20increase=20data=20resilience=20and=20optimize=20the=20=
use=20of=20EBML=20in=20transmission.=20For=20instance=20a=20pertinent=20=
Top-Level=20Element=20could=20be=20periodically=20resent=20within=20a=20=
data=20stream=20so=20that=20an=20EBML=20Reader=20which=20starts=20=
reading=20the=20stream=20from=20the=20middle=20could=20better=20=
interpret=20the=20contents.=20Identically=20Recurring=20Elements=20=
SHOULD=20include=20a=20CRC-32=20Element=20as=20a=20Child=20Element;=20=
this=20is=20especially=20recommended=20when=20EBML=20is=20used=20for=20=
long-term=20storage=20or=20transmission.=20If=20a=20Parent=20Element=20=
contains=20more=20than=20one=20copy=20of=20an=20Identically=20Recurring=20=
Element=20which=20includes=20a=20CRC-32=20Element=20as=20a=20Child=20=
Element=20then=20the=20first=20instance=20of=20the=20Identically=20=
Recurring=20Element=20with=20a=20valid=20CRC-32=20value=20should=20be=20=
used=20for=20interpretation.=20If=20a=20Parent=20Element=20contains=20=
more=20than=20one=20copy=20of=20an=20Identically=20Recurring=20Element=20=
which=20does=20not=20contain=20a=20CRC-32=20Element=20or=20if=20CRC-32=20=
Elements=20are=20present=20but=20none=20are=20valid=20then=20the=20first=20=
instance=20of=20the=20Identically=20Recurring=20Element=20should=20be=20=
used=20for=20interpretation.=0A=0A=0ATextual=20expression=20of=20=
floats=0AWhen=20a=20float=20value=20is=20represented=20=
textually=20in=20an=20EBML=20Schema,=20such=20as=20within=20a=20default=20=
or=20range=20value,=20the=20float=20values=20MUST=20be=20expressed=20as=20=
Hexadecimal=20Floating-Point=20Constants=20as=20defined=20in=20the=20C11=20=
standard=20=20(see=20section=20=
6.4.4.2=20on=20Floating=20Constants).=20The=20following=20table=20=
provides=20examples=20of=20expressions=20of=20float=20ranges.=0A=
=0A=0A=0Aas=20decimal=0Aas=20Hexadecimal=20Floating-Point=20Constants=0A=
=0A=0A=0A=0A=0A0.0=0A=
0x0p+1=0A=0A=0A=0A0.0-1.0=0A0x0p+1-0x1p+0=0A=0A=0A=0A1.0-256.0=0A0x1p+0-0x1p+8=0A=0A=0A=0A0.857421875=0A0x1.b7p-1=0A=0A=0A=0A-1.0--0.857421875=0A-0x1p+0--0x1.b7p-1=0A=0A=0A=

Within=20an=20expression=20of=20a=20float=20range,=20as=20in=20=
an=20integer=20range,=20the=20-=20(hyphen)=20character=20is=20the=20=
separator=20between=20the=20minimal=20and=20maximum=20value=20permitted=20=
by=20the=20range.=20Hexadecimal=20Floating-Point=20Constants=20also=20=
use=20a=20-=20(hyphen)=20when=20indicating=20a=20negative=20binary=20=
power.=20Within=20a=20float=20range,=20when=20a=20-=20(hyphen)=20is=20=
immediately=20preceded=20by=20a=20letter=20p,=20then=20the=20-=20=
(hyphen)=20is=20a=20part=20of=20the=20Hexadecimal=20Floating-Point=20=
Constant=20which=20notes=20negative=20binary=20power.=20Within=20a=20=
float=20range,=20when=20a=20-=20(hyphen)=20is=20not=20immediately=20=
preceded=20by=20a=20letter=20p,=20then=20the=20-=20(hyphen)=20represents=20=
the=20separator=20between=20the=20minimal=20and=20maximum=20value=20=
permitted=20by=20the=20range.=0A=0A=0ANote=20on=20the=20use=20of=20default=20attributes=20to=20=
define=20Mandatory=20EBML=20Elements=0AIf=20a=20Mandatory=20=
EBML=20Element=20has=20a=20default=20value=20declared=20by=20an=20EBML=20=
Schema=20and=20the=20value=20of=20the=20EBML=20Element=20is=20equal=20to=20=
the=20declared=20default=20value=20then=20that=20EBML=20Element=20is=20=
not=20required=20to=20be=20present=20within=20the=20EBML=20Document=20if=20=
its=20Parent=20Element=20is=20present.=20In=20this=20case,=20the=20=
default=20value=20of=20the=20Mandatory=20EBML=20Element=20MUST=20be=20=
read=20by=20the=20EBML=20Reader=20although=20the=20EBML=20Element=20is=20=
not=20present=20within=20its=20Parent=20Element.=0AIf=20a=20=
Mandatory=20EBML=20Element=20has=20no=20default=20value=20declared=20by=20=
an=20EBML=20Schema=20and=20its=20Parent=20Element=20is=20present=20then=20=
the=20EBML=20Element=20MUST=20be=20present=20as=20well.=20If=20a=20=
Mandatory=20EBML=20Element=20has=20a=20default=20value=20declared=20by=20=
an=20EBML=20Schema=20and=20its=20Parent=20Element=20is=20present=20and=20=
the=20value=20of=20the=20EBML=20Element=20is=20NOT=20equal=20to=20the=20=
declared=20default=20value=20then=20the=20EBML=20Element=20MUST=20be=20=
present.=0AThis=20table=20clarifies=20if=20a=20Mandatory=20EBML=20=
Element=20MUST=20be=20written,=20according=20to=20if=20the=20default=20=
value=20is=20declared,=20if=20the=20value=20of=20the=20EBML=20Element=20=
is=20equal=20to=20the=20declared=20default=20value,=20and=20if=20the=20=
Parent=20Element=20is=20used.=0A=0A=0A=0AIs=20the=20default=20value=20declared?=0AIs=20the=20value=20equal=20to=20default?=0AIs=20the=20Parent=20Element=20present?=0AThen=20is=20storing=20the=20EBML=20Element=20=
REQUIRED?=0A=0A=0A=0A=0A=0AYes=0AYes=0AYes=0ANo=0A=0A=0A=
=0AYes=0AYes=0A=
No=0ANo=0A=0A=
=0A=0AYes=0ANo=
=0AYes=0AYes=0A=
=0A=0A=0AYes=0ANo=0ANo=0ANo=0A=0A=0A=0ANo=0An/a=0AYes=0AYes=0A=0A=0A=
=0ANo=0An/a=0A=
No=0ANo=0A=0A=
=0A
=0A=0A=0AEBML=20Header=20Elements=0A=
This=20document=20contains=20definitions=20of=20all=20EBML=20Elements=20=
of=20the=20EBML=20Header.=0A=0AEBML=20Element=0Aname:=20=
EBML=0Apath:=201*1(\EBML)=0Aid:=200x1A45DFA3=0A=
minOccurs:=201=0AmaxOccurs:=201=0Atype:=20Master=20=
Element=0Adescription:=20Set=20the=20EBML=20characteristics=20of=20=
the=20data=20to=20follow.=20Each=20EBML=20Document=20has=20to=20start=20=
with=20this.=0A=0A=0AEBMLVersion=20Element=0A=
name:=20EBMLVersion=0Apath:=20=
1*1(\EBML\EBMLVersion)=0Aid=200x4286=0AminOccurs:=20=
1=0AmaxOccurs:=201=0Arange:=20not=200=0Adefault:=20=
1=0Atype:=20Unsigned=20Integer=0Adescription:=20The=20=
version=20of=20EBML=20specifications=20used=20to=20create=20the=20EBML=20=
Document.=20The=20version=20of=20EBML=20defined=20in=20this=20document=20=
is=201,=20so=20EBMLVersion=20SHOULD=20be=201.=0A=0A=0A=
EBMLReadVersion=20=
Element=0Aname:=20EBMLReadVersion=0Apath:=20=
1*1(\EBML\EBMLReadVersion)=0Aid:=200x42F7=0A=
minOccurs:=201=0AmaxOccurs:=201=0Arange:=201=0A=
default:=201=0Atype:=20Unsigned=20Integer=0A=
description:=20The=20minimum=20EBML=20version=20an=20EBML=20Reader=20=
has=20to=20support=20to=20read=20this=20EBML=20Document.=20The=20=
EBMLReadVersion=20Element=20MUST=20be=20less=20than=20or=20equal=20to=20=
EBMLVersion.=0A=0A=0AEBMLMaxIDLength=20=
Element=0Aname:=20EBMLMaxIDLength=0Apath:=20=
1*1(\EBML\EBMLMaxIDLength)=0Aid=200x42F2=0A=
minOccurs:=201=0AmaxOccurs:=201=0Arange:=20>=3D4=0A=
default:=204=0Atype:=20Unsigned=20Integer=0A=
description:=20The=20EBMLMaxIDLength=20Element=20stores=20the=20=
maximum=20permitted=20length=20in=20octets=20of=20the=20Element=20IDs=20=
to=20be=20found=20within=20the=20EBML=20Body.=20An=20EBMLMaxIDLength=20=
Element=20value=20of=20four=20is=20RECOMMENDED,=20though=20larger=20=
values=20are=20allowed.=0A=0A=0AEBMLMaxSizeLength=20=
Element=0Aname:=20EBMLMaxSizeLength=0Apath:=20=
1*1(\EBML\EBMLMaxSizeLength)=0Aid=200x42F3=0A=
minOccurs:=201=0AmaxOccurs:=201=0Arange:=20not=200=0A=
default:=208=0Atype:=20Unsigned=20Integer=0A=
description:=20The=20EBMLMaxSizeLength=20Element=20stores=20the=20=
maximum=20permitted=20length=20in=20octets=20of=20the=20expressions=20of=20=
all=20Element=20Data=20Sizes=20to=20be=20found=20within=20the=20EBML=20=
Body.=20The=20EBMLMaxSizeLength=20Element=20documents=20an=20upper=20=
bound=20for=20the=20length=20of=20all=20Element=20Data=20Size=20=
expressions=20within=20the=20EBML=20Body=20and=20not=20an=20upper=20=
bound=20for=20the=20value=20of=20all=20Element=20Data=20Size=20=
expressions=20within=20the=20EBML=20Body.=20EBML=20Elements=20that=20=
have=20an=20Element=20Data=20Size=20expression=20which=20is=20larger=20=
in=20octets=20than=20what=20is=20expressed=20by=20EBMLMaxSizeLength=20=
Element=20are=20invalid.=0A=0A=0ADocType=20Element=0Aname:=20=
DocType=0Apath:=201*1(\EBML\DocType)=0Aid=20=
0x4282=0AminOccurs:=201=0AmaxOccurs:=201=0Alength:=20=
>0=0Atype:=20String=0Adescription:=20A=20string=20that=20=
describes=20and=20identifies=20the=20content=20of=20the=20EBML=20Body=20=
that=20follows=20this=20EBML=20Header.=0A=0A=0ADocTypeVersion=20Element=0A=
name:=20DocTypeVersion=0Apath:=20=
1*1(\EBML\DocTypeVersion)=0Aid=200x4287=0A=
minOccurs:=201=0AmaxOccurs:=201=0Arange:=20not=200=0A=
default:=201=0Atype:=20Unsigned=20Integer=0A=
description:=20The=20version=20of=20DocType=20interpreter=20used=20to=20=
create=20the=20EBML=20Document.=0A=0A=0ADocTypeReadVersion=20=
Element=0Aname:=20DocTypeReadVersion=0Apath:=20=
1*1(\EBML\DocTypeReadVersion)=0Aid=200x4285=0A=
minOccurs:=201=0AmaxOccurs:=201=0Arange:=20not=200=0A=
default:=201=0Atype:=20Unsigned=20Integer=0A=
description:=20The=20minimum=20DocType=20version=20an=20EBML=20Reader=20=
has=20to=20support=20to=20read=20this=20EBML=20Document.=20The=20value=20=
of=20the=20DocTypeReadVersion=20Element=20MUST=20be=20less=20than=20or=20=
equal=20to=20the=20value=20of=20the=20DocTypeVersion=20Element.=0A=
=0A=0ADocTypeExtension=20=
Element=0Aname:=20DocTypeExtension=0Apath:=20=
0*(\EBML\DocTypeExtension)=0Aid=200x4281=0A=
minOccurs:=200=0Atype:=20Master=20Element=0A=
description:=20A=20DocTypeExtension=20adds=20extra=20Elements=20to=20=
the=20main=20DocType+DocTypeVersion=20tuple=20it's=20attached=20to.=20An=20=
EBML=20Reader=20MAY=20know=20these=20extra=20Elements=20and=20how=20to=20=
use=20them.=20A=20DocTypeExtension=20MAY=20be=20used=20to=20iterate=20=
between=20experimental=20Elements=20before=20they=20are=20integrated=20=
in=20a=20regular=20DocTypeVersion.=20Reading=20one=20DocTypeExtension=20=
version=20of=20a=20DocType+DocTypeVersion=20tuple=20doesn't=20imply=20=
one=20should=20be=20able=20to=20read=20upper=20versions=20of=20this=20=
DocTypeExtension.=0A=0A=0ADocTypeExtensionName=20=
Element=0Aname:=20DocTypeExtensionName=0Apath:=20=
1*1(\EBML\DocTypeExtension\Name)=0Aid=200x4283=0A=
minOccurs:=201=0AmaxOccurs:=201=0Alength:=20>0=0A=
type:=20String=0Adescription:=20The=20name=20of=20the=20=
DocTypeExtension=20to=20differentiate=20it=20from=20other=20=
DocTypeExtension=20of=20the=20same=20DocType+DocTypeVersion=20tuple.=20A=20=
DocTypeExtensionName=20value=20MUST=20be=20unique=20within=20the=20EBML=20=
Header.=0A=0A=0ADocTypeExtensionVersion=20=
Element=0Aname:=20DocTypeExtensionVersion=0Apath:=20=
1*1(\EBML\DocTypeExtension\Version)=0Aid=200x4284=0A=
minOccurs:=201=0AmaxOccurs:=201=0Arange:=20not=200=0A=
type:=20Unsigned=20Integer=0Adescription:=20The=20version=20of=20=
the=20DocTypeExtension.=20Different=20DocTypeExtensionVersion=20values=20=
of=20the=20same=20DocType+DocTypeVersion+DocTypeExtensionName=20tuple=20=
MAY=20contain=20completely=20different=20sets=20of=20extra=20Elements.=20=
An=20EBML=20Reader=20MAY=20support=20multiple=20versions=20of=20the=20=
same=20DocTypeExtension,=20only=20one=20or=20none.=0A=0A=
=0A=0AGlobal=20=
Elements=0AEBML=20allows=20some=20special=20Elements=20to=20be=20=
found=20within=20more=20than=20one=20parent=20in=20an=20EBML=20Document=20=
or=20optionally=20at=20the=20Root=20Level=20of=20an=20EBML=20Body.=20=
These=20Elements=20are=20called=20Global=20Elements.=20There=20are=202=20=
Global=20Elements=20that=20can=20be=20found=20in=20any=20EBML=20=
Document:=20the=20CRC-32=20Element=20and=20the=20Void=20Element.=20An=20=
EBML=20Schema=20MAY=20add=20other=20Global=20Elements=20to=20the=20=
format=20it=20defines.=20These=20extra=20elements=20apply=20only=20to=20=
the=20EBML=20Body,=20not=20the=20EBML=20Header.=0AGlobal=20=
Elements=20are=20EBML=20Elements=20whose=20path=20have=20a=20=
EBMLGlobalParent=20as=20their=20EBMLLastParent.=20Because=20it=20is=20=
the=20last=20Parent=20part=20of=20the=20path,=20a=20Global=20Element=20=
might=20also=20have=20non-EBMLGlobalParent=20parts=20in=20its=20path.=20=
In=20this=20case=20the=20Global=20Element=20can=20only=20be=20found=20=
within=20this=20non-EBMLGlobalParent=20path,=20i.e.=20it's=20not=20fully=20=
"global".=0AThe=20EBMLEltOccurrence=20of=20a=20Global=20=
Element=20is=20the=20number=20of=20occurrences=20the=20Element=20can=20=
be=20found=20in=20a=20Parent=20Element.=20But=20the=20Global=20Element=20=
can=20be=20found=20in=20many=20Parent=20Elements,=20allowing=20the=20=
same=20number=20of=20occurrences=20in=20each=20Parent=20where=20this=20=
Element=20is=20found.=0A=0ACRC-32=20Element=0Aname:=20=
CRC-32=0Apath:=20*1((1*\)\CRC-32)=0Aid:=20=
0xBF=0AminOccurs:=200=0AmaxOccurs:=201=0Alength:=20=
4=0Atype:=20Binary=0Adescription:=20The=20CRC-32=20Element=20=
contains=20a=2032-bit=20Cyclic=20Redundancy=20Check=20value=20of=20all=20=
the=20Element=20Data=20of=20the=20Parent=20Element=20as=20stored=20=
except=20for=20the=20CRC-32=20Element=20itself.=20When=20the=20CRC-32=20=
Element=20is=20present,=20the=20CRC-32=20Element=20MUST=20be=20the=20=
first=20ordered=20EBML=20Element=20within=20its=20Parent=20Element=20for=20=
easier=20reading.=20All=20Top-Level=20Elements=20of=20an=20EBML=20=
Document=20that=20are=20Master=20Elements=20SHOULD=20include=20a=20=
CRC-32=20Element=20as=20a=20Child=20Element.=20The=20CRC=20in=20use=20is=20=
the=20IEEE-CRC-32=20algorithm=20as=20used=20in=20the=20=20standard=20and=20in=20section=20=
8.1.1.6.2=20of=20,=20with=20=
initial=20value=20of=200xFFFFFFFF.=20The=20CRC=20value=20MUST=20be=20=
computed=20on=20a=20little=20endian=20bitstream=20and=20MUST=20use=20=
little=20endian=20storage.=0A=0A=0AVoid=20Element=0Aname:=20=
Void=0Apath:=20*((*\)\Void)=0Aid:=200xEC=0A=
minOccurs:=200=0Atype:=20Binary=0Adescription:=20Used=20=
to=20void=20data=20or=20to=20avoid=20unexpected=20behaviors=20when=20=
using=20damaged=20data.=20The=20content=20is=20discarded.=20Also=20used=20=
to=20reserve=20space=20in=20a=20sub-element=20for=20later=20use.=0A=
=0A=0A=0A=0AConsiderations=20=
for=20Reading=20EBML=20Data=0AThe=20following=20scenarios=20=
describe=20events=20to=20consider=20when=20reading=20EBML=20Documents=20=
and=20the=20recommended=20design=20of=20an=20EBML=20Reader.=0AIf=20=
a=20Master=20Element=20contains=20a=20CRC-32=20Element=20that=20doesn't=20=
validate,=20then=20the=20EBML=20Reader=20MAY=20ignore=20all=20contained=20=
data=20except=20for=20Descendant=20Elements=20that=20contain=20their=20=
own=20valid=20CRC-32=20Element.=0AIf=20a=20Master=20Element=20=
contains=20more=20occurrences=20of=20a=20Child=20Master=20Element=20than=20=
permitted=20according=20to=20the=20maxOccurs=20and=20recurring=20=
attributes=20of=20the=20definition=20of=20that=20Element=20then=20the=20=
occurrences=20in=20addition=20to=20maxOccurs=20MAY=20be=20ignored.=0A=
If=20a=20Master=20Element=20contains=20more=20occurrences=20of=20a=20=
Child=20Element=20than=20permitted=20according=20to=20the=20maxOccurs=20=
attribute=20of=20the=20definition=20of=20that=20Element=20then=20all=20=
instances=20of=20that=20Element=20after=20the=20first=20maxOccur=20=
occurrences=20from=20the=20beginning=20of=20its=20Parent=20Element=20=
SHOULD=20be=20ignored.=0A=0A=0ATerminating=20Elements=0A=
Null=20Octets,=20which=20are=20octets=20with=20all=20bits=20set=20to=20=
zero,=20MAY=20follow=20the=20value=20of=20a=20String=20Element=20or=20=
UTF-8=20Element=20to=20serve=20as=20a=20terminator.=20An=20EBML=20Writer=20=
MAY=20terminate=20a=20String=20Element=20or=20UTF-8=20Element=20with=20=
Null=20Octets=20in=20order=20to=20overwrite=20a=20stored=20value=20with=20=
a=20new=20value=20of=20lesser=20length=20while=20maintaining=20the=20=
same=20Element=20Data=20Size=20(this=20can=20prevent=20the=20need=20to=20=
rewrite=20large=20portions=20of=20an=20EBML=20Document);=20otherwise=20=
the=20use=20of=20Null=20Octets=20within=20a=20String=20Element=20or=20=
UTF-8=20Element=20is=20NOT=20RECOMMENDED.=20An=20EBML=20Reader=20MUST=20=
consider=20the=20value=20of=20the=20String=20Element=20or=20UTF-8=20=
Element=20to=20be=20terminated=20upon=20the=20first=20read=20Null=20=
Octet=20and=20MUST=20ignore=20any=20data=20following=20the=20first=20=
Null=20Octet=20within=20that=20Element.=20A=20string=20value=20and=20a=20=
copy=20of=20that=20string=20value=20terminated=20by=20one=20or=20more=20=
Null=20Octets=20are=20semantically=20equal.=0AThe=20following=20=
table=20shows=20examples=20of=20semantics=20and=20validation=20for=20the=20=
use=20of=20Null=20Octets.=20Values=20to=20represent=20Stored=20Values=20=
and=20the=20Semantic=20Meaning=20as=20represented=20as=20hexadecimal=20=
values.=0A=0A=0A=0AStored=20=
Value=0ASemantic=20Meaning=0A=0A=
=0A=0A=0A=0A0x65=200x62=200x6D=20=
0x6C=0A0x65=200x62=200x6D=200x6C=0A=0A=
=0A=0A0x65=200x62=200x00=200x6C=0A0x65=200x62=0A=0A=0A=0A0x65=200x62=200x00=200x00=0A0x65=20=
0x62=0A=0A=0A=0A0x65=200x62=0A=
0x65=200x62=0A=0A=0A=

=0A=0AGuidelines=20for=20=
Updating=20Elements=0AAn=20EBML=20Document=20can=20be=20=
updated=20without=20requiring=20that=20the=20entire=20EBML=20Document=20=
be=20rewritten.=20These=20recommendations=20describe=20strategies=20to=20=
change=20the=20Element=20Data=20of=20a=20written=20EBML=20Element=20with=20=
minimal=20disruption=20to=20the=20rest=20of=20the=20EBML=20Document.=0A=
=0AReducing=20=
a=20Element=20Data=20in=20Size=0AThere=20are=20three=20methods=20=
to=20reduce=20the=20size=20of=20Element=20Data=20of=20a=20written=20EBML=20=
Element.=0A=0AAdding=
=20a=20Void=20Element=0AWhen=20an=20EBML=20Element=20is=20=
changed=20to=20reduce=20its=20total=20length=20by=20more=20than=20one=20=
octet,=20an=20EBML=20Writer=20SHOULD=20fill=20the=20freed=20space=20with=20=
a=20Void=20Element.=0A=0A=0AExtending=20the=20=
Element=20Data=20Size=0AThe=20same=20value=20for=20Element=20=
Data=20Size=20MAY=20be=20written=20in=20variable=20lengths,=20so=20for=20=
minor=20reductions=20in=20octet=20length=20the=20Element=20Data=20Size=20=
MAY=20be=20written=20to=20a=20longer=20octet=20length=20to=20fill=20the=20=
freed=20space.=0AFor=20example,=20the=20first=20row=20of=20the=20=
following=20table=20depicts=20a=20String=20Element=20that=20stores=20an=20=
Element=20ID=20(3=20octets),=20Element=20Data=20Size=20(1=20octet),=20=
and=20Element=20Data=20(4=20octets).=20If=20the=20Element=20Data=20is=20=
changed=20to=20reduce=20the=20length=20by=20one=20octet=20and=20if=20the=20=
current=20length=20of=20the=20Element=20Data=20Size=20is=20less=20than=20=
its=20maximum=20permitted=20length,=20then=20the=20Element=20Data=20Size=20=
of=20that=20Element=20MAY=20be=20rewritten=20to=20increase=20its=20=
length=20by=20one=20octet.=20Thus=20before=20and=20after=20the=20change=20=
the=20EBML=20Element=20maintains=20the=20same=20length=20of=208=20octets=20=
and=20data=20around=20the=20Element=20does=20not=20need=20to=20be=20=
moved.=0A=0A=0A=0A=0A=0A=0A=0A=
=0A=0A=0A=0A=0A=0A=
=0A=0A=0A=0A=0A=
=0A=0A=0A=0A=
=0A=0A=0A
StatusElement=20=
IDElement=20Data=20SizeElement=20Data
Before=20edit0x3B40400x840x65626D6C
After=20edit0x3B40400x40030x6D6B76
This=20method=20is=20=
RECOMMENDED=20when=20the=20Element=20Data=20is=20reduced=20by=20a=20=
single=20octet;=20for=20reductions=20by=20two=20or=20more=20octets=20it=20=
is=20RECOMMENDED=20to=20fill=20the=20freed=20space=20with=20a=20Void=20=
Element.=0ANote=20that=20if=20the=20Element=20Data=20length=20=
needs=20to=20be=20rewritten=20as=20shortened=20by=20one=20octet=20and=20=
the=20Element=20Data=20Size=20could=20be=20rewritten=20as=20a=20shorter=20=
VINT=20then=20it=20is=20RECOMMENDED=20to=20rewrite=20the=20Element=20=
Data=20Size=20as=20one=20octet=20shorter,=20shorten=20the=20Element=20=
Data=20by=20one=20octet,=20and=20follow=20that=20Element=20with=20a=20=
Void=20Element.=20For=20example,=20the=20following=20table=20depicts=20a=20=
String=20Element=20that=20stores=20an=20Element=20ID=20(3=20octets),=20=
Element=20Data=20Size=20(2=20octets,=20but=20could=20be=20rewritten=20in=20=
one=20octet),=20and=20Element=20Data=20(3=20octets).=20If=20the=20=
Element=20Data=20is=20to=20be=20rewritten=20to=20a=20two=20octet=20=
length,=20then=20another=20octet=20can=20be=20taken=20from=20Element=20=
Data=20Size=20so=20that=20there=20is=20enough=20space=20to=20add=20a=20=
two=20octet=20Void=20Element.=0A=0A=0A=0A=
=0A=0A=0A=
=0A=0A=0A=0A=0A=
=0A=0A=0A=0A=0A=
=0A=0A=0A=0A=0A=0A=
=0A=0A=0A=0A=
=0A=0A
StatusElement=20IDElement=20Data=20SizeElement=20DataVoid=20Element
Before0x3B40400x40030x6D6B76
After0x3B40400x820x68690xEC80
=0A=0ATerminating=20Element=20=
Data=0AFor=20String=20Elements=20and=20UTF-8=20Elements=20the=20=
length=20of=20Element=20Data=20MAY=20be=20reduced=20by=20adding=20Null=20=
Octets=20to=20terminate=20the=20Element=20Data=20(see=20the=20section=20on=20Terminating=20=
Elements).=0AIn=20the=20following=20table,=20a=20four=20=
octets=20long=20Element=20Data=20is=20changed=20to=20a=20three=20octet=20=
long=20value=20followed=20by=20a=20Null=20Octet;=20the=20Element=20Data=20=
Size=20includes=20any=20Null=20Octets=20used=20to=20terminate=20Element=20=
Data=20so=20remains=20unchanged.=0A=0A=0A=0A=
=0A=0A=0A=
=0A=0A=0A=0A=0A=0A=
=0A=0A=0A=
=0A=0A=0A=0A=0A=
=0A=0A=0A=0A=
=0A
StatusElement=20IDElement=20Data=20SizeElement=20Data
Before=20edit0x3B40400x840x65626D6C
After=20edit0x3B40400x840x6D6B7600
Note=20that=20this=20method=20is=20NOT=20=
RECOMMENDED.=20For=20reductions=20of=20one=20octet,=20the=20method=20for=20=
Extending=20the=20Element=20Data=20Size=20SHOULD=20be=20used.=20For=20=
reduction=20by=20more=20than=20one=20octet,=20the=20method=20for=20=
Adding=20a=20Void=20Element=20SHOULD=20be=20used.=0A=0A=
=0A=0AConsiderations=20when=20Updating=20Elements=20with=20=
Cyclic=20Redundancy=20Check=20(CRC)=0AIf=20the=20Element=20to=20=
be=20changed=20is=20a=20Descendant=20Element=20of=20any=20Master=20=
Element=20that=20contains=20a=20CRC-32=20Element=20(see=20)=20then=20the=20CRC-32=20Element=20=
MUST=20be=20verified=20before=20permitting=20the=20change.=20=
Additionally=20the=20CRC-32=20Element=20value=20MUST=20be=20subsequently=20=
updated=20to=20reflect=20the=20changed=20data.=0A=0A=
=0A=0ABackward=20and=20=
Forward=20Compatibility=0AElements=20of=20an=20EBML=20format=20=
SHOULD=20be=20designed=20with=20backward=20and=20forward=20compatibility=20=
in=20mind.=0A=0ABackward=20Compatibility=0A=
Backward=20compatibility=20of=20new=20EBML=20Elements=20can=20be=20=
achieved=20by=20using=20default=20values=20for=20mandatory=20elements.=20=
The=20default=20value=20MUST=20represent=20the=20state=20that=20was=20=
assumed=20for=20previous=20versions=20of=20the=20EBML=20Schema,=20=
without=20this=20new=20EBML=20Element.=20If=20such=20a=20state=20doesn't=20=
make=20sense=20for=20previous=20versions,=20then=20the=20new=20EBML=20=
Element=20SHOULD=20NOT=20be=20mandatory.=0ANon=20mandatory=20EBML=20=
Elements=20can=20be=20added=20in=20a=20new=20EBMLDocTypeVersion.=20Since=20=
they=20are=20not=20mandatory=20they=20won't=20be=20found=20in=20older=20=
versions=20of=20the=20EBMLDocTypeVersion,=20just=20as=20they=20might=20=
not=20be=20found=20in=20newer=20versions.=20This=20causes=20no=20=
compatibility=20issue.=0A=0A=0AForward=20Compatibility=0A=
EBML=20Elements=20MAY=20be=20marked=20as=20deprecated=20in=20a=20new=20=
EBMLDocTypeVersion=20using=20the=20maxver=20attribute=20of=20the=20EBML=20=
Schema.=20If=20such=20an=20Element=20is=20found=20in=20an=20EBML=20=
Document=20with=20newer=20version=20of=20the=20EBMLDocTypeVersion=20it=20=
SHOULD=20be=20discarded.=0A=0A=0A=0ASecurity=20=
Considerations=0AEBML=20itself=20does=20not=20offer=20any=20=
kind=20of=20security=20and=20does=20not=20provide=20confidentiality.=20=
EBML=20does=20not=20provide=20any=20kind=20of=20authorization.=20EBML=20=
only=20offers=20marginally=20useful=20and=20effective=20data=20integrity=20=
options,=20such=20as=20CRC=20elements.=0AEven=20if=20the=20=
semantic=20layer=20offers=20any=20kind=20of=20encryption,=20EBML=20=
itself=20could=20leak=20information=20at=20both=20the=20semantic=20layer=20=
(as=20declared=20via=20the=20DocType=20Element)=20and=20within=20the=20=
EBML=20structure=20(the=20presence=20of=20EBML=20Elements=20can=20be=20=
derived=20even=20with=20an=20unknown=20semantic=20layer=20using=20a=20=
heuristic=20approach;=20not=20without=20errors,=20of=20course,=20but=20=
with=20a=20certain=20degree=20of=20confidence).=0AAn=20EBML=20=
Document=20that=20has=20the=20following=20issues=20may=20still=20be=20=
handled=20by=20the=20EBML=20Reader=20and=20the=20data=20accepted=20as=20=
such,=20depending=20on=20how=20strict=20the=20EBML=20Reader=20wants=20to=20=
be:=0A=0A
    =0A
  • Invalid=20Element=20IDs=20that=20are=20longer=20=
than=20the=20limit=20stated=20in=20the=20EBMLMaxIDLength=20Element=20of=20=
the=20EBML=20Header.=0A
    • =0A
  • Invalid=20Element=20IDs=20that=20=
are=20not=20encoded=20in=20the=20shortest-possible=20way.=0A
    • =0A=

  • Invalid=20Element=20Data=20Size=20values=20that=20are=20longer=20=
than=20the=20limit=20stated=20in=20the=20EBMLMaxSizeLength=20Element=20=
of=20the=20EBML=20Header.=0A
    • =0A
=0AElement=20IDs=20that=20=
are=20unknown=20to=20the=20EBML=20Reader=20MAY=20be=20accepted=20as=20=
valid=20EBML=20IDs=20in=20order=20to=20skip=20such=20elements.=0A=
EBML=20Elements=20with=20a=20string=20type=20may=20contain=20extra=20=
data=20after=20the=20first=200x00.=20These=20data=20MUST=20be=20=
discarded=20according=20to=20the=20=20rules.=0AAn=20EBML=20=
Reader=20may=20discard=20some=20or=20all=20data=20if=20the=20following=20=
errors=20are=20found=20in=20the=20EBML=20Document:=0A=0A
    =0A=

  • Invalid=20Element=20Data=20Size=20values=20(e.g.=20extending=20=
the=20length=20of=20the=20EBML=20Element=20beyond=20the=20scope=20of=20=
the=20Parent=20Element;=20possibly=20triggering=20access-out-of-bounds=20=
issues).=0A
    • =0A
  • Very=20high=20lengths=20in=20order=20to=20=
force=20out-of-memory=20situations=20resulting=20in=20a=20denial=20of=20=
service,=20access-out-of-bounds=20issues=20etc.=0A
    • =0A=

  • Missing=20EBML=20Elements=20that=20are=20mandatory=20in=20a=20=
Master=20Element=20and=20have=20no=20declared=20default=20value,=20=
making=20the=20semantic=20invalid=20at=20that=20Master=20Element=20=
level.=0A
    • =0A
  • Usage=20of=20invalid=20UTF-8=20encoding=20in=20=
EBML=20Elements=20of=20UTF-8=20type=20(e.g.=20in=20order=20to=20trigger=20=
access-out-of-bounds=20or=20buffer=20overflow=20issues).=0A
    • =0A=

  • Usage=20of=20invalid=20data=20in=20EBML=20Elements=20with=20a=20=
date=20type,=20triggering=20bogus=20date=20accesses.=0A
    • =0A
=0A=
Side=20channel=20attacks=20could=20exploit:=0A=0A
    =0A=

  • The=20semantic=20equivalence=20of=20the=20same=20string=20stored=20=
in=20a=20String=20Element=20or=20UTF-8=20Element=20with=20and=20without=20=
zero-bit=20padding,=20making=20comparison=20at=20the=20semantic=20level=20=
invalid.=0A
    • =0A
  • The=20semantic=20equivalence=20of=20=
VINT_DATA=20within=20Element=20Data=20Size=20with=20two=20different=20=
lengths=20due=20to=20left-padding=20zero=20bits,=20making=20comparison=20=
at=20the=20semantic=20level=20invalid.=0A
    • =0A
  • Data=20=
contained=20within=20a=20Master=20Element=20which=20is=20not=20itself=20=
part=20of=20a=20Child=20Element=20can=20trigger=20incorrect=20parsing=20=
behavior=20in=20EBML=20Readers.=0A
    • =0A
  • Extraneous=20copies=20=
of=20Identically=20Recurring=20Element,=20making=20parsing=20=
unnecessarily=20slow=20to=20the=20point=20of=20not=20being=20usable.=0A=

    • =0A
  • Copies=20of=20Identically=20Recurring=20Element=20within=20=
a=20Parent=20Element=20that=20contain=20invalid=20CRC-32=20Elements.=20=
EBML=20Readers=20not=20checking=20the=20CRC-32=20might=20use=20the=20=
version=20of=20the=20element=20with=20mismatching=20CRC-32.=0A
    • =0A=

  • Use=20of=20Void=20Elements=20which=20could=20be=20used=20to=20=
hide=20content=20or=20create=20bogus=20resynchronization=20points=20seen=20=
by=20some=20EBML=20Reader=20and=20not=20others.=0A
    • =0A
=0A=
=0A=0AIANA=20=
Considerations=0A=0ACELLAR=20EBML=20Element=20=
ID=20Registry=0AThis=20document=20creates=20a=20new=20IANA=20=
Registry=20called=20"CELLAR=20EBML=20Element=20ID=20=
Registry".=0AElement=20IDs=20are=20described=20in=20section=20=
Element=20ID.=20Element=20IDs=20are=20encoded=20using=20the=20VINT=20=
mechanism=20described=20in=20section=20=20can=20be=20between=20one=20=
and=20five=20octets=20long.=20Five=20octet=20long=20Element=20IDs=20are=20=
possible=20only=20if=20declared=20in=20the=20header.=0AThis=20=
IANA=20Registry=20only=20applies=20to=20Elements=20that=20can=20be=20=
contained=20in=20the=20EBML=20Header,=20thus=20including=20Global=20Elements.=20Elements=20only=20=
found=20in=20the=20EBML=20Body=20have=20their=20own=20set=20of=20=
independent=20Element=20IDs=20and=20are=20not=20part=20of=20this=20IANA=20=
Registry.=0AThe=20VINT=20Data=20value=20of=20one-octet=20Element=20=
IDs=20MUST=20be=20between=200x01=20and=200x7E.=20These=20items=20are=20=
valuable=20because=20they=20are=20short,=20and=20need=20to=20be=20used=20=
for=20commonly=20repeated=20elements.=20Values=20from=201=20to=20126=20=
are=20to=20be=20allocated=20according=20to=20the=20"RFC=20=
Required"=20policy=20.=0A=
The=20VINT=20Data=20value=20of=20two-octet=20Element=20IDs=20MUST=20=
be=20between=200x007F=20and=200x3FFE.=20Numbers=20are=20to=20be=20=
allocated=20within=20this=20range=20according=20to=20the=20=
"Specification=20Required"=20policy=20.=0AThe=20numbers=200x3FFF=20and=20=
0x4000=20are=20RESERVED.=0AThe=20VINT=20Data=20value=20of=20=
three-octet=20Element=20IDs=20MUST=20be=20between=200x4001=20and=20=
0x1FFFFE.=20Numbers=20may=20be=20allocated=20within=20this=20range=20=
according=20to=20the=20"First=20Come=20First=20Served"=20=
policy=20.=0AThe=20numbers=20=
0x1FFFFF=20and=200x200000=20are=20RESERVED.=0AFour-octet=20=
Element=20IDs=20are=20numbers=20between=200x101FFFFF=20and=200x1FFFFFFE.=20=
Four-octet=20Element=20IDs=20are=20somewhat=20special=20in=20that=20they=20=
are=20useful=20for=20resynchronizing=20to=20major=20structures=20in=20=
the=20event=20of=20data=20corruption=20or=20loss.=20As=20such=20=
four-octet=20Element=20IDs=20are=20split=20into=20two=20categories.=20=
Four-octet=20Element=20IDs=20whose=20lower=20three=20octets=20(as=20=
encoded)=20would=20make=20printable=207-bit=20ASCII=20values=20(0x20=20=
to=200x7E,=20inclusive)=20MUST=20be=20allocated=20by=20the=20=
"Specification=20Required"=20policy.=20Sequential=20allocation=20=
of=20values=20is=20not=20required:=20specifications=20SHOULD=20include=20=
a=20specific=20request,=20and=20are=20encouraged=20to=20do=20early=20=
allocations.=0ATo=20be=20clear=20about=20the=20above=20category:=20=
four-octet=20Element=20IDs=20always=20start=20with=20hex=200x10=20to=20=
0x1F,=20and=20that=20octet=20may=20be=20chosen=20so=20that=20the=20=
entire=20number=20has=20some=20desirable=20property,=20such=20as=20a=20=
specific=20CRC.=20The=20other=20three=20octets,=20when=20ALL=20having=20=
values=20between=200x21=20(33,=20ASCII=20!)=20and=200x7E=20(126,=20ASCII=20=
~),=20fall=20into=20this=20category.=0AOther=20four-octet=20=
Element=20IDs=20may=20be=20allocated=20by=20the=20"First=20Come=20=
First=20Served"=20policy.=0AThe=20numbers=200xFFFFFFF=20and=20=
0x1000000=20are=20RESERVED.=0AFive=20octet=20Element=20IDs=20=
(values=20from=200x10000001=20upwards)=20are=20RESERVED=20according=20to=20=
the=20"Experimental=20Use"=20policy=20:=20they=20may=20be=20used=20by=20anyone=20at=20=
any=20time,=20but=20there=20is=20no=20coordination.=0AID=20Values=20=
found=20in=20this=20document=20are=20assigned=20as=20initial=20values=20=
as=20follows:=0A=0A=0A=0AID=0AElement=20Name=0AReference=0A=0A=0A=0A=0A=0A=
0x1A45DFA3=0AEBML=0A=
Described=20in=20=0A=0A=0A=0A0x4286=0AEBMLVersion=0A=
Described=20in=20=0A=0A=0A=0A0x42F7=0AEBMLReadVersion=0A=
Described=20in=20=0A=0A=0A=0A0x42F2=0AEBMLMaxIDLength=0A=
Described=20in=20=0A=0A=0A=0A0x42F3=0AEBMLMaxSizeLength=0A=
Described=20in=20=0A=0A=0A=0A=
0x4282=0ADocType=0A=
Described=20in=20=0A=0A=0A=0A0x4287=0ADocTypeVersion=0A=
Described=20in=20=0A=0A=0A=0A0x4285=0ADocTypeReadVersion=
=0ADescribed=20in=20=0A=0A=0A=0A=
0x4281=0ADocTypeExtension=0ADescribed=20=
in=20=0A=0A=0A=
=0A0x4283=0ADocTypeExtensionName=0ADescribed=20=
in=20=0A=
=0A=0A=0A0x4284=0ADocTypeExtensionVersion=0ADescribed=20in=20=0A=0A=0A=
=0A0xBF=0ACRC-32=0A=
Described=20in=20=0A=0A=0A=0A0xEC=0AVoid=0ADescribed=20in=20=0A=0A=0A=

=0A=0ACELLAR=20EBML=20DocType=20=
Registry=0AThis=20document=20creates=20a=20new=20IANA=20=
Registry=20called=20"CELLAR=20EBML=20DocType=20Registry".=0A=
To=20register=20a=20new=20DocType=20in=20this=20registry=20one=20=
needs=20a=20DocType=20name,=20a=20Description=20of=20the=20DocType,=20a=20=
Change=20Controller=20(IESG=20or=20email=20of=20registrant)=20and=20an=20=
optional=20Reference=20to=20a=20document=20describing=20the=20=
DocType.=0ADocType=20values=20are=20described=20in=20this=20section.=20DocTypes=20are=20ASCII=20=
strings,=20defined=20in=20the=20=
String=20Element=20section,=20which=20label=20the=20official=20=
name=20of=20the=20EBML=20Document=20Type.=20The=20strings=20may=20be=20=
allocated=20according=20to=20the=20"First=20Come=20First=20=
Served"=20policy.=0AThe=20use=20of=20ASCII=20corresponds=20=
to=20the=20types=20and=20code=20already=20in=20use,=20the=20value=20is=20=
not=20meant=20to=20be=20visible=20to=20the=20user.=0ADocType=20=
string=20values=20of=20"matroska"=20and=20"webm"=20=
are=20RESERVED=20to=20the=20IETF=20for=20future=20use.=0AThese=20can=20=
be=20assigned=20via=20the=20"IESG=20Approval"=20or=20"RFC=20=
Required"=20policies=20.=0A=
=0A=0A=0A=0A=0A=0A=
Normative=20References=0A=0A=20=20=0A=20=20=20=20=
Data=20communication=20-=20High-level=20data=20link=20control=20=
procedures=20-=20Frame=20structure=0A=20=20=20=20=0A=20=20=
=20=20=20=20International=20Organization=20for=20=
Standardization=0A=20=20=20=20=0A=20=20=20=20=
=0A=20=20=0A=0A=
=0A=20=20=0A=20=
=20=20=20Programming=20languages=20-=20C=0A=20=20=20=20=
=0A=20=20=20=20=20=20International=20Organization=20=
for=20Standardization=0A=20=20=20=20=0A=20=20=20=20=
=0A=20=20=0A=0A=
=0A=0A=0A=0A=0A=0A=0A=
=20=20=0A=20=20=20=20XHTML(tm)=20Basic=201.1=20-=20Second=20=
Edition=0A=20=20=20=20=0A=20=20=20=20=20=20=
=0A=20=20=20=20=0A=20=20=20=20=
=0A=20=20=
=0A=20=20=0A=
=0A=0A=20=20=
=0A=20=20=20=20Error-correcting=20Procedures=20for=20DCEs=20=
Using=20Asynchronous-to-Synchronous=20Conversion=0A=20=20=20=20=
=0A=20=20=20=20=20=20International=20=
Telecommunications=20Union=0A=20=20=20=20=0A=20=20=
=20=20=0A=20=20=0A=0A=
=0A=20=20=0A=20=
=20=20=20Standard=20for=20Binary=20Floating-Point=20=
Arithmetic=0A=20=20=20=20=0A=20=20=20=20=20=20=
Institute=20of=20Electrical=20and=20Electronics=20=
Engineers=0A=20=20=20=20=0A=20=20=20=20=0A=20=20=0A=0A=
=0A=0A=0A=0A=0AInformative=20References=0A=
=0A=0A=0A=0A=0A=0A=

--Apple-Mail=_6992EB9F-D436-4DDC-BEC4-E7F50FEADAC1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii



On =
lines 559-609 and 824-939 there are <sourcecode> nodes that =
contain multi-line xml expressions. During the upload the idnit test =
showed no issues or nits at all.  However in the resulting files =
at https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/12/=
 the outputs remove the line-breaks of the multi-line xml within =
the <sourcecode> nodes. So in the HTML version the =
<sourcecode> is shown as a single line, see https://www.ietf.org/id/draft-ietf-cellar-ebml-12.html#name-ebm=
l-schema-example, and in the plain text as well, see Section 11.1.1 =
of https://www.ietf.org/id/draft-ietf-cellar-ebml-12.txt.

In another =
document, I have been find/replacing the <sourcecode> node with =
the older <artwork> node as a workaround.

Best Regards,

Dave Rice
=

--Apple-Mail=_6992EB9F-D436-4DDC-BEC4-E7F50FEADAC1--

--Apple-Mail=_B20C7190-BE01-4B9F-9E1E-3DFEF488C1CF--


From nobody Mon Oct 21 09:47:24 2019
Return-Path: 
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762C0120108 for ; Mon, 21 Oct 2019 09:47:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 tJuMZDowXy7X for ; Mon, 21 Oct 2019 09:47:19 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 CE286120071 for ; Mon, 21 Oct 2019 09:47:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1571676377; bh=mqiXb1atcq7QmbituJJk7tWQhf1sSdSHK/A6R6F4PTM=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=jHiQRR/2nBT2ur3RNBsCHyJLtWF4qmfvzZciNf7sLQV3iNILNZ8DxwPCE69PmDWYM fUwkhf1zlzH7x7L36cYFVv5s9tKMcr1Dkwh78v4QGzsxE7qHatTB25ny5qnjlzUnYl RcwomsifK44cO53wM4oV7nU5Hwy+TuQO/RJ1rzmU=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.124] ([217.251.143.142]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MKbkM-1iapsr0xI4-00KwI6; Mon, 21 Oct 2019 18:46:17 +0200
To: Dave Rice , Henrik Levkowetz 
Cc: rfc-interest , tools-discuss@ietf.org
References: <20285.1568652805@localhost> <705AA16B-68B1-4B5E-AE47-0714F6781C1A@dericed.com> <26105.1568818137@localhost>  <1268.1568828850@localhost>  <15814.1569013442@localhost> <3a8f5865-9f5c-8c65-63be-bca31c5f1c86@levkowetz.com> <3650B5EF-A442-4291-928A-2FCB2144134C@dericed.com> <06122b6d-d5f9-30b9-2db4-a2427d299a1f@levkowetz.com> 
From: Julian Reschke 
Message-ID: <97e68838-ac0c-25e4-67a9-a2a998b6e8af@gmx.de>
Date: Mon, 21 Oct 2019 18:46:12 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:EDXn6lIAOmmZJGjmYsDlPZ0ZF5ZKg75UcsSFW5yyA26Suc/XmC5 q39Kv4uc5gdiw/fSi+iViT19Nl903bu82RYWP0XvsGPBuFV9xnZTLWIjcaC6V9MThyJeMwM xVfzwAm8eTPE7YLLuV8dukV1xcqeS9zWzd2UcEcmEUDk9Q48X8pxCJClLeWRjdp3m4TeY7o YePCAL+iRik/aBUoF2NOQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:xely+8TkLuU=:/3198vzXce1SVMwC6aqjpk GijO7rP0vnAcqPH8QFBczkoWZcfD5E+QgceNWfTd+vtykQl6PHp0ZwIN0mxQcjnqCj+XZuMBz KllvfilkjI1l8JAKjrks7NWMalCQadMAg8Tx9qqQTtuJF9wlYWU2VT2FrQsLK7OCtSS7tzaJE BFy6uYWqLFcImTqnx/ExN1F09R09yksBVPh9LYegJMKcUWE+3LfMN1LANSzJdZ8W6nXqM2JfP XUghXCom+xrla0ZnKv3tDj8B1e7pbjZQZxQOnXO0wLwECauZKHe6P9h9nEG3YbOc2zvt67we8 +mva8MpNqtdplwds+qgE/ICOQ94rAcAsn8xqW8xkfG2xFswyYhLdIbim8N1MAKcWsiByPq39N E80uEhiKOXLrzmjrWX4VN5sAP9nW0yQjap52AtgWQuqRuxmHcXstxE0MeoFjd1ZydWd5qimDq LqmEhw+rMMkaL56vTP3NMEqJwULQ3gwVxmBxknRS+Hj/jvkgzKgwzMT6O/Bexup1Nde1qwRXT lJExOfbU8iZkYI8MFwp4vpfKwqwMKikamtr3FuiLE47MXLq4VTZHn4HJ1KxZ5VWG44UTeawBs 7YlyI09RkQoM9IDkmZgoHsyGiTqN3Y5iIo4sv/R6t4ZvaMDJlbLjsfuLkGtcPnEon8vWZFYzg Um9myxnHL34bWDM840Si+ACyLwJG2UAbqCuGj7fEv2nnpxH+7Z9yEETP8J5bx5SUAY/EtmWAV 3+CSQ1v1eoIJUHl2pCYoQgS4dASxEpksgqll/nzRu8aqnomFYKcOQj5F2dA+U0wwOTF0/rHYE epdKJvMEwBLSLzy6FWTkaw6bpW2vymN8aaI9UCwWda3EbzLllHRIkSsNPSrQYKbicIHYjFzD4 g12X/iPAu4TjjXSFOjQrdwpPuP2MFv40oRBUwrFr1/D3GaGUkUm1rTSyhdpzS4pbgqC7bznd+ 5U9lzkn9fTth2u5uylUWqFCtNsTKf372tNQElZgS+YmGTvDnEpmolY0xm4DN00W9yZeq/u1YJ pfZam+tsqT+dKNUFJDG0AfcE+4sauDrzuyKUhpu/bLlTgKtWKrVwa+lWF2CJXQosjbx3qSinX L0BbuTOM2j1/S6QjZ91PmeGVDlh73/5Oir5qOpM0mW7iNls5z7hB8jSy0EuBIEgeBGBSfvElt BYek8xCKVYBXM6Z+3Q5V+m6cBBVd94xACOMr6wgd+THXR4f7R9v4TctheJ3q/nBl2UWAN5Hvr 3u/OBH2E4wv0YOhBfvnc9tBg9LAE/AY7iI3umqGMPN/fYesJwwH6nRPQbPY4=
Archived-At: 
Subject: Re: [Tools-discuss] [rfc-i] Update: The transition to xml2rfc v3 (today!) (fwd) Heather Flanagan: Update: The transition to xml2rfc v3 (today!)
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2019 16:47:22 -0000

On 21.10.2019 18:14, Dave Rice wrote:
> Hi all,
>
>> On Oct 9, 2019, at 1:38 PM, Henrik Levkowetz > > wrote:
>>
>> Hi David,
>>
>> On 2019-10-09 17:32, Dave Rice wrote:
>>> Thanks Henrik,
>>>
>>>> On Sep 20, 2019, at 5:26 PM, Henrik Levkowetz >>> > wrote:
>>>>
>>>> Hi Michael, David,
>>>>
>>>> On 2019-09-20 23:04, Michael Richardson wrote:
>>>>>
>>>>> Dave Rice > wrote:
>>>>>> Another annoyance here is the the xml processor in the submission t=
ool
>>>>>> and the xml processor at
>>>>>> https://xml2rfc.tools.ietf.org/experimental.html
>>>>>>  perform
>>>>>> differently,
>>>>>> so there=E2=80=99s effectively no test environment to use before su=
bmitting.
>>>>>> Dave
>>>>>
>>>>> Dave, can you please try xml2rfc.ietf.org
>>>>> , which is a different installation,
>>>>> supported by a different entity?
>>>>
>>>> Michael: =C2=A0Umm, no, that redirects to tools.ietf.org
>>>> , too, and the processor
>>>> behind that, and behind
>>>> https://xml2rfc.tools.ietf.org/experimental.html,
>>>> _and_ behind the submission tool are all the latest release of xml2rf=
c.
>>>>
>>>> David: I'd be happy to look into any discrepancies you see, but I
>>>> can only
>>>> do so if you provide observations and input XML files for me to work
>>>> with. =C2=A0It won't happen if I don't know about it :-)
>>>
>>
>>> When I use the tool at https://xml2rfc.tools.ietf.org or
>>> https://xml2rfc.tools.ietf.org/experimental.html, the plain text
>>> output appears ok, but when I use
>>> https://datatracker.ietf.org/submit/
>>> , the contents of the
>>>  elements (which are new in xml2rfc version 3) have their
>>> line breaks stripped out and thus cause an error when the line length
>>> limits are exceeded.
>>
>> That sounds like a bug.
>>
>>> For the moment, I=E2=80=99m proposing a find and replace to convert th=
e newer
>>>  elements back to  elements as in
>>> https://github.com/FFmpeg/FFV1/pull/171/commits/a018f091534678f45cc157=
bfd154518ad6267c7e
>>> ,
>>> thus an xml2rfc version 2 processor or version 3 processor should
>>> proceed accurate results though not as semantically clear in the
>>> xml.
>>>
>>>> FWIW, if you have atools.ietf.org login, you
>>>> can use the xml2rfc
>>>> issue
>>>> tracker athttps://trac.tools.ietf.org/tools/xml2rfc/trac/newticket, f=
or
>>>> xml2rfc issues, andhttps://trac.tools.ietf.org/tools/ietfdb/newticket
>>>> for datatracker issues.
>>>
>>> I don=E2=80=99t have a login, but I=E2=80=99ll see if I can make a tin=
y test file for
>>> this issue and file a concise ticket.
>>
>> Please don't put time into this; I'm perfectly happy to work from the x=
ml
>> file you found problematic on submission. =C2=A0Just let me know the na=
me
>> of the
>> draft in question, so I can pull it.
>
> I just uploaded this new version of the EBML specification to the
> datatracker.
>
>
> On lines 559-609 and 824-939 there are  nodes that contain
> multi-line xml expressions. During the upload the idnit test showed no
> issues or nits at all. =C2=A0However in the resulting files at
> https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/12/=C2=A0the out=
puts
> remove the line-breaks of the multi-line xml within the 
> nodes. So in the HTML version the  is shown as a single
> line, see
> https://www.ietf.org/id/draft-ietf-cellar-ebml-12.html#name-ebml-schema-=
example,
> and in the plain text as well, see Section 11.1.1 of
> https://www.ietf.org/id/draft-ietf-cellar-ebml-12.txt.
>
> In another document, I have been find/replacing the  node
> with the older  node as a workaround.
>
> Best Regards,
>
> Dave Rice
> ...

I had the same problem and reported it as
.

Best regards, Julian


From nobody Mon Oct 21 10:50:28 2019
Return-Path: 
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F5A120105; Mon, 21 Oct 2019 10:50:21 -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_HELO_NONE=0.001, 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 57Yqo3KgnEHY; Mon, 21 Oct 2019 10:50:19 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10C781200F7; Mon, 21 Oct 2019 10:50:18 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 719293897C; Mon, 21 Oct 2019 13:47:46 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B6DDD612; Mon, 21 Oct 2019 13:50:17 -0400 (EDT)
From: Michael Richardson 
To: cellar@ietf.org, tools-discuss@ietf.org
cc: Dave Rice 
In-Reply-To: <157167166904.31800.14436237517062444902@ietfa.amsl.com>
References: <157167166904.31800.14436237517062444902@ietfa.amsl.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
Archived-At: 
Subject: Re: [Tools-discuss] [Cellar] I-D Action: draft-ietf-cellar-ebml-12.txt
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2019 17:50:22 -0000

--=-=-=
Content-Type: text/plain


Dave, is ebml in XML v3, uploaded as such?
Were the txt and HTML generated by you or the datatracker?

> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-ebml-12

looking at the diff of the txt, there are a bunch of relative references which did not
get expanded correctly from the markdown:

    unknownsizeallowed attribute (#unknownsizeallowed)).

Looks like a tooling issue somewhere.
Looking at this:
  https://www.ietf.org/id/draft-ietf-cellar-ebml-12.html

I don't see #unknownsizeallowed in the same way, but the reference that is
generated looks off to me.

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



--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl2t79kACgkQgItw+93Q
3WWPywf9FWgfjEIyiA81BrqQFMHSREqYwtCXdSWSMqhJcXCbjSjqAJ99/4C9uXZ9
bLx0yYycDfwt/7Ann9gAnFGKQf3nnY0Xp+WhJtj/cbxcCud61rMY+a5KIRHNuuRN
U+zlb0f/CPEofzVzboV13Ab2MRRxFYz29LZ+rGOpGRYzhlEl14gOa7HZ2Vv7gZCj
kmrtHyoH9H14A6t+lMNChiKXCdgtgEOEA/C9pHQ8mUoaSWH3ODnmz3HVUIa5QxMQ
MfiqSunFks/xZVw9pAh/LaMomffXkMFfeFnOENtEyvuoEatzzTIMBYo1nEmRqrxY
+ykRiyQ9df3ard4yz2BMAuRWtRALAw==
=YBdH
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Mon Oct 21 11:24:22 2019
Return-Path: 
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C48B1201DB; Mon, 21 Oct 2019 11:22:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.109
X-Spam-Level: 
X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, T_HTML_ATTACH=0.01] autolearn=no 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 x08mwcrOQZ3V; Mon, 21 Oct 2019 11:22:18 -0700 (PDT)
Received: from server172-3.web-hosting.com (server172-3.web-hosting.com [68.65.122.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88722120108; Mon, 21 Oct 2019 11:22:18 -0700 (PDT)
Received: from [146.96.19.240] (port=50482 helo=[10.10.201.23]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1iMcJs-004JSE-AA; Mon, 21 Oct 2019 14:22:17 -0400
From: Dave Rice 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_826F171C-452B-41F2-8E91-66701F5AD401"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Date: Mon, 21 Oct 2019 14:22:10 -0400
In-Reply-To: <2259.1571680217@localhost>
Cc: cellar@ietf.org, tools-discuss@ietf.org
To: Michael Richardson 
References: <157167166904.31800.14436237517062444902@ietfa.amsl.com> <2259.1571680217@localhost>
X-Mailer: Apple Mail (2.3445.104.8)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server172.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - dericed.com
X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com
X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-From-Rewrite: unmodified, already matched
Archived-At: 
X-Mailman-Approved-At: Mon, 21 Oct 2019 11:24:19 -0700
Subject: Re: [Tools-discuss] [Cellar] I-D Action: draft-ietf-cellar-ebml-12.txt
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2019 18:22:34 -0000

--Apple-Mail=_826F171C-452B-41F2-8E91-66701F5AD401
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Michael,

> On Oct 21, 2019, at 1:50 PM, Michael Richardson  =
wrote:
>=20
>=20
> Dave, is ebml in XML v3, uploaded as such?

It was uploaded via https://datatracker.ietf.org/submit/ =
.

> Were the txt and HTML generated by you or the datatracker?

With xml2rfc 2.32.0 locally the files look ok, I=E2=80=99m attaching =
them.

I haven=E2=80=99t tested but in the XML within the  we have =
0x0A for line breaks. I wonder if an 0x0d (carriage return) would make a =
difference, though I feel guilty using up version numbers just to test =
that.

>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cellar-ebml-12
>=20
> looking at the diff of the txt, there are a bunch of relative =
references which did not
> get expanded correctly from the markdown:
>=20
>    unknownsizeallowed attribute (#unknownsizeallowed)).

I=E2=80=99ll address that separately.

> Looks like a tooling issue somewhere.
> Looking at this:
>  https://www.ietf.org/id/draft-ietf-cellar-ebml-12.html
>=20
> I don't see #unknownsizeallowed in the same way, but the reference =
that is
> generated looks off to me.
>=20
> --
> ]               Never tell me the odds!                 | ipv6 mesh =
networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT =
architect   [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on =
rails    [
>=20
>=20

--Apple-Mail=_826F171C-452B-41F2-8E91-66701F5AD401
Content-Type: multipart/mixed;
 boundary="Apple-Mail=_3CEF22D2-68BC-49E3-ABE9-E337F8FEA435"


--Apple-Mail=_3CEF22D2-68BC-49E3-ABE9-E337F8FEA435
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi =
Michael,

On Oct 21, 2019, at 1:50 PM, Michael =
Richardson <mcr@sandelman.ca> wrote:


Dave, is ebml in XML v3, uploaded as such?

It =
was uploaded via https://datatracker.ietf.org/submit/.

Were the txt and HTML generated by you or the datatracker?

With xml2rfc 2.32.0 locally the files look =
ok, I=E2=80=99m attaching them.

I =
haven=E2=80=99t tested but in the XML within the <sourcecode> we =
have 0x0A for line breaks. I wonder if an 0x0d (carriage return) would =
make a difference, though I feel guilty using up version numbers just to =
test that.

A diff =
from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cellar-ebml-12

looking at the diff of the =
txt, there are a bunch of relative references which did not
get expanded correctly from the markdown:

    unknownsizeallowed attribute =
(#unknownsizeallowed)).


Looks like a tooling issue somewhere.
Looking =
at this:
  https://www.ietf.org/id/draft-ietf-cellar-ebml-12.html

I don't see #unknownsizeallowed in the same =
way, but the reference that is
generated looks off to =
me.

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


=

--Apple-Mail=_3CEF22D2-68BC-49E3-ABE9-E337F8FEA435
Content-Disposition: attachment;
	filename=draft-ietf-cellar-ebml-12.html
Content-Type: text/html; x-unix-mode=0644;
 name="draft-ietf-cellar-ebml-12.html"
Content-Transfer-Encoding: quoted-printable







Extensible Binary Meta Language

















Internet-Draft
EBML
October 2019




Lhomme, et al.
Expires 23 April 2020
[Page]











Workgroup:


cellar


Internet-Draft:


draft-ietf-cellar-ebml-12


Published:




    


Intended Status:


Standards Track


Expires:




Authors:





      
S. Lhomme





      
D. Rice





      
M. Bunkus










Extensible Binary Meta Language



      
Abstract


This document defines the Extensible Binary =
Meta Language (EBML) format as a generalized file format for any type of =
data in a hierarchical form. EBML is designed as a binary equivalent to =
XML and uses a storage-efficient approach to build nested Elements with =
identifiers, lengths, and values. Similar to how an XML Schema defines =
the structure and semantics of an XML Document, this document defines =
how EBML Schemas are created to convey the semantics of an EBML =
Document.=C2=B6







        

Status of This Memo
        



        This Internet-Draft is submitted in full conformance with the
        provisions of BCP 78 and BCP 79.=C2=B6



        Internet-Drafts are working documents of the Internet =
Engineering Task
        Force (IETF). Note that other groups may also distribute working
        documents as Internet-Drafts. The list of current =
Internet-Drafts is
        at https://datatracker.=
ietf.org/drafts/current/.=C2=B6



        Internet-Drafts are draft documents valid for a maximum of six =
months
        and may be updated, replaced, or obsoleted by other documents at =
any
        time. It is inappropriate to use Internet-Drafts as reference
        material or to cite them other than as "work in progress."=C2=B6



        This Internet-Draft will expire on 23 April 2020.=C2=B6









        


            Copyright (c) 2019 IETF Trust and the persons identified as =
the
            document authors. All rights reserved.=C2=B6



            This document is subject to BCP 78 and the IETF Trust's =
Legal
            Provisions Relating to IETF Documents
            (https://trustee.ietf.org/li=
cense-info) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions =
with
            respect to this document. Code Components extracted from =
this
            document must include Simplified BSD License text as =
described in
            Section 4.e of the Trust Legal Provisions and are provided =
without
            warranty as described in the Simplified BSD License.=C2=B6









        =E2=96=B2<=
/a>

Table =
of Contents
        










      

1.=C2=A0Introduction
      


EBML, short for Extensible Binary Meta Language, =
specifies a binary and octet (byte) aligned format inspired by the =
principle of XML (a framework for structuring data).=C2=B6


The goal of this document is to define a generic, =
binary, space-efficient format that can be used to define more complex =
formats using an EBML Schema. EBML is used by the multimedia container =
Matroska<=
/a>. The applicability of EBML for other use cases is beyond the scope =
of this document.=C2=B6
=


The definition of the EBML format recognizes the =
idea behind HTML and XML as a good one: separate structure and semantics =
allowing the same structural layer to be used with multiple, possibly =
widely differing semantic layers. Except for the EBML Header and a few =
Global Elements this specification does not define particular EBML =
format semantics; however this specification is intended to define how =
other EBML-based formats can be defined, such as the audio-video =
container formats Matroska and WebM.=C2=B6


EBML uses a simple approach of building Elements =
upon three pieces of data (tag, length, and value) as this approach is =
well known, easy to parse, and allows selective data parsing. The EBML =
structure additionally allows for hierarchical arrangement to support =
complex structural formats in an efficient manner.=C2=B6


A typical EBML file has the following structure:=C2=B6




EBML Header (master)
  + DocType (string)
  + DocTypeVersion (unsigned integer)
EBML Body Root (master)
  + ElementA (utf-8)
  + Parent (master)
    + ElementB (integer)
  + Parent (master)
    + ElementB (integer)

=C2=B6










      

2.=C2=A0Notation and Conventions
      


The key words "MUST", "MUST NOT", "REQUIRED", =
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT =
RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be =
interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in =
all capitals, as shown here.=C2=B6


This document defines specific terms in order to =
define the format and application of EBML. Specific terms =
are defined below:=C2=B6

EBML: Extensible Binary Meta =
Language=C2=B6


EBML Document Type: A name provided =
by an EBML Schema to designate a particular implementation =
of EBML for a data format (e.g.: matroska and webm).=C2=B6


EBML Schema: A standardized =
definition for the structure of an EBML Document Type.=C2=B6


EBML Document: A datastream comprised =
of only two components, an EBML Header and an EBML =
Body.=C2=B6


EBML Reader: A data parser that =
interprets the semantics of an EBML Document and creates a =
way for programs to use EBML.=C2=B6


EBML Stream: A file that consists of =
one or more EBML Documents that are concatenated =
together.=C2=B6


EBML Header: A declaration that =
provides processing instructions and identification of the EBML =
Body. The EBML Header is analogous to an XML =
Declaration [W3C.REC-xml-20081126] (see section 2.8 on =
Prolog and Document Type Declaration).=C2=B6


EBML Body: All data of an EBML =
Document following the EBML Header.=C2=B6


Variable Size Integer: A compact =
variable-length binary value which defines its own length.=C2=B6


VINT: Also known as Variable =
Size Integer.=C2=B6=



EBML Element: A foundation block of =
data that contains three parts: an Element ID, an =
Element Data Size, and Element Data.=C2=B6


Element ID: The Element =
ID is a binary value, encoded as a Variable Size =
Integer, used to uniquely identify a defined EBML =
Element within a specific EBML Schema.=C2=B6


EBML Class: A representation of the =
octet length of an Element ID.=C2=B6


Element Data Size: An expression, =
encoded as a Variable Size Integer, of the length in octets =
of Element Data.=C2=B6


VINTMAX: The maximum possible value =
that can be stored as Element Data Size.=C2=B6


Unknown-Sized Element: An =
Element with an unknown Element Data Size.=C2=B6


Element Data: The value(s) of the =
EBML Element which is identified by its Element =
ID and Element Data Size. The form of the =
Element Data is defined by this document and the =
corresponding EBML Schema of the Element's EBML =
Document Type.=C2=B6


Root Level: The starting level in =
the hierarchy of an EBML Document.=C2=B6


Root Element: A mandatory, =
non-repeating EBML Element which occurs at the top level of =
the path hierarchy within an EBML Body and contains all =
other EBML Elements of the EBML Body, =
excepting optional Void Elements.=C2=B6


Top-Level Element: An EBML =
Element defined to only occur as a Child Element of =
the Root Element.=C2=B6


Master Element: The Master =
Element contains zero, one, or many other EBML =
Elements.=C2=B6
=


Child Element: A Child =
Element is a relative term to describe the EBML =
Elements immediately contained within a Master =
Element.=C2=B6


Parent Element: A relative term to =
describe the Master Element which contains a specified =
element. For any specified EBML Element that is not at =
Root Level, the Parent Element refers to the =
Master Element in which that EBML Element is =
contained.=C2=B6


Descendant Element: A relative term =
to describe any EBML Elements contained within a =
Master Element, including any of the Child =
Elements of its Child Elements, and so on.=C2=B6


Void Element: A Void =
Element is an Element used to overwrite data or =
reserve space within a Master Element for later use.=C2=B6


Element Name: The human-readable =
name of the EBML Element.=C2=B6


Element Path: The hierarchy of =
Parent Element where the EBML Element is =
expected to be found in the EBML Body.=C2=B6


Empty Element: An EBML =
Element that has an Element Data Size with all =
VINT_DATA bits set to zero, which indicates that the =
Element Data of the Element is zero octets in =
length.=C2=B6









      

3.=C2=A0Structure
      


EBML uses a system of Elements to compose an EBML =
Document. EBML Elements incorporate three parts: an Element ID, an =
Element Data Size, and Element Data. The Element Data, which is =
described by the Element ID, includes either binary data, one or more =
other EBML Elements, or both.=C2=B6









      

4.=C2=A0Variable Size Integer
      


The Element ID and Element Data Size are both =
encoded as a Variable Size Integer. The Variable Size Integer is =
composed of a VINT_WIDTH, VINT_MARKER, and VINT_DATA, in that order. =
Variable Size Integers MUST left-pad the VINT_DATA value with zero bits =
so that the whole Variable Size Integer is octet-aligned. Variable Size =
Integer will be referred to as VINT for shorthand.=C2=B6





        

4.1.=C2=A0VINT_WIDTH
        


Each Variable Size Integer begins with a =
VINT_WIDTH which consists of zero or many zero-value bits. The count of =
consecutive zero-values of the VINT_WIDTH plus one equals the length in =
octets of the Variable Size Integer. For example, a Variable Size =
Integer that starts with a VINT_WIDTH which contains zero consecutive =
zero-value bits is one octet in length and a Variable Size Integer that =
starts with one consecutive zero-value bit is two octets in length. The =
VINT_WIDTH MUST only contain zero-value bits or be empty.=C2=B6


Within the EBML Header the VINT_WIDTH of a VINT =
MUST NOT exceed three bits in length (meaning that the Variable Size =
Integer MUST NOT exceed four octets in length) except if said VINT is =
used to express the Element Data Size of an EBML Element with Element =
Name EBML and Element ID 0x1A45DFA3 (see the definition of the EBML Element) in which =
case the VINT_WIDTH MUST NOT exceed seven bits in length. Within the =
EBML Body, when a VINT is used to express an Element ID, the maximum =
length allowed for the VINT_WIDTH is one less than the value set in the =
EBMLMaxIDLength Element. Within the EBML Body, when a VINT is used to =
express an Element Data Size, the maximum length allowed for the =
VINT_WIDTH is one less than the value set in the EBMLMaxSizeLength =
Element.=C2=B6









        

4.2.=C2=A0VINT_MARKER
        


The VINT_MARKER serves as a separator between =
the VINT_WIDTH and VINT_DATA. Each Variable Size Integer MUST contain =
exactly one VINT_MARKER. The VINT_MARKER is one bit in length and =
contain a bit with a value of one. The first bit with a value of one =
within the Variable Size Integer is the VINT_MARKER.=C2=B6









        

4.3.=C2=A0VINT_DATA
        


The VINT_DATA portion of the Variable Size =
Integer includes all data that follows (but not including) the =
VINT_MARKER until end of the Variable Size Integer whose length is =
derived from the VINT_WIDTH. The bits required for the VINT_WIDTH and =
the VINT_MARKER use one out of every eight bits of the total length of =
the Variable Size Integer. Thus a Variable Size Integer of 1 octet =
length supplies 7 bits for VINT_DATA, a 2 octet length supplies 14 bits =
for VINT_DATA, and a 3 octet length supplies 21 bits for VINT_DATA. If =
the number of bits required for VINT_DATA are less than the bit size of =
VINT_DATA, then VINT_DATA MUST be zero-padded to the left to a size that =
fits. The VINT_DATA value MUST be expressed as a big-endian unsigned =
integer.=C2=B6









        

4.4.=C2=A0VINT =
Examples
        


This table shows examples of Variable Size =
Integers with lengths from 1 to 5 octets. The Usable Bits column refers =
to the number of bits that can be used in the VINT_DATA. The =
Representation column depicts a binary expression of Variable Size =
Integers where VINT_WIDTH is depicted by 0, the VINT_MARKER =
as 1, and the VINT_DATA as x.=C2=B6



          Table =
1

            

              Octet =
Length
              Usable =
Bits
              Representation
            

          
          
            

              1
              7
              1xxx =
xxxx
            

            

              2
              14
              01xx =
xxxx xxxx xxxx
            

            

              3
              21
              001x =
xxxx xxxx xxxx xxxx xxxx
            

            

              4
              28
              0001 =
xxxx xxxx xxxx xxxx xxxx xxxx xxxx
            

            

              5
              35
              0000 =
1xxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
            

          
        


Data encoded as a Variable Size Integer may be =
rendered at octet lengths larger than needed to store the data in order =
to facilitate overwriting it at a later date, e.g. when its final size =
isn't known in advance. In this table a binary value of 0b10 is shown =
encoded as different Variable Size Integers with lengths from one octet =
to four octets. All four encoded examples have identical semantic =
meaning though the VINT_WIDTH and the padding of the VINT_DATA vary.=C2=B6



          Table =
2

            

              Binary =
Value
              Octet =
Length
              As =
Represented in Variable Size Integer
            

          
          
            

              10
              1
              1000 =
0010
            

            

              10
              2
              0100 =
0000 0000 0010
            

            

              10
              3
              0010 =
0000 0000 0000 0000 0010
            

            

              10
              4
              0001 =
0000 0000 0000 0000 0000 0000 0010
            

          
        













      

5.=C2=A0Element ID
      


The Element ID is encoded as a Variable Size =
Integer. By default, Element IDs are encoded in lengths from one octet =
to four octets, although Element IDs of greater lengths MAY be used if =
the EBMLMaxIDLength Element of the EBML Header is set to a value greater =
than four (see the section on the =
EBMLMaxIDLength Element). The VINT_DATA component of the Element ID =
MUST NOT be either defined or written as either all zero values or all =
one values. Any Element ID with the VINT_DATA component set as all zero =
values or all one values MUST be ignored. The VINT_DATA component of the =
Element ID MUST be encoded at the shortest valid length. For example, an =
Element ID with binary encoding of 1011 1111 is valid, =
whereas an Element ID with binary encoding of 0100 0000 0011 =
1111 stores a semantically equal VINT_DATA but is invalid because =
a shorter VINT encoding is possible. Additionally, an Element ID with =
binary encoding of 1111 1111 is invalid since the VINT_DATA =
section is set to all one values, whereas an Element ID with binary =
encoding of 0100 0000 0111 1111 stores a semantically equal =
VINT_DATA and is the shortest possible VINT encoding.=C2=B6


The following table details these specific =
examples further:=C2=B6
=

=

          =

          =

          

        Table =
3

          

            VINT_WIDTH
            VINT_MARKER
            VINT_DATA
            Element =
ID Status
          

        
        
          

            
            1
            0000000
            Invalid: =
VINT_DATA MUST NOT be set to all 0
          

          

            0
            1
            00000000000000
            Invalid: =
VINT_DATA MUST NOT be set to all 0
          

          

            
            1
            0000001
            Valid

          

            0
            1
            00000000000001
            Invalid: =
A shorter VINT_DATA encoding is available.
          

          

            
            1
            0111111
            Valid

          

            0
            1
            00000000111111
            Invalid: =
A shorter VINT_DATA encoding is available.
          

          

            
            1
            1111111
            Invalid: =
VINT_DATA MUST NOT be set to all 1
          

          

            0
            1
            00000001111111
            Valid

        
      


The octet length of an Element ID determines its =
EBML Class.=C2=B6



        Table =
4

          

            EBML =
Class
            Length
            Possible=
 IDs
            Number =
of IDs
          

        
        
          

            Class =
A
            1
            0x81 - =
0xFE
            126
          

          

            Class =
B
            2
            0x407F =
- 0x7FFE
            16,256
          

          

            Class =
C
            3
            0x203FFF=
 - 0x3FFFFE
            2,080,768
          

          

            Class =
D
            4
            0x101FFFFF - 0x1FFFFFFE
            268,338,304
          

        
      









      

6.=C2=A0Element =
Data Size
      





        

6.1.=C2=A0Data =
Size Format
        


The Element Data Size expresses the length in =
octets of Element Data. The Element Data Size itself is encoded as a =
Variable Size Integer. By default, Element Data Sizes can be encoded in =
lengths from one octet to eight octets, although Element Data Sizes of =
greater lengths MAY be used if the octet length of the longest Element =
Data Size of the EBML Document is declared in the EBMLMaxSizeLength =
Element of the EBML Header (see the=
 section on the EBMLMaxSizeLength Element). Unlike the VINT_DATA of =
the Element ID, the VINT_DATA component of the Element Data Size is not =
mandated to be encoded at the shortest valid length. For example, an =
Element Data Size with binary encoding of 1011 1111 or a binary encoding =
of 0100 0000 0011 1111 are both valid Element Data Sizes and both store =
a semantically equal value (both 0b00000000111111 and 0b0111111, the =
VINT_DATA sections of the examples, represent the integer 63).=C2=B6


Although an Element ID with all VINT_DATA bits =
set to zero is invalid, an Element Data Size with all VINT_DATA bits set =
to zero is allowed for EBML Element Types which do not mandate a =
non-zero length (see the section on EBML =
Element Types). An Element Data Size with all VINT_DATA bits set to =
zero indicates that the Element Data is zero octets in length. Such an =
EBML Element is referred to as an Empty Element. If an Empty Element has =
a default value declared then the EBML Reader MUST interpret the value =
of the Empty Element as the default value. If an Empty Element has no =
default value declared then the EBML Reader MUST use the value of the =
Empty Element for the corresponding EBML Element Type of the Element ID, =
0 for numbers and an empty string for strings.=C2=B6









        

6.2.=C2=A0Unknown =
Data Size
        


An Element Data Size with all VINT_DATA bits set =
to one is reserved as an indicator that the size of the EBML Element is =
unknown. The only reserved value for the VINT_DATA of Element Data Size =
is all bits set to one. An EBML Element with an unknown Element Data =
Size is referred to as an Unknown-Sized Element. A Master Element MAY be =
an Unknown-Sized Element; however an EBML Element that is not a Master =
Element MUST NOT be an Unknown-Sized Element. Master Elements MUST NOT =
use an unknown size unless the unknownsizeallowed attribute of their =
EBML Schema is set to true (see the =
section on the unknownsizeallowed attribute).=C2=B6


The use of Unknown-Sized Elements allows for an =
EBML Element to be written and read before the size of the EBML Element =
is known. Unknown-Sized Element MUST NOT be used or defined =
unnecessarily; however if the Element Data Size is not known before the =
Element Data is written, such as in some cases of data streaming, then =
Unknown-Sized Elements MAY be used. The end of an Unknown-Sized Element =
is determined by whichever comes first:=C2=B6


    

  • 
            
    Any EBML Element that is a valid =
Parent Element of the Unknown-Sized Element according to the EBML =
Schema, Global Elements excluded.=C2=B6
    

    • 
          
  • 
            
    Any valid EBML Element according =
to the EBML Schema, Global Elements =
excluded, that is not a Descendant Element of the Unknown-Sized Element =
but share a common direct parent, such as a Top-Level Element.=C2=B6
    

    • 
          
  • 
            
    Any EBML Element that is a valid =
Root Element according to the EBML Schema, Global Elements excluded.=C2=B6
    

    • 
          
  • 
            
    The end of the Parent Element =
with a known size has been reached.=C2=B6
    

    • 
          
  • 
            
    The end of the EBML Document, =
either when reaching the end of the file or because a new EBML Header =
started.=C2=B6
    

    • 
        


Consider an Unknown-Sized Element which EBML =
path is \root\level1\level2\elt. When reading a new Element =
ID, assuming the EBML Path of that new Element is valid, here are some =
possible and impossible ways that this new Element is ending =
elt:=C2=B6


          Table =
5

            

              EBML =
Path of new element
              Status
            

          
          
            

              
                \root\level1\level2

              Ends =
the Unknown-Sized Element, as it is a new Parent Element
            

            

              
                \root\level1

              Ends =
the Unknown-Sized Element, as it is a new Parent Element
            

            

              
                \root

              Ends =
the Unknown-Sized Element, as it is a new Root Element
            

            

              
                \root2

              Ends =
the Unknown-Sized Element, as it is a new Root Element
            

            

              
                \root\level1\level2\other

              Ends =
the Unknown-Sized Element, as they share the same parent
            

            

              
                \root\level1\level2\elt

              Ends =
the Unknown-Sized Element, as they share the same parent
            

            

              
                \root\level1\level2\elt\inside

              Doesn't =
end the Unknown-Sized Element, it's a child of elt

            

            

              
                \root\level1\level2\elt\<global>

              Global =
Element is valid, it's a child of elt

            

            

              
                \root\level1\level2\<global>

              Global =
Element cannot be assumed to have this path, while parsing =
elt it can only be a child of elt

            

          
        









        

6.3.=C2=A0Data =
Size Values
        


For Element Data Sizes encoded at octet lengths =
from one to eight, this table depicts the range of possible values that =
can be encoded as an Element Data Size. An Element Data Size with an =
octet length of 8 is able to express a size of 2^56-2 or =
72,057,594,037,927,934 octets (or about 72 petabytes). The maximum =
possible value that can be stored as Element Data Size is referred to as =
VINTMAX.=C2=B6



          Table =
6

            

              Octet =
Length
              Possible=
 Value Range
            

          
          
            

              1
              0 to  =
27-2

            

            

              2
              0 to =
214-2

            

            

              3
              0 to =
221-2

            

            

              4
              0 to =
228-2

            

            

              5
              0 to =
235-2

            

            

              6
              0 to =
242-2

            

            

              7
              0 to =
249-2

            

            

              8
              0 to =
256-2

            

          
        


If the length of Element Data equals 2^(n*7)-1 =
then the octet length of the Element Data Size MUST be at least n+1. =
This rule prevents an Element Data Size from being expressed as the =
unknown size value. The following table clarifies this rule by showing a =
valid and invalid expression of an Element Data Size with a VINT_DATA of =
127 (which is equal to 2^(1*7)-1) and 16,383 (which is equal to =
2(2*7)-1).=C2=B6

=

              =

              

          Table =
7

            

              VINT_WIDTH
              VINT_MARKER
              VINT_DATA
              Element =
Data Size Status
            

          
          
            

              
              1
              1111111
              Reserved=
 (meaning Unknown)
            

            

              0
              1
              00000001111111
              Valid =
(meaning 127 octets)
            

            

              001
              000000000000001111111
              Valid =
(meaning 127 octets)
            

            

              0
              1
              11111111111111
              Reserved=
 (meaning Unknown)
            

            

              001
              000000011111111111111
              Valid =
(16,383 octets)
            

          
        













      

7.=C2=A0EBML =
Element Types
      


EBML Elements are defined by an EBML Schema (see =
Section 11.1) which MUST =
declare one of the following EBML Element Types for each EBML Element. =
An EBML Element Type defines a concept of storing data within an EBML =
Element that describes such characteristics as length, endianness, and =
definition.=C2=B6


EBML Elements which are defined as a Signed =
Integer Element, Unsigned Integer Element, Float Element, or Date =
Element use big endian storage.=C2=B6





        

7.1.=C2=A0Signed Integer Element
        


A Signed Integer Element MUST declare a length =
from zero to eight octets. If the EBML Element is not defined to have a =
default value, then a Signed Integer Element with a zero-octet length =
represents an integer value of zero.=C2=B6


A Signed Integer Element stores an integer =
(meaning that it can be written without a fractional component) which =
could be negative, positive, or zero. Signed Integers are stored with =
two's complement notation with the leftmost bit being the sign bit. =
Because EBML limits Signed Integers to 8 octets in length a Signed =
Integer Element stores a number from -9,223,372,036,854,775,808 to =
+9,223,372,036,854,775,807.=C2=B6









        

7.2.=C2=A0Unsigned Integer Element
        


An Unsigned Integer Element MUST declare a =
length from zero to eight octets. If the EBML Element is not defined to =
have a default value, then an Unsigned Integer Element with a zero-octet =
length represents an integer value of zero.=C2=B6


An Unsigned Integer Element stores an integer =
(meaning that it can be written without a fractional component) which =
could be positive or zero. Because EBML limits Unsigned Integers to 8 =
octets in length an Unsigned Integer Element stores a number from 0 to =
18,446,744,073,709,551,615.=C2=B6









        

7.3.=C2=A0Float =
Element
        


A Float Element MUST declare a length of either =
zero octet (0 bit), four octets (32 bit) or eight octets (64 bit). If =
the EBML Element is not defined to have a default value, then a Float =
Element with a zero-octet length represents a numerical value of zero.=C2=B6


A Float Element stores a floating-point number =
as defined in [IEEE.754.1985].=C2=B6









        

7.4.=C2=A0String =
Element
        


A String Element MUST declare a length in octets =
from zero to VINTMAX. If the EBML Element is not defined to have a =
default value, then a String Element with a zero-octet length represents =
an empty string.=C2=B6

A String Element MUST either be empty =
(zero-length) or contain printable ASCII characters [RFC0020] in the range of =
0x20 to 0x7E, with an exception made for termination (see the section on the Terminating =
Elements).=C2=B6









        

7.5.=C2=A0UTF-8 =
Element
        


A UTF-8 Element MUST declare a length in octets =
from zero to VINTMAX. If the EBML Element is not defined to have a =
default value, then a UTF-8 Element with a zero-octet length represents =
an empty string.=C2=B6

A UTF-8 Element contains only a valid Unicode =
string as defined in [RFC3629], with an exception made for =
termination (see the section on the =
Terminating Elements).=C2=B6









        

7.6.=C2=A0Date =
Element
        


A Date Element MUST declare a length of either =
zero octets or eight octets. If the EBML Element is not defined to have =
a default value, then a Date Element with a zero-octet length represents =
a timestamp of 2001-01-01T00:00:00.000000000 UTC [RFC3339].=C2=B6


The Date Element stores an integer in the same =
format as the Signed Integer Element that expresses a point in time =
referenced in nanoseconds from the precise beginning of the third =
millennium of the Gregorian Calendar in Coordinated Universal Time (also =
known as 2001-01-01T00:00:00.000000000 UTC). This provides a possible =
expression of time from 1708-09-11T00:12:44.854775808 UTC to =
2293-04-11T11:47:16.854775807 UTC.=C2=B6









        

7.7.=C2=A0Master =
Element
        


A Master Element MUST declare a length in octets =
from zero to VINTMAX. The Master Element MAY also use an unknown length. =
See the section on Element Data Size =
for rules that apply to elements of unknown length.=C2=B6


The Master Element contains zero, one, or many =
other elements. EBML Elements contained within a Master Element MUST =
have the EBMLParentPath of their Element Path equal to the =
EBMLMasterPath of the Master Element Element Path (see the section on the EBML Path). Element Data stored =
within Master Elements SHOULD only consist of EBML Elements and SHOULD =
NOT contain any data that is not part of an EBML Element. The EBML =
Schema identifies what Element IDs are valid within the Master Elements =
for that version of the EBML Document Type. Any data contained within a =
Master Element that is not part of a Child Element MUST be ignored.=C2=B6









        

7.8.=C2=A0Binary =
Element
        


A Binary Element MUST declare a length in octets =
from zero to VINTMAX.=C2=B6


The contents of a Binary Element should not be =
interpreted by the EBML Reader.=C2=B6













      

8.=C2=A0EBML =
Document
      


An EBML Document is comprised of only two =
components, an EBML Header and an EBML Body. An EBML Document MUST start =
with an EBML Header that declares significant characteristics of the =
entire EBML Body. An EBML Document consists of EBML Elements and MUST =
NOT contain any data that is not part of an EBML Element.=C2=B6





        

8.1.=C2=A0EBML =
Header
        


The EBML Header is a declaration that provides =
processing instructions and identification of the EBML Body. The EBML =
Header of an EBML Document is analogous to the XML Declaration of an XML =
Document.=C2=B6


The EBML Header documents the EBML Schema (also =
known as the EBML DocType) that is used to semantically interpret the =
structure and meaning of the EBML Document. Additionally the EBML Header =
documents the versions of both EBML and the EBML Schema that were used =
to write the EBML Document and the versions required to read the EBML =
Document.=C2=B6


The EBML Header MUST contain a single Master =
Element with an Element Name of EBML and Element ID of 0x1A45DFA3 (see =
the definition of the EBML Element) and =
any number of additional EBML Elements within it. The EBML Header of an =
EBML Document that uses an EBMLVersion of 1 MUST only contain EBML =
Elements that are defined as part of this document.=C2=B6









        

8.2.=C2=A0EBML Body
        


All data of an EBML Document following the EBML =
Header is the EBML Body. The end of the EBML Body, as well as the end of =
the EBML Document that contains the EBML Body, is reached at whichever =
comes first: the beginning of a new EBML Header at the Root Level or the =
end of the file. The EBML Body MUST NOT contain any data that is not =
part of an EBML Element. This document defines precisely which EBML =
Elements are to be used within the EBML Header, but does not name or =
define which EBML Elements are to be used within the EBML Body. The =
definition of which EBML Elements are to be used within the EBML Body is =
defined by an EBML Schema.=C2=B6













      

9.=C2=A0EBML =
Stream
      


An EBML Stream is a file that consists of one or =
more EBML Documents that are concatenated together. An occurrence of a =
EBML Header at the Root Level marks the beginning of an EBML Document.=C2=B6









      

10.=C2=A0EBML =
Versioning
      


An EBML Document handles 2 different versions: =
the version of the EBML Header and the version of the EBML Body. Both =
versions are meant to be backward compatible.=C2=B6





        

10.1.=C2=A0=
EBML Header Version
        


The version of the EBML Header is found in =
EBMLVersion. An EBML parser can read an EBML Header if it can read =
either the EBMLVersion version or a version equal or higher than the one =
found in EBMLReadVersion.=C2=B6









        

10.2.=C2=A0=
EBML Document Version
        


The version of the EBML Body is found in =
EBMLDocTypeVersion. A parser for the particular DocType format can read =
the EBML Document if it can read either the EBMLDocTypeVersion version =
of that format or a version equal or higher than the one found in =
EBMLDocTypeReadVersion.=C2=B6













      

11.=C2=A0Elements =
semantic
      





        

11.1.=C2=A0=
EBML =
Schema
        


An EBML Schema is a well-formed XML Document =
[W3C.REC-xml-20081126] that defines the =
properties, arrangement, and usage of EBML Elements that compose a =
specific EBML Document Type. The relationship of an EBML Schema to an =
EBML Document is analogous to the relationship of an XML Schema =
[W3C.REC-xmlschema-0-20041028] to an XML =
Document [W3C.REC-xml-20081126]. An EBML Schema MUST be =
clearly associated with one or more EBML Document Types. An EBML =
Document Type is identified by a string stored within the EBML Header in =
the DocType Element; for example matroska or webm (see the definition of the DocType Element). =
The DocType value for an EBML Document Type MUST be unique and =
persistent.=C2=B6


An EBML Schema MUST declare exactly one EBML =
Element at Root Level (referred to as the Root Element) that occurs =
exactly once within an EBML Document. The Void Element MAY also occur at =
Root Level but is not a Root Element (see the =
definition of the Void Element).=C2=B6


The EBML Schema MUST document all Elements of =
the EBML Body. The EBML Schema does not document Global Elements that are defined by this =
document (namely the Void Element and the CRC-32 Element).=C2=B6


The EBML Schema MUST NOT use the Element ID =
0x1A45DFA3 which is reserved for the EBML Header for =
resynchronization purpose.=C2=B6


An EBML Schema MAY constrain the use of EBML =
Header Elements (see EBML Header =
Elements) by adding or constraining that Element's =
range attribute. For example, an EBML Schema MAY constrain =
the EBMLMaxSizeLength to a maximum value of 8 or MAY =
constrain the EBMLVersion to only support a value of 1. If =
an EBML Schema adopts the EBML Header Element as-is, then it is not =
required to document that Element within the EBML Schema. If an EBML =
Schema constrains the range of an EBML Header Element, then that Element =
MUST be documented within an <element> node of the =
EBML Schema. This document provides an example of an EBML Schema, see EBML Schema Example.=C2=B6





          

11.1.1.=C2=A0EBML Schema Example
          




<?xml version=3D"1.0" =
encoding=3D"utf-8"?>
<EBMLSchema xmlns=3D"https://ietf.org/cellar/ebml"
  docType=3D"files-in-ebml-demo" version=3D"1">
 <!-- constraints to the range of two EBML Header Elements -->
 <element name=3D"EBMLReadVersion" path=3D"1*1(\EBML\EBMLReadVersion)"
   id=3D"0x42F7" minOccurs=3D"1" maxOccurs=3D"1" range=3D"1" default=3D"1"=

   type=3D"uinteger"/>
 <element name=3D"EBMLMaxSizeLength"
   path=3D"1*1(\EBML\EBMLMaxSizeLength)" id=3D"0x42F3" minOccurs=3D"1"
   maxOccurs=3D"1" range=3D"8" default=3D"8" type=3D"uinteger"/>
 <!-- Root Element-->
 <element name=3D"Files" path=3D"*1(\Files)" id=3D"0x1946696C"
   type=3D"master">
  <documentation lang=3D"en" purpose=3D"definition">Container of =
data and
  attributes representing one or many files.</documentation>
 </element>
 <element name=3D"File" path=3D"1*(\Files\File)" id=3D"0x6146"
   type=3D"master" minOccurs=3D"1">
  <documentation lang=3D"en" purpose=3D"definition">
    An attached file.
  </documentation>
 </element>
 <element name=3D"FileName" path=3D"1*1(\Files\File\FileName)"
   id=3D"0x614E" type=3D"utf-8"
   minOccurs=3D"1">
  <documentation lang=3D"en" purpose=3D"definition">
    Filename of the attached file.
  </documentation>
 </element>
 <element name=3D"MimeType" path=3D"1*1(\Files\File\MimeType)"
   id=3D"0x464D" type=3D"string"
     minOccurs=3D"1">
  <documentation lang=3D"en" purpose=3D"definition">
    MIME type of the file.
  </documentation>
 </element>
 <element name=3D"ModificationTimestamp"
   path=3D"1*1(\Files\File\ModificationTimestamp)" id=3D"0x4654"
   type=3D"date" minOccurs=3D"1">
  <documentation lang=3D"en" purpose=3D"definition">
    Modification timestamp of the file.
  </documentation>
 </element>
 <element name=3D"Data" path=3D"1*1(\Files\File\Data)" id=3D"0x4664"=20=

   type=3D"binary" minOccurs=3D"1">
  <documentation lang=3D"en" purpose=3D"definition">
    The data of the file.
  </documentation>
 </element>
</EBMLSchema>

=C2=B6










          

11.1.2.=C2=A0<EBMLSchema> Element
          


As an XML Document, the EBML Schema MUST use =
<EBMLSchema> as the top level element. The =
<EBMLSchema> element can contain =
<element> sub-elements.=C2=B6









          

11.1.3.=C2=A0<EBMLSchema> Attributes
          


Within an EBML Schema the =
<EBMLSchema> element uses the following attributes:=C2=B6





            

11.1.3.1.=C2=A0docType
            


The docType lists the official name of the =
EBML Document Type that is defined by the EBML Schema; for example, =
<EBMLSchema docType=3D"matroska">.=C2=B6


The docType attribute is REQUIRED within =
the <EBMLSchema> Element.=C2=B6









            

11.1.3.2.=C2=A0version
            


The version lists a non-negative integer =
that specifies the version of the docType documented by the EBML Schema. =
Unlike XML Schemas, an EBML Schema documents all versions of a docType's =
definition rather than using separate EBML Schemas for each version of a =
docType. EBML Elements may be introduced and deprecated by using the =
minver and maxver attributes of <element>.=C2=B6


The version attribute is REQUIRED within =
the <EBMLSchema> Element.=C2=B6













          

11.1.4.=C2=A0<element> Element
          


Each <element> defines one =
EBML Element through the use of several attributes that are defined in =
EBML Schema Element Attributes. =
EBML Schemas MAY contain additional attributes to extend the semantics =
but MUST NOT conflict with the definitions of the =
<element> attributes defined within this document.=C2=B6


The <element> nodes =
contain a description of the meaning and use of the EBML Element stored =
within one or more <documentation> sub-elements, =
followed by optional <implementation_note> =
sub-elements, followed by zero or one <restriction> =
sub-element, followed by optional <extension> =
sub-elements. All <element> nodes MUST be =
sub-elements of the <EBMLSchema>.=C2=B6









          

11.1.5.=C2=A0<element> Attributes
          


Within an EBML Schema the =
<element> uses the following attributes to define an =
EBML Element:=C2=B6




            

11.1.5.1.=C2=A0name
            


The name provides the human-readable name =
of the EBML Element. The value of the name MUST be in the form of =
characters "A" to "Z", "a" to "z", "0" to "9", "-" and ".".=C2=B6


The name attribute is REQUIRED.=C2=B6









            

11.1.5.2.=C2=A0path
            


The path defines the allowed storage =
locations of the EBML Element within an EBML Document. This path MUST be =
defined with the full hierarchy of EBML Elements separated with a =
\. The top EBML Element in the path hierarchy being the =
first in the value. The syntax of the path attribute is defined using =
this Augmented Backus-Naur Form (ABNF) [RFC5234] with the case sensitive update =
[RFC7405] =
notation:=C2=B6


The path attribute is REQUIRED.=C2=B6




EBMLFullPath             =3D EBMLEltOccurrence "(" EBMLMasterPath =
")"
EBMLMasterPath           =3D [EBMLParentPath] EBMLElementPath
EBMLParentPath           =3D EBMLFixedParent EBMLLastParent
EBMLFixedParent          =3D *(EBMLPathAtom)
EBMLElementPath          =3D EBMLPathAtom / EBMLPathAtomRecursive
EBMLPathAtom             =3D PathDelimiter EBMLAtomName
EBMLPathAtomRecursive    =3D "(1*(" EBMLPathAtom "))"
EBMLLastParent           =3D EBMLPathAtom / EBMLGlobalParent
EBMLGlobalParent         =3D "(" GlobalParentOccurence "\)"
EBMLAtomName             =3D 1*(EBMLNameChar)
EBMLNameChar             =3D ALPHA / DIGIT / "-" / "."
PathDelimiter            =3D "\"
EBMLEltOccurrence        =3D [EBMLMinOccurrence] "*" [EBMLMaxOccurrence]
EBMLMinOccurrence        =3D 1*DIGIT ; no upper limit
EBMLMaxOccurrence        =3D 1*DIGIT ; no upper limit
GlobalParentOccurence    =3D [PathMinOccurrence] "*" [PathMaxOccurrence]
PathMinOccurrence        =3D 1*DIGIT ; no upper limit
PathMaxOccurrence        =3D 1*DIGIT ; no upper limit

=C2=B6



The *, ( and =
) symbols are interpreted as defined in [RFC5234].=C2=B6


The EBMLPathAtom part of the =
EBMLElementPath MUST be equal to the name attribute of the EBML =
Schema.=C2=B6


The starting PathDelimiter of the path =
corresponds to the root of the EBML Document.=C2=B6


The EBMLEltOccurrence part is interpreted =
as an ABNF Variable Repetition. The repetition amounts correspond to how =
many times the EBML Element can be found in its Parent Element.=C2=B6


The EBMLMinOccurrence represents the =
minimum permitted number of occurrences of this EBML Element within its =
Parent Element. Each instance of the Parent Element MUST contain at =
least this many instances of this EBML Element. If the EBML Element has =
an empty EBMLParentPath then EBMLMinOccurrence refers to constraints on =
the occurrence of the EBML Element within the EBML Document. If =
EBMLMinOccurrence is not present then that EBML Element has an =
EBMLMinOccurrence value of 0. The semantic meaning of EBMLMinOccurrence =
within an EBML Schema is analogous to the meaning of minOccurs within an =
XML Schema. EBML Elements with EBMLMinOccurrence set to "1" that also =
have a default value (see default) declared are =
not REQUIRED to be stored but are REQUIRED to be interpreted, see Note on the Use of default attributes to define Mandatory EBML =
Elements. An EBML Element defined with a EBMLMinOccurrence value =
greater than zero is called a Mandatory EBML Element.=C2=B6


The EBMLMaxOccurrence represents the =
maximum permitted number of occurrences of this EBML Element within its =
Parent Element. Each instance of the Parent Element MUST contain at most =
this many instances of this EBML Element. If the EBML Element has an =
empty EBMLParentPath then EBMLMaxOccurrence refers to constraints on the =
occurrence of the EBML Element within the EBML Document. If =
EBMLMaxOccurrence is not present then there is no upper bound for the =
permitted number of occurrences of this EBML Element within its Parent =
Element resp. within the EBML Document depending on whether the =
EBMLParentPath of the EBML Element is empty or not. The semantic meaning =
of EBMLMaxOccurrence within an EBML Schema path is analogous to the =
meaning of maxOccurs within an XML Schema.=C2=B6


In some cases the EBMLLastParent part of =
the path is an EBMLGlobalParent. A path with a EBMLGlobalParent defines =
a Global Element. Any path that starts =
with the EBMLFixedParent of the Global Element and matches the =
occurrences found in the GlobalParentOccurence is a valid path for the =
Global Element.=C2=B6


The GlobalParentOccurence part is =
interpreted as an ABNF Variable Repetition. The repetition amounts =
correspond to the amount of unspecified Parent Element levels there can =
be between the EBMLFixedParent and the actual EBMLElementPath.=C2=B6


PathMinOccurrence represents the minimum =
number of element path required between the EBMLFixedParent and the =
Global Element EBMLElementPath. For example 0 means the EBMLElementPath =
can be right after the EBMLFixedParent, 1 means there has to be at least =
an element between the EBMLFixedParent and the EBMLElementPath. If =
PathMinOccurrence is not present then that EBML Element has an =
PathMinOccurrence value of 0.=C2=B6


PathMaxOccurrence represents the maximum =
number of element path possible between the EBMLFixedParent and the =
Global Element EBMLElementPath. It cannot have the value 0 as it would =
be the Global Element can only be found right after the EBMLFixedParent, =
in which case it's not a Global Element anymore. If PathMaxOccurrence is =
not present then there is no upper bound for the permitted number of =
occurrences of element path possible between the EBMLFixedParent and the =
Global Element EBMLElementPath.=C2=B6


If the path contains an =
EBMLPathAtomRecursive part, the EBML Element can occur within itself =
recursively (see the recursive attribute).=C2=B6


As an example, a path of =
1*(\Segment\Info) means the element Info is found inside =
the Segment elements at least once and with no maximum iteration. An =
element SeekHead with path 0*2(\Segment\SeekHead) may not =
be found at all in its Segment parent, once or twice but no more than =
that.=C2=B6









            

11.1.5.3.=C2=A0id
            


The Element ID encoded as a Variable Size =
Integer expressed in hexadecimal notation prefixed by a 0x that is read =
and stored in big-endian order. To reduce the risk of false positives =
while parsing EBML Streams, the Element IDs of the Root Element and =
Top-Level Elements SHOULD be at least 4 octets in length. Element IDs =
defined for use at Root Level or directly under the Root Level MAY use =
shorter octet lengths to facilitate padding and optimize edits to EBML =
Documents; for instance, the Void Element uses an Element ID with a one =
octet length to allow its usage in more writing and editing scenarios.=C2=B6


The id attribute is REQUIRED.=C2=B6









            

11.1.5.4.=C2=A0minOccurs
            


An integer expressing the minimum permitted =
number of occurrences of this EBML Element within its Parent Element. =
The minOccurs value MUST be equal to the EBMLMinOccurrence value of the =
path.=C2=B6


The minOccurs attribute is OPTIONAL. If the =
minOccurs attribute is not present then that EBML Element has a =
minOccurs value of 0.=C2=B6









            

11.1.5.5.=C2=A0maxOccurs
            


An integer expressing the maximum permitted =
number of occurrences of this EBML Element within its Parent Element. =
The maxOccurs value MUST be equal to the EBMLMaxOccurrence value of the =
path.=C2=B6


The maxOccurs attribute is OPTIONAL. If the =
maxOccurs attribute is not present then that EBML Element has no maximum =
occurrence, similar to unbounded in the XML world.=C2=B6









            

11.1.5.6.=C2=A0range
            


A numerical range for EBML Elements which =
are of numerical types (Unsigned Integer, Signed Integer, Float, and =
Date). If specified the value of the EBML Element MUST be within the =
defined range. See section of =
Expressions of range for rules applied to expression of range =
values.=C2=B6


The range attribute is OPTIONAL. If the =
range attribute is not present then any value legal for the type =
attribute is valid.=C2=B6





              

11.1.5.6.1.=C2=A0Expression of range
              


The range attribute MUST only be used =
with EBML Elements that are either signed integer, unsigned integer, =
float, or date. The expression defines the upper, lower, exact or =
excluded value of the EBML Element and optionally an upper boundary =
value combined with a lower boundary. The range expression may contain =
whitespace (using the ASCII 0x20 character) for readability but =
whitespace within a range expression MUST NOT convey meaning.=C2=B6


To set a fixed value for the range, the =
value is used as the attribute value. For example 1234 =
means the EBML element always has the value 1234. The value can be =
prefixed with not to indicate that the fixed value MUST NOT =
be used for that Element. For example not 1234 means the =
Element can use all values of its type except 1234.=C2=B6


For an exclusive lower boundary the =
> sign is used and the >=3D sign is used =
for an inclusive lower boundary. For example >3 meaning =
the Element value MUST be greater than 3 or >=3D0x1p+0 =
meaning the Element value MUST be greater than or equal to the floating =
value 1.0, see textual =
expression of floats.=C2=B6


For an exclusive upper boundary the =
< sign is used and the <=3D sign is used =
for an inclusive upper boundary. For example <-2 meaning =
the Element value MUST be less than -2 or <=3D10 meaning =
the Element value MUST be less than or equal to the 10.=C2=B6


The lower and upper bounds can be =
combined into an expression to form a closed boundary. The lower =
boundary coming first followed by the upper boundary, separated by a =
comma. For example >3,<=3D 20 means the Element value =
MUST be greater than 3 and less than or equal to 20.=C2=B6


A special form of lower and upper bounds =
using the - separator is possible, meaning the Element =
value MUST be greater than or to the first value and MUST be less than =
or equal to the second value. For example 1-10 is =
equivalent to >=3D1,<=3D10. If the upper boundary is =
negative, only the latter form MUST be used.=C2=B6













            

11.1.5.7.=C2=A0length
            


A value to express the valid length of the =
Element Data as written measured in octets. The length provides a =
constraint in addition to the Length value of the definition of the =
corresponding EBML Element Type. This length MUST be expressed as either =
a non-negative integer or a range (see expression of range) that consists of =
only non-negative integers and valid operators.=C2=B6


The length attribute is OPTIONAL. If the =
length attribute is not present for that EBML Element then that EBML =
Element is only limited in length by the definition of the associated =
EBML Element Type.=C2=B6









            

11.1.5.8.=C2=A0default
            


If an Element is mandatory (has a =
EBMLMinOccurrence value greater than zero) but not written within its =
Parent Element or stored as an Empty Element, then the EBML Reader of =
the EBML Document MUST semantically interpret the EBML Element as =
present with this specified default value for the EBML Element. EBML =
Elements that are Master Elements MUST NOT declare a default value. EBML =
Elements with a minOccurs value greater than 1 MUST NOT declare a =
default value.=C2=B6=



The default attribute is OPTIONAL.=C2=B6









            

11.1.5.9.=C2=A0type
            


The type MUST be set to one of the =
following values: integer (signed integer), =
uinteger (unsigned integer), float, =
string, date, utf-8, =
master, or binary. The content of each type is =
defined within section on EBML Element =
Types.=C2=B6
=


The type attribute is REQUIRED.=C2=B6









            

11.1.5.10.=C2=A0unknownsizeallowed
            


A boolean to express if an EBML Element is =
permitted to be Unknown-Sized Element (having all VINT_DATA bits of =
Element Data Size set to 1). EBML Elements that are not Master Elements =
MUST NOT set unknownsizeallowed to true. An EBML Element that is defined =
with an unknownsizeallowed attribute set to 1 MUST also have the =
unknownsizeallowed attribute of its Parent Element set to 1.=C2=B6


An EBML Element with the =
unknownsizeallowed attribute set to 1 MUST NOT have its recursive =
attribute set to 1.=C2=B6


The unknownsizeallowed attribute is =
OPTIONAL. If the unknownsizeallowed attribute is not used then that EBML =
Element is not allowed to use an unknown Element Data Size.=C2=B6









            

11.1.5.11.=C2=A0recursive
            


A boolean to express if an EBML Element is =
permitted to be stored recursively. In this case the EBML Element MAY be =
stored within another EBML Element that has the same Element ID. Which =
itself can be stored in an EBML Element that has the same Element ID, =
and so on. EBML Elements that are not Master Elements MUST NOT set =
recursive to true.=C2=B6


If the path contains an =
EBMLPathAtomRecursive part then the recursive value MUST be true and =
false otherwise.=C2=B6


An EBML Element with the recursive =
attribute set to 1 MUST NOT have its unknownsizeallowed attribute set to =
1.=C2=B6


The recursive attribute is OPTIONAL. If =
the recursive attribute is not present then the EBML Element MUST NOT be =
used recursively.=C2=B6









            

11.1.5.12.=C2=A0recurring
            


A boolean to express if an EBML Element is =
defined as an Identically Recurring Element or not.=C2=B6


The recurring attribute is OPTIONAL. If =
the recurring attribute is not present then the EBML Element is not an =
Identically Recurring Element.=C2=B6









            

11.1.5.13.=C2=A0minver
            


The minver (minimum version) attribute =
stores a non-negative integer that represents the first version of the =
docType to support the EBML Element.=C2=B6


The minver attribute is OPTIONAL. If the =
minver attribute is not present, then the EBML Element has a minimum =
version of "1".=C2=B6









            

11.1.5.14.=C2=A0maxver
            


The maxver (maximum version) attribute =
stores a non-negative integer that represents the last or most recent =
version of the docType to support the element. maxver MUST be greater =
than or equal to minver.=C2=B6


The maxver attribute is OPTIONAL. If the =
maxver attribute is not present then the EBML Element has a maximum =
version equal to the value stored in the version attribute of =
<EBMLSchema>.=C2=B6













          

11.1.6.=C2=A0<documentation> Element
          


The <documentation> =
element provides additional information about the EBML Element. Within =
the <documentation> element the following XHTML =
[W3C.SPSD-xhtml-basic-20180327] elements MAY be =
used: <a>, <br>, =
<strong>.=C2=B6









          

11.1.7.=C2=A0<documentation> Attributes
          





            

11.1.7.1.=C2=A0lang
            


A lang attribute which is set to the =
[RFC5646] value of =
the language of the element's documentation.=C2=B6


The lang attribute is OPTIONAL.=C2=B6









            

11.1.7.2.=C2=A0purpose
            


A purpose attribute distinguishes the =
meaning of the documentation. Values for the =
<documentation> sub-element's purpose attribute MUST =
include one of the following: definition, =
rationale, usage notes, and =
references.=C2=B6


The purpose attribute is REQUIRED.=C2=B6













          

11.1.8.=C2=A0<implementation_note> Element
          


In some cases within an EBML Document Type, =
the attributes of the <element> element are not =
sufficient to clearly communicate how the defined EBML Element is =
intended to be implemented.
For instance, one EBML Element might only be mandatory if another EBML =
Element is present, or as another example, the default value of an EBML =
Element might derive from a related Element's content.
In these cases where the Element's definition is conditional or advanced =
implementation notes are needed, one or many =
<implementation_note> elements can be used to store =
that information.
The <implementation_note> refer to a specific =
attribute of the parent <element> as expressed by the =
note_attribute attribute Section 11.1.9.1.=C2=B6









          

11.1.9.=C2=A0<implementation_note> =
Attributes
          





            

11.1.9.1.=C2=A0note_attribute
            


The note_attribute attribute references =
which of the <element>'s attributes that the =
implementation_note is in regards to.
The note_attribute attribute MUST be set to one of the following values =
(corresponding to that attribute of the parent =
<element>): minOccurs, =
maxOccurs, range, length, =
default, minver, or maxver.
The <implementation_note> SHALL supersede the parent =
<element>'s attribute that is named in the =
note_attribute attribute.
An <element> SHALL NOT have more than one =
<implementation_note> of the same =
note_attribute.=C2=B6


The note_attribute attribute is REQUIRED.=C2=B6













          

11.1.10.=C2=A0<restriction> Element
          


The <restriction> element =
provides information about restrictions to the allowable values for the =
EBML Element which are listed in <enum> elements.=C2=B6









          

11.1.11.=C2=A0<enum> Element
          


The <enum> element stores =
a list of values allowed for storage in the EBML Element. The values =
MUST match the type of the EBML Element (for example <enum =
value=3D"Yes"> cannot be a valid value for a EBML Element that =
is defined as an unsigned integer). An <enum> element =
MAY also store <documentation> elements to further =
describe the <enum>.=C2=B6









          

11.1.12.=C2=A0<enum> Attributes
          





            

11.1.12.1.=C2=A0label
            


The label provides a concise expression =
for human consumption that describes what the value of the =
<enum> represents.=C2=B6


The label attribute is OPTIONAL.=C2=B6









            

11.1.12.2.=C2=A0value
            


The value represents data that MAY be =
stored within the EBML Element.=C2=B6


The value attribute is REQUIRED.=C2=B6













          

11.1.13.=C2=A0<extension> Element
          


The <extension> element =
provides an unconstrained element to contain information about the =
associated EBML <element> which is undefined by this =
document but MAY be defined by the associated EBML Document Type. The =
<extension> element MUST contain a type =
attribute and also MAY contain any other attribute or sub-element as =
long as the EBML Schema remains as a well-formed XML Document. All =
<extension> elements MUST be sub-elements of the =
<element>.=C2=B6









          

11.1.14.=C2=A0<extension> Attributes
          





            

11.1.14.1.=C2=A0type
            


The type attribute should reference a name =
or identifier of the project or authority associated with the contents =
of the <extension> element.=C2=B6


The type attribute is REQUIRED.=C2=B6













          

11.1.15.=C2=A0XML Schema for EBML Schema
          


This following provides an XML Schema =
[W3C.REC-xmlschema-0-20041028] for facilitating =
verification of an EBML Schema to the definition described in Section 8.1.=C2=B6




<?xml version=3D"1.0" =
encoding=3D"UTF-8"?>
<xs:schema xmlns=3D"https://ietf.org/cellar/ebml"
  targetNamespace=3D"https://ietf.org/cellar/ebml"
  xmlns:xs=3D"http://www.w3.org/2001/XMLSchema"
  xmlns:xhtml=3D"http://www.w3.org/1999/xhtml"
  elementFormDefault=3D"qualified" version=3D"01">

  <!-- for HTML in comments -->
  <xs:import namespace=3D"http://www.w3.org/1999/xhtml"
    schemaLocation=3D"http://www.w3.org/MarkUp/SCHEMA/xhtml11.xsd"/>

  <xs:element name=3D"EBMLSchema" type=3D"EBMLSchemaType"/>

  <xs:complexType name=3D"EBMLSchemaType">
    <xs:sequence>
      <xs:element name=3D"element" type=3D"elementType"
        minOccurs=3D"0" maxOccurs=3D"unbounded"/>
    </xs:sequence>
    <xs:attribute name=3D"docType" use=3D"required"/>
    <xs:attribute name=3D"version" use=3D"required"/>
  </xs:complexType>

  <xs:complexType name=3D"elementType">
    <xs:sequence>
      <xs:element name=3D"documentation" type=3D"documentationType"
        minOccurs=3D"0" maxOccurs=3D"unbounded"/>
      <xs:element name=3D"implementation_note" type=3D"noteType"
        minOccurs=3D"0" maxOccurs=3D"unbounded"/>
      <xs:element name=3D"restriction" type=3D"restrictionType"
        minOccurs=3D"0" maxOccurs=3D"1"/>
      <xs:element name=3D"extension" type=3D"extensionType"
        minOccurs=3D"0" maxOccurs=3D"unbounded"/>
    </xs:sequence>
    <xs:attribute name=3D"name" use=3D"required"/>
    <xs:attribute name=3D"path" use=3D"required"/>
    <xs:attribute name=3D"id" use=3D"required"/>
    <xs:attribute name=3D"minOccurs" default=3D"0"/>
    <xs:attribute name=3D"maxOccurs" default=3D"1"/>
    <xs:attribute name=3D"range"/>
    <xs:attribute name=3D"length"/>
    <xs:attribute name=3D"default"/>
    <xs:attribute name=3D"type" use=3D"required"/>
    <xs:attribute name=3D"unknownsizeallowed"/>
    <xs:attribute name=3D"recurring"/>
    <xs:attribute name=3D"minver" default=3D"1"/>
    <xs:attribute name=3D"maxver"/>
  </xs:complexType>

  <xs:complexType name=3D"restrictionType">
    <xs:sequence>
      <xs:element name=3D"enum" type=3D"enumType"
        minOccurs=3D"0" maxOccurs=3D"unbounded"/>
    </xs:sequence>
  </xs:complexType>

  <xs:complexType name=3D"extensionType">
    <xs:sequence>
      <xs:any processContents=3D"skip"
        minOccurs=3D"0" maxOccurs=3D"unbounded"/>
    </xs:sequence>
    <xs:attribute name=3D"type" use=3D"required"/>
    <xs:anyAttribute processContents=3D"skip"/>
  </xs:complexType>

  <xs:complexType name=3D"enumType">
    <xs:sequence>
      <xs:element name=3D"documentation" type=3D"documentationType"
        minOccurs=3D"0" maxOccurs=3D"unbounded"/>
    </xs:sequence>
    <xs:attribute name=3D"label"/>
    <xs:attribute name=3D"value" use=3D"required"/>
  </xs:complexType>

  <xs:complexType name=3D"documentationType" mixed=3D"true">
    <xs:sequence>
      <xs:element name=3D"a"      type=3D"xhtml:xhtml.a.type"=20
        minOccurs=3D"0" maxOccurs=3D"unbounded"/>
      <xs:element name=3D"br"     type=3D"xhtml:xhtml.br.type"
        minOccurs=3D"0" maxOccurs=3D"unbounded"/>
      <xs:element name=3D"strong" type=3D"xhtml:xhtml.strong.type"
        minOccurs=3D"0" maxOccurs=3D"unbounded"/>
    </xs:sequence>
    <xs:attribute name=3D"lang"/>
    <xs:attribute name=3D"purpose" use=3D"required">
      <xs:simpleType>
        <xs:restriction base=3D"xs:string">
          <xs:enumeration value=3D"definition"/>
          <xs:enumeration value=3D"rationale"/>
          <xs:enumeration value=3D"references"/>
          <xs:enumeration value=3D"usage notes"/>
        </xs:restriction>
      </xs:simpleType>
    </xs:attribute>
  </xs:complexType>

  <xs:complexType name=3D"noteType">
    <xs:simpleContent>
      <xs:extension base=3D"xs:string">
        <xs:attribute name=3D"note_attribute" use=3D"required">
          <xs:simpleType>
            <xs:restriction base=3D"xs:string">
              <xs:enumeration value=3D"minOccurs"/>
              <xs:enumeration value=3D"maxOccurs"/>
              <xs:enumeration value=3D"range"/>
              <xs:enumeration value=3D"length"/>
              <xs:enumeration value=3D"default"/>
              <xs:enumeration value=3D"minver"/>
              <xs:enumeration value=3D"maxver"/>
            </xs:restriction>
          </xs:simpleType>
        </xs:attribute>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
</xs:schema>

=C2=B6










          

11.1.16.=C2=A0Identically Recurring Elements
          


An Identically Recurring Element is an EBML =
Element that MAY occur within its Parent Element more than once but that =
each recurrence within that Parent Element MUST be identical both in =
storage and semantics. Identically Recurring Elements are permitted to =
be stored multiple times within the same Parent Element in order to =
increase data resilience and optimize the use of EBML in transmission. =
For instance a pertinent Top-Level Element could be periodically resent =
within a data stream so that an EBML Reader which starts reading the =
stream from the middle could better interpret the contents. Identically =
Recurring Elements SHOULD include a CRC-32 Element as a Child Element; =
this is especially recommended when EBML is used for long-term storage =
or transmission. If a Parent Element contains more than one copy of an =
Identically Recurring Element which includes a CRC-32 Element as a Child =
Element then the first instance of the Identically Recurring Element =
with a valid CRC-32 value should be used for interpretation. If a Parent =
Element contains more than one copy of an Identically Recurring Element =
which does not contain a CRC-32 Element or if CRC-32 Elements are =
present but none are valid then the first instance of the Identically =
Recurring Element should be used for interpretation.=C2=B6









          

11.1.17.=C2=A0Textual expression of floats
          


When a float value is represented textually =
in an EBML Schema, such as within a default or range value, the float =
values MUST be expressed as Hexadecimal Floating-Point Constants as =
defined in the C11 standard [ISO.9899.2011] (see section 6.4.4.2 on =
Floating Constants). The following table provides examples of =
expressions of float ranges.=C2=B6



            Table =
8

              

                as =
decimal
                as =
Hexadecimal Floating-Point Constants
              

            
            
              

                0.0
                
                  0x0p+1

              

              

                0.0-1.0
                
                  0x0p+1-0x1p+0

              

              

                1.0-256.0
                
                  0x1p+0-0x1p+8

              

              

                0.857421875
                
                  0x1.b7p-1

              

              

                -1.0--0.857421875
                
                  -0x1p+0--0x1.b7p-1

              

            
          


Within an expression of a float range, as in =
an integer range, the - (hyphen) character is the separator between the =
minimal and maximum value permitted by the range. Hexadecimal =
Floating-Point Constants also use a - (hyphen) when indicating a =
negative binary power. Within a float range, when a - (hyphen) is =
immediately preceded by a letter p, then the - (hyphen) is a part of the =
Hexadecimal Floating-Point Constant which notes negative binary power. =
Within a float range, when a - (hyphen) is not immediately preceded by a =
letter p, then the - (hyphen) represents the separator between the =
minimal and maximum value permitted by the range.=C2=B6









          

11.1.18.=C2=A0Note on the use of default attributes to =
define Mandatory EBML Elements
          


If a Mandatory EBML Element has a default =
value declared by an EBML Schema and the value of the EBML Element is =
equal to the declared default value then that EBML Element is not =
required to be present within the EBML Document if its Parent Element is =
present. In this case, the default value of the Mandatory EBML Element =
MUST be read by the EBML Reader although the EBML Element is not present =
within its Parent Element.=C2=B6


If a Mandatory EBML Element has no default =
value declared by an EBML Schema and its Parent Element is present then =
the EBML Element MUST be present as well. If a Mandatory EBML Element =
has a default value declared by an EBML Schema and its Parent Element is =
present and the value of the EBML Element is NOT equal to the declared =
default value then the EBML Element MUST be present.=C2=B6


This table clarifies if a Mandatory EBML =
Element MUST be written, according to if the default value is declared, =
if the value of the EBML Element is equal to the declared default value, =
and if the Parent Element is used.=C2=B6



            Table =
9

              

                Is =
the default value declared?
                Is =
the value equal to default?
                Is =
the Parent Element present?
                Then=
 is storing the EBML Element REQUIRED?
              

            
            
              

                Yes
                Yes
                Yes
                No
              

              

                Yes
                Yes
                No
                No
              

              

                Yes
                No
                Yes
                Yes
              

              

                Yes
                No
                No
                No
              

              

                No
                n/a
                Yes
                Yes
              

              

                No
                n/a
                No
                No
              

            
          













        

11.2.=C2=A0=
EBML Header Elements
        


This document contains definitions of all EBML =
Elements of the EBML Header.=C2=B6





          

11.2.1.=C2=A0EBML Element
          


name: EBML=C2=B6


path: 1*1(\EBML)=C2=B6


id: 0x1A45DFA3=C2=B6


minOccurs: 1=C2=B6


maxOccurs: 1=C2=B6


type: Master Element=C2=B6


description: Set the EBML characteristics of =
the data to follow. Each EBML Document has to start with this.=C2=B6









          

11.2.2.=C2=A0EBMLVersion Element
          


name: EBMLVersion=C2=B6


path: 1*1(\EBML\EBMLVersion)=C2=B6


id 0x4286=C2=B6


minOccurs: 1=C2=B6


maxOccurs: 1=C2=B6


range: not 0=C2=B6


default: 1=C2=B6


type: Unsigned Integer=C2=B6


description: The version of EBML =
specifications used to create the EBML Document. The version of EBML =
defined in this document is 1, so EBMLVersion SHOULD be 1.=C2=B6









          

11.2.3.=C2=A0EBMLReadVersion Element
          


name: EBMLReadVersion=C2=B6


path: =
1*1(\EBML\EBMLReadVersion)=C2=B6


id: 0x42F7=C2=B6


minOccurs: 1=C2=B6


maxOccurs: 1=C2=B6


range: 1=C2=B6


default: 1=C2=B6


type: Unsigned Integer=C2=B6


description: The minimum EBML version an EBML =
Reader has to support to read this EBML Document. The EBMLReadVersion =
Element MUST be less than or equal to EBMLVersion.=C2=B6









          

11.2.4.=C2=A0EBMLMaxIDLength Element
          


name: EBMLMaxIDLength=C2=B6


path: =
1*1(\EBML\EBMLMaxIDLength)=C2=B6


id 0x42F2=C2=B6


minOccurs: 1=C2=B6


maxOccurs: 1=C2=B6


range: >=3D4=C2=B6


default: 4=C2=B6


type: Unsigned Integer=C2=B6


description: The EBMLMaxIDLength Element =
stores the maximum permitted length in octets of the Element IDs to be =
found within the EBML Body. An EBMLMaxIDLength Element value of four is =
RECOMMENDED, though larger values are allowed.=C2=B6









          

11.2.5.=C2=A0EBMLMaxSizeLength Element
          


name: EBMLMaxSizeLength=C2=B6


path: =
1*1(\EBML\EBMLMaxSizeLength)=C2=B6


id 0x42F3=C2=B6


minOccurs: 1=C2=B6


maxOccurs: 1=C2=B6


range: not 0=C2=B6


default: 8=C2=B6


type: Unsigned Integer=C2=B6


description: The EBMLMaxSizeLength Element =
stores the maximum permitted length in octets of the expressions of all =
Element Data Sizes to be found within the EBML Body. The =
EBMLMaxSizeLength Element documents an upper bound for the =
length of all Element Data Size expressions within the EBML =
Body and not an upper bound for the value of all Element =
Data Size expressions within the EBML Body. EBML Elements that have an =
Element Data Size expression which is larger in octets than what is =
expressed by EBMLMaxSizeLength Element are invalid.=C2=B6









          

11.2.6.=C2=A0DocType Element
          


name: DocType=C2=B6


path: 1*1(\EBML\DocType)=C2=B6


id 0x4282=C2=B6


minOccurs: 1=C2=B6


maxOccurs: 1=C2=B6


length: >0=C2=B6


type: String=C2=B6


description: A string that describes and =
identifies the content of the EBML Body that follows this EBML Header.=C2=B6









          

11.2.7.=C2=A0DocTypeVersion Element
          


name: DocTypeVersion=C2=B6


path: =
1*1(\EBML\DocTypeVersion)=C2=B6


id 0x4287=C2=B6


minOccurs: 1=C2=B6


maxOccurs: 1=C2=B6


range: not 0=C2=B6


default: 1=C2=B6


type: Unsigned Integer=C2=B6


description: The version of DocType =
interpreter used to create the EBML Document.=C2=B6









          

11.2.8.=C2=A0DocTypeReadVersion Element
          


name: DocTypeReadVersion=C2=B6


path: =
1*1(\EBML\DocTypeReadVersion)=C2=B6


id 0x4285=C2=B6


minOccurs: 1=C2=B6


maxOccurs: 1=C2=B6


range: not 0=C2=B6


default: 1=C2=B6


type: Unsigned Integer=C2=B6


description: The minimum DocType version an =
EBML Reader has to support to read this EBML Document. The value of the =
DocTypeReadVersion Element MUST be less than or equal to the value of =
the DocTypeVersion Element.=C2=B6









          

11.2.9.=C2=A0DocTypeExtension Element
          


name: DocTypeExtension=C2=B6


path: =
0*(\EBML\DocTypeExtension)=C2=B6


id 0x4281=C2=B6


minOccurs: 0=C2=B6


type: Master Element=C2=B6


description: A DocTypeExtension adds extra =
Elements to the main DocType+DocTypeVersion tuple it's attached to. An =
EBML Reader MAY know these extra Elements and how to use them. A =
DocTypeExtension MAY be used to iterate between experimental Elements =
before they are integrated in a regular DocTypeVersion. Reading one =
DocTypeExtension version of a DocType+DocTypeVersion tuple doesn't imply =
one should be able to read upper versions of this DocTypeExtension.=C2=B6









          

11.2.10.=C2=A0DocTypeExtensionName Element
          


name: DocTypeExtensionName=C2=B6


path: =
1*1(\EBML\DocTypeExtension\Name)=C2=B6


id 0x4283=C2=B6


minOccurs: 1=C2=B6


maxOccurs: 1=C2=B6


length: >0=C2=B6


type: String=C2=B6


description: The name of the =
DocTypeExtension to differentiate it from other DocTypeExtension of the =
same DocType+DocTypeVersion tuple. A DocTypeExtensionName value MUST be =
unique within the EBML Header.=C2=B6









          

11.2.11.=C2=A0DocTypeExtensionVersion Element
          


name: DocTypeExtensionVersion=C2=B6


path: =
1*1(\EBML\DocTypeExtension\Version)=C2=B6


id 0x4284=C2=B6


minOccurs: 1=C2=B6


maxOccurs: 1=C2=B6


range: not 0=C2=B6


type: Unsigned Integer=C2=B6


description: The version of the =
DocTypeExtension. Different DocTypeExtensionVersion values of the same =
DocType+DocTypeVersion+DocTypeExtensionName tuple MAY contain completely =
different sets of extra Elements. An EBML Reader MAY support multiple =
versions of the same DocTypeExtension, only one or none.=C2=B6













        

11.3.=C2=A0=
Global =
Elements
        


EBML allows some special Elements to be found =
within more than one parent in an EBML Document or optionally at the =
Root Level of an EBML Body. These Elements are called Global Elements. =
There are 2 Global Elements that can be found in any EBML Document: the =
CRC-32 Element and the Void Element. An EBML Schema MAY add other Global =
Elements to the format it defines. These extra elements apply only to =
the EBML Body, not the EBML Header.=C2=B6


Global Elements are EBML Elements whose path =
have a EBMLGlobalParent as their EBMLLastParent. Because it is the last =
Parent part of the path, a Global Element might also have =
non-EBMLGlobalParent parts in its path. In this case the Global Element =
can only be found within this non-EBMLGlobalParent path, i.e. it's not =
fully "global".=C2=B6

The EBMLEltOccurrence of a Global Element is =
the number of occurrences the Element can be found in a Parent Element. =
But the Global Element can be found in many Parent Elements, allowing =
the same number of occurrences in each Parent where this Element is =
found.=C2=B6





          

11.3.1.=C2=A0CRC-32 Element
          


name: CRC-32=C2=B6


path: *1((1*\)\CRC-32)=C2=B6


id: 0xBF=C2=B6


minOccurs: 0=C2=B6


maxOccurs: 1=C2=B6


length: 4=C2=B6


type: Binary=C2=B6


description: The CRC-32 Element contains a =
32-bit Cyclic Redundancy Check value of all the Element Data of the =
Parent Element as stored except for the CRC-32 Element itself. When the =
CRC-32 Element is present, the CRC-32 Element MUST be the first ordered =
EBML Element within its Parent Element for easier reading. All Top-Level =
Elements of an EBML Document that are Master Elements SHOULD include a =
CRC-32 Element as a Child Element. The CRC in use is the IEEE-CRC-32 =
algorithm as used in the [ISO.3309.1979] standard and in section =
8.1.1.6.2 of [ITU.V42.1994], with initial value of =
0xFFFFFFFF. The CRC value MUST be computed on a little endian bitstream =
and MUST use little endian storage.=C2=B6









          

11.3.2.=C2=A0Void Element
          


name: Void=C2=B6


path: *((*\)\Void)=C2=B6


id: 0xEC=C2=B6


minOccurs: 0=C2=B6


type: Binary=C2=B6


description: Used to void data or to avoid =
unexpected behaviors when using damaged data. The content is discarded. =
Also used to reserve space in a sub-element for later use.=C2=B6

















      

12.=C2=A0Considerations for Reading EBML Data
      


The following scenarios describe events to =
consider when reading EBML Documents and the recommended design of an =
EBML Reader.=C2=B6


If a Master Element contains a CRC-32 Element =
that doesn't validate, then the EBML Reader MAY ignore all contained =
data except for Descendant Elements that contain their own valid CRC-32 =
Element.=C2=B6


If a Master Element contains more occurrences of =
a Child Master Element than permitted according to the maxOccurs and =
recurring attributes of the definition of that Element then the =
occurrences in addition to maxOccurs MAY be ignored.=C2=B6


If a Master Element contains more occurrences of =
a Child Element than permitted according to the maxOccurs attribute of =
the definition of that Element then all instances of that Element after =
the first maxOccur occurrences from the beginning of its Parent Element =
SHOULD be ignored.=C2=B6








      

13.=C2=A0Terminating Elements
      


Null Octets, which are octets with all bits set =
to zero, MAY follow the value of a String Element or UTF-8 Element to =
serve as a terminator. An EBML Writer MAY terminate a String Element or =
UTF-8 Element with Null Octets in order to overwrite a stored value with =
a new value of lesser length while maintaining the same Element Data =
Size (this can prevent the need to rewrite large portions of an EBML =
Document); otherwise the use of Null Octets within a String Element or =
UTF-8 Element is NOT RECOMMENDED. An EBML Reader MUST consider the value =
of the String Element or UTF-8 Element to be terminated upon the first =
read Null Octet and MUST ignore any data following the first Null Octet =
within that Element. A string value and a copy of that string value =
terminated by one or more Null Octets are semantically equal.=C2=B6


The following table shows examples of semantics =
and validation for the use of Null Octets. Values to represent Stored =
Values and the Semantic Meaning as represented as hexadecimal values.=C2=B6



        Table =
10

          

            Stored =
Value
            Semantic =
Meaning
          

        
        
          

            0x65 =
0x62 0x6D 0x6C
            0x65 =
0x62 0x6D 0x6C
          

          

            0x65 =
0x62 0x00 0x6C
            0x65 =
0x62
          

          

            0x65 =
0x62 0x00 0x00
            0x65 =
0x62
          

          

            0x65 =
0x62
            0x65 =
0x62
          

        
      









      

14.=C2=A0Guidelines for Updating Elements
      


An EBML Document can be updated without requiring =
that the entire EBML Document be rewritten. These recommendations =
describe strategies to change the Element Data of a written EBML Element =
with minimal disruption to the rest of the EBML Document.=C2=B6





        

14.1.=C2=A0=
Reducing a Element Data in Size
        


There are three methods to reduce the size of =
Element Data of a written EBML Element.=C2=B6





          

14.1.1.=C2=A0Adding a Void Element
          


When an EBML Element is changed to reduce its =
total length by more than one octet, an EBML Writer SHOULD fill the =
freed space with a Void Element.=C2=B6









          

14.1.2.=C2=A0Extending the Element Data Size
          


The same value for Element Data Size MAY be =
written in variable lengths, so for minor reductions in octet length the =
Element Data Size MAY be written to a longer octet length to fill the =
freed space.=C2=B6
=


For example, the first row of the following =
table depicts a String Element that stores an Element ID (3 octets), =
Element Data Size (1 octet), and Element Data (4 octets). If the Element =
Data is changed to reduce the length by one octet and if the current =
length of the Element Data Size is less than its maximum permitted =
length, then the Element Data Size of that Element MAY be rewritten to =
increase its length by one octet. Thus before and after the change the =
EBML Element maintains the same length of 8 octets and data around the =
Element does not need to be moved.=C2=B6



            Table =
11

              

                Status
                Element ID
                Element Data Size
                Element Data
              

            
            
              

                Before=
 edit
                0x3B4040
                0x84
                0x65626D6C
              

              

                After =
edit
                0x3B4040
                0x4003
                0x6D6B76
              

            
          


This method is RECOMMENDED when the Element =
Data is reduced by a single octet; for reductions by two or more octets =
it is RECOMMENDED to fill the freed space with a Void Element.=C2=B6


Note that if the Element Data length needs to =
be rewritten as shortened by one octet and the Element Data Size could =
be rewritten as a shorter VINT then it is RECOMMENDED to rewrite the =
Element Data Size as one octet shorter, shorten the Element Data by one =
octet, and follow that Element with a Void Element. For example, the =
following table depicts a String Element that stores an Element ID (3 =
octets), Element Data Size (2 octets, but could be rewritten in one =
octet), and Element Data (3 octets). If the Element Data is to be =
rewritten to a two octet length, then another octet can be taken from =
Element Data Size so that there is enough space to add a two octet Void =
Element.=C2=B6



            Table =
12

              

                Status
                Element ID
                Element Data Size
                Element Data
                Void =
Element
              

            
            
              

                Before
                0x3B4040
                0x4003
                0x6D6B76
                
              

              

                After
                0x3B4040
                0x82
                0x6869
                0xEC80
              

            
          









          

14.1.3.=C2=A0Terminating Element Data
          


For String Elements and UTF-8 Elements the =
length of Element Data MAY be reduced by adding Null Octets to terminate =
the Element Data (see the section on =
Terminating Elements).=C2=B6


In the following table, a four octets long =
Element Data is changed to a three octet long value followed by a Null =
Octet; the Element Data Size includes any Null Octets used to terminate =
Element Data so remains unchanged.=C2=B6



            Table =
13

              

                Status
                Element ID
                Element Data Size
                Element Data
              

            
            
              

                Before=
 edit
                0x3B4040
                0x84
                0x65626D6C
              

              

                After =
edit
                0x3B4040
                0x84
                0x6D6B7600
              

            
          


Note that this method is NOT RECOMMENDED. For =
reductions of one octet, the method for Extending the Element Data Size =
SHOULD be used. For reduction by more than one octet, the method for =
Adding a Void Element SHOULD be used.=C2=B6













        

14.2.=C2=A0=
Considerations when Updating Elements with Cyclic Redundancy =
Check (CRC)
        


If the Element to be changed is a Descendant =
Element of any Master Element that contains a CRC-32 Element (see Section 11.3.1) then the =
CRC-32 Element MUST be verified before permitting the change. =
Additionally the CRC-32 Element value MUST be subsequently updated to =
reflect the changed data.=C2=B6













      

15.=C2=A0Backward and Forward Compatibility
      


Elements of an EBML format SHOULD be designed =
with backward and forward compatibility in mind.=C2=B6





        

15.1.=C2=A0=
Backward Compatibility
        


Backward compatibility of new EBML Elements can =
be achieved by using default values for mandatory elements. The default =
value MUST represent the state that was assumed for previous versions of =
the EBML Schema, without this new EBML Element. If such a state doesn't =
make sense for previous versions, then the new EBML Element SHOULD NOT =
be mandatory.=C2=B6


Non mandatory EBML Elements can be added in a =
new EBMLDocTypeVersion. Since they are not mandatory they won't be found =
in older versions of the EBMLDocTypeVersion, just as they might not be =
found in newer versions. This causes no compatibility issue.=C2=B6









        

15.2.=C2=A0=
Forward Compatibility
        


EBML Elements MAY be marked as deprecated in a =
new EBMLDocTypeVersion using the maxver attribute of the EBML Schema. If =
such an Element is found in an EBML Document with newer version of the =
EBMLDocTypeVersion it SHOULD be discarded.=C2=B6













      

16.=C2=A0Security Considerations
      


EBML itself does not offer any kind of security =
and does not provide confidentiality. EBML does not provide any kind of =
authorization. EBML only offers marginally useful and effective data =
integrity options, such as CRC elements.=C2=B6


Even if the semantic layer offers any kind of =
encryption, EBML itself could leak information at both the semantic =
layer (as declared via the DocType Element) and within the EBML =
structure (the presence of EBML Elements can be derived even with an =
unknown semantic layer using a heuristic approach; not without errors, =
of course, but with a certain degree of confidence).=C2=B6


An EBML Document that has the following issues =
may still be handled by the EBML Reader and the data accepted as such, =
depending on how strict the EBML Reader wants to be:=C2=B6


    

  • 
          
    Invalid Element IDs that are longer =
than the limit stated in the EBMLMaxIDLength Element of the EBML =
Header.=C2=B6
    

    • 
        
  • 
          
    Invalid Element IDs that are not =
encoded in the shortest-possible way.=C2=B6
    

    • 
        
  • 
          
    Invalid Element Data Size values =
that are longer than the limit stated in the EBMLMaxSizeLength Element =
of the EBML Header.=C2=B6
    

    • 
      


Element IDs that are unknown to the EBML Reader =
MAY be accepted as valid EBML IDs in order to skip such elements.=C2=B6


EBML Elements with a string type may contain =
extra data after the first 0x00. These data MUST be discarded according =
to the Section 13 =
rules.=C2=B6


An EBML Reader may discard some or all data if =
the following errors are found in the EBML Document:=C2=B6


    

  • 
          
    Invalid Element Data Size values =
(e.g. extending the length of the EBML Element beyond the scope of the =
Parent Element; possibly triggering access-out-of-bounds issues).=C2=B6
    

    • 
        
  • 
          
    Very high lengths in order to force =
out-of-memory situations resulting in a denial of service, =
access-out-of-bounds issues etc.=C2=B6
    

    • 
        
  • 
          
    Missing EBML Elements that are =
mandatory in a Master Element and have no declared default value, making =
the semantic invalid at that Master Element level.=C2=B6
    

    • 
        
  • 
          
    Usage of invalid UTF-8 encoding in =
EBML Elements of UTF-8 type (e.g. in order to trigger =
access-out-of-bounds or buffer overflow issues).=C2=B6
    

    • 
        
  • 
          
    Usage of invalid data in EBML =
Elements with a date type, triggering bogus date accesses.=C2=B6
    

    • 
      


Side channel attacks could exploit:=C2=B6


    

  • 
          
    The semantic equivalence of the =
same string stored in a String Element or UTF-8 Element with and without =
zero-bit padding, making comparison at the semantic level invalid.=C2=B6
    

    • 
        
  • 
          
    The semantic equivalence of =
VINT_DATA within Element Data Size with two different lengths due to =
left-padding zero bits, making comparison at the semantic level =
invalid.=C2=B6
    

    • 
        
  • 
          
    Data contained within a Master =
Element which is not itself part of a Child Element can trigger =
incorrect parsing behavior in EBML Readers.=C2=B6
    

    • 
        
  • 
          
    Extraneous copies of Identically =
Recurring Element, making parsing unnecessarily slow to the point of not =
being usable.=C2=B6

    • 
        
  • 
          
    Copies of Identically Recurring =
Element within a Parent Element that contain invalid CRC-32 Elements. =
EBML Readers not checking the CRC-32 might use the version of the =
element with mismatching CRC-32.=C2=B6
    

    • 
        
  • 
          
    Use of Void Elements which could =
be used to hide content or create bogus resynchronization points seen by =
some EBML Reader and not others.=C2=B6
    

    • 
      









      

17.=C2=A0IANA =
Considerations
      





        

17.1.=C2=A0=
CELLAR EBML Element ID Registry
        


This document creates a new IANA Registry =
called "CELLAR EBML Element ID Registry".=C2=B6


Element IDs are described in section Element =
ID. Element IDs are encoded using the VINT mechanism described in =
section Section 4 =
can be between one and five octets long. Five octet long Element IDs are =
possible only if declared in the header.=C2=B6


This IANA Registry only applies to Elements =
that can be contained in the EBML Header, thus including Global Elements. Elements only found in =
the EBML Body have their own set of independent Element IDs and are not =
part of this IANA Registry.=C2=B6


The VINT Data value of one-octet Element IDs =
MUST be between 0x01 and 0x7E. These items are valuable because they are =
short, and need to be used for commonly repeated elements. Values from 1 =
to 126 are to be allocated according to the "RFC Required" policy =
[RFC8126].=C2=B6


The VINT Data value of two-octet Element IDs =
MUST be between 0x007F and 0x3FFE. Numbers are to be allocated within =
this range according to the "Specification Required" policy [RFC8126].=C2=B6


The numbers 0x3FFF and 0x4000 are RESERVED.=C2=B6


The VINT Data value of three-octet Element IDs =
MUST be between 0x4001 and 0x1FFFFE. Numbers may be allocated within =
this range according to the "First Come First Served" policy [RFC8126].=C2=B6


The numbers 0x1FFFFF and 0x200000 are =
RESERVED.=C2=B6


Four-octet Element IDs are numbers between =
0x101FFFFF and 0x1FFFFFFE. Four-octet 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-octet Element IDs are =
split into two categories. Four-octet Element IDs whose lower three =
octets (as encoded) would make printable 7-bit ASCII values (0x20 to =
0x7E, inclusive) MUST be allocated by the "Specification Required" =
policy. Sequential allocation of values is not required: specifications =
SHOULD include a specific request, and are encouraged to do early =
allocations.=C2=B6


To be clear about the above category: =
four-octet Element IDs always start with hex 0x10 to 0x1F, and that =
octet may be chosen so that the entire number has some desirable =
property, such as a specific CRC. The other three octets, when ALL =
having values between 0x21 (33, ASCII !) and 0x7E (126, ASCII ~), fall =
into this category.=C2=B6


Other four-octet Element IDs may be allocated =
by the "First Come First Served" policy.=C2=B6


The numbers 0xFFFFFFF and 0x1000000 are =
RESERVED.=C2=B6


Five octet Element IDs (values from 0x10000001 =
upwards) are RESERVED according to the "Experimental Use" policy =
[RFC8126]: they may =
be used by anyone at any time, but there is no coordination.=C2=B6


ID Values found in this document are assigned =
as initial values as follows:=C2=B6

=

              

          Table =
14

            

              IDElement =
Name
              Reference
            

          
          
            

              0x1A45DFA3
              EBML
              Described in Section 11.2.1

            

            

              0x4286
              EBMLVersion
              Described in Section 11.2.2

            

            

              0x42F7
              EBMLReadVersion
              Described in Section 11.2.3

            

            

              0x42F2
              EBMLMaxIDLength
              Described in Section 11.2.4

            

            

              0x42F3
              EBMLMaxSizeLength
              Described in Section 11.2.5

            

            

              0x4282
              DocType
              Described in Section 11.2.6

            

            

              0x4287
              DocTypeVersion
              Described in Section 11.2.7

            

            

              0x4285
              DocTypeReadVersion
              Described in Section 11.2.8

            

            

              0x4281
              DocTypeExtension
              Described in Section 11.2.9

            

            

              0x4283
              DocTypeExtensionName
              Described in Section 11.2.10

            

            

              0x4284
              DocTypeExtensionVersion
              Described in Section 11.2.11

            

            

              0xBF
              CRC-32
              Described in Section 11.3.1

            

            

              0xEC
              Void
              Described in Section 11.3.2

            

          
        









        

17.2.=C2=A0=
CELLAR EBML DocType Registry
        


This document creates a new IANA Registry =
called "CELLAR EBML DocType Registry".=C2=B6


To register a new DocType in this registry one =
needs a DocType name, a Description of the DocType, a Change Controller =
(IESG or email of registrant) and an optional Reference to a document =
describing the DocType.=C2=B6


DocType values are described in this section. DocTypes are ASCII strings, defined =
in the String Element section, which =
label the official name of the EBML Document Type. The strings may be =
allocated according to the "First Come First Served" policy.=C2=B6


The use of ASCII corresponds to the types and =
code already in use, the value is not meant to be visible to the user.=C2=B6


DocType string values of "matroska" and "webm" =
are RESERVED to the IETF for future use.
These can be assigned via the "IESG Approval" or "RFC Required" policies =
[RFC8126].=C2=B6











      

18.=C2=A0Normative References
      




[IEEE.754.1985]

      

Institute of Electrical and Electronics =
Engineers, "Standard for Binary =
Floating-Point Arithmetic", . 


[ISO.3309.1979]

      

International Organization for =
Standardization, "Data communication - =
High-level data link control procedures - Frame structure", . 


[ISO.9899.2011]

      

International Organization for =
Standardization, "Programming languages =
- C", . 


[ITU.V42.1994]

      

International Telecommunications Union, =
"Error-correcting Procedures for DCEs Using =
Asynchronous-to-Synchronous Conversion", . 


[RFC0020]

      

Cerf, V., "ASCII=
 format for network interchange", STD =
80, RFC 20, DOI 10.17487/RFC0020, , <https://www.rfc-editor.org/=
info/rfc20>. 


[RFC2119]

      

Bradner, S., "Key words for use in RFCs to Indicate Requirement =
Levels", BCP 14, RFC 2119, DOI =
10.17487/RFC2119, , =
<https://www.rfc-editor.or=
g/info/rfc2119>. 


[RFC3339]

      

Klyne, G. and =
C. Newman, "Date and Time on the =
Internet: Timestamps", RFC =
3339, DOI 10.17487/RFC3339, =
, <https://www.rfc-editor.or=
g/info/rfc3339>. 


[RFC3629]

      

Yergeau, F., "UTF-8, a transformation format of ISO 10646", =
STD 63, RFC =
3629, DOI 10.17487/RFC3629, =
, <https://www.rfc-editor.or=
g/info/rfc3629>. 


[RFC5234]

      

Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: =
ABNF", STD 68, RFC 5234, DOI =
10.17487/RFC5234, , =
<https://www.rfc-editor.or=
g/info/rfc5234>. 


[RFC5646]

      

Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC =
5646, DOI 10.17487/RFC5646, =
, <https://www.rfc-editor.or=
g/info/rfc5646>. 


[RFC7405]

      

Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, DOI =
10.17487/RFC7405, , <https://www.rfc-editor.or=
g/info/rfc7405>. 


[RFC8126]

      

Cotton, M., =
Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations =
Section in RFCs", BCP 26, RFC 8126, DOI =
10.17487/RFC8126, , =
<https://www.rfc-editor.or=
g/info/rfc8126>. 


[RFC8174]

      

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key =
Words", BCP 14, RFC 8174, DOI =
10.17487/RFC8174, , =
<https://www.rfc-editor.or=
g/info/rfc8174>. 


[W3C.REC-xml-20081126]

      

Bray, T., =
Paoli, J., Sperberg-McQueen, =
M., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth =
Edition)", World Wide Web Consortium =
Recommendation REC-xml-20081126, , <http://www.w3.org/TR/2=
008/REC-xml-20081126>. 


[W3C.SPSD-xhtml-basic-20180327]

    

McCarron, S., "XHTML(tm) Basic 1.1 - Second Edition", . 







      

19.=C2=A0Informative References
      




[W3C.REC-xmlschema-0-20041028]

    

Fallside, D. =
and P. Walmsley, "XML Schema Part 0: =
Primer Second Edition", World Wide Web =
Consortium Recommendation REC-xmlschema-0-20041028, , <http://www.w3.=
org/TR/2004/REC-xmlschema-0-20041028>. 









      

Authors' Addresses
      



        
Steve Lhomme



Email:
slhomme@matroska.org






        
Dave Rice



Email:
dave@dericed.com






        
Moritz Bunkus



Email:
moritz@bunkus.org=













--Apple-Mail=_3CEF22D2-68BC-49E3-ABE9-E337F8FEA435
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii


--Apple-Mail=_3CEF22D2-68BC-49E3-ABE9-E337F8FEA435
Content-Disposition: attachment;
	filename=draft-ietf-cellar-ebml-12.txt
Content-Type: text/plain; x-unix-mode=0644;
 name="draft-ietf-cellar-ebml-12.txt"
Content-Transfer-Encoding: quoted-printable





cellar                                                         S. Lhomme
Internet-Draft                                                   D. Rice
Intended status: Standards Track                               M. Bunkus
Expires: 23 April 2020                                   21 October 2019


                    Extensible Binary Meta Language
                       draft-ietf-cellar-ebml-12

Abstract

   This document defines the Extensible Binary Meta Language (EBML)
   format as a generalized file format for any type of data in a
   hierarchical form.  EBML is designed as a binary equivalent to XML
   and uses a storage-efficient approach to build nested Elements with
   identifiers, lengths, and values.  Similar to how an XML Schema
   defines the structure and semantics of an XML Document, this document
   defines how EBML Schemas are created to convey the semantics of an
   EBML Document.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 23 April 2020.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Simplified BSD License text



Lhomme, et al.            Expires 23 April 2020                 [Page 1]
=0C
Internet-Draft                    EBML                      October 2019


   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Notation and Conventions  . . . . . . . . . . . . . . . . . .   4
   3.  Structure . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   4.  Variable Size Integer . . . . . . . . . . . . . . . . . . . .   7
     4.1.  VINT_WIDTH  . . . . . . . . . . . . . . . . . . . . . . .   7
     4.2.  VINT_MARKER . . . . . . . . . . . . . . . . . . . . . . .   7
     4.3.  VINT_DATA . . . . . . . . . . . . . . . . . . . . . . . .   8
     4.4.  VINT Examples . . . . . . . . . . . . . . . . . . . . . .   8
   5.  Element ID  . . . . . . . . . . . . . . . . . . . . . . . . .   9
   6.  Element Data Size . . . . . . . . . . . . . . . . . . . . . .  11
     6.1.  Data Size Format  . . . . . . . . . . . . . . . . . . . .  11
     6.2.  Unknown Data Size . . . . . . . . . . . . . . . . . . . .  11
     6.3.  Data Size Values  . . . . . . . . . . . . . . . . . . . .  14
   7.  EBML Element Types  . . . . . . . . . . . . . . . . . . . . .  15
     7.1.  Signed Integer Element  . . . . . . . . . . . . . . . . .  15
     7.2.  Unsigned Integer Element  . . . . . . . . . . . . . . . .  16
     7.3.  Float Element . . . . . . . . . . . . . . . . . . . . . .  16
     7.4.  String Element  . . . . . . . . . . . . . . . . . . . . .  16
     7.5.  UTF-8 Element . . . . . . . . . . . . . . . . . . . . . .  16
     7.6.  Date Element  . . . . . . . . . . . . . . . . . . . . . .  17
     7.7.  Master Element  . . . . . . . . . . . . . . . . . . . . .  17
     7.8.  Binary Element  . . . . . . . . . . . . . . . . . . . . .  17
   8.  EBML Document . . . . . . . . . . . . . . . . . . . . . . . .  18
     8.1.  EBML Header . . . . . . . . . . . . . . . . . . . . . . .  18
     8.2.  EBML Body . . . . . . . . . . . . . . . . . . . . . . . .  18
   9.  EBML Stream . . . . . . . . . . . . . . . . . . . . . . . . .  18
   10. EBML Versioning . . . . . . . . . . . . . . . . . . . . . . .  19
     10.1.  EBML Header Version  . . . . . . . . . . . . . . . . . .  19
     10.2.  EBML Document Version  . . . . . . . . . . . . . . . . .  19
   11. Elements semantic . . . . . . . . . . . . . . . . . . . . . .  19
     11.1.  EBML Schema  . . . . . . . . . . . . . . . . . . . . . .  19
       11.1.1.  EBML Schema Example  . . . . . . . . . . . . . . . .  20
       11.1.2.   Element . . . . . . . . . . . . . . . .  21
       11.1.3.   Attributes  . . . . . . . . . . . . . .  21
       11.1.4.   Element  . . . . . . . . . . . . . . . . .  22
       11.1.5.   Attributes . . . . . . . . . . . . . . . .  22
       11.1.6.   Element  . . . . . . . . . . . . . .  29
       11.1.7.   Attributes . . . . . . . . . . . . .  29
       11.1.8.   Element  . . . . . . . . . . .  29
       11.1.9.   Attributes . . . . . . . . . .  29
       11.1.10.  Element  . . . . . . . . . . . . . . .  30
       11.1.11.  Element . . . . . . . . . . . . . . . . . . .  30
       11.1.12.  Attributes  . . . . . . . . . . . . . . . . .  30



Lhomme, et al.            Expires 23 April 2020                 [Page 2]
=0C
Internet-Draft                    EBML                      October 2019


       11.1.13.  Element  . . . . . . . . . . . . . . . .  30
       11.1.14.  Attributes . . . . . . . . . . . . . . .  31
       11.1.15. XML Schema for EBML Schema . . . . . . . . . . . . .  31
       11.1.16. Identically Recurring Elements . . . . . . . . . . .  33
       11.1.17. Textual expression of floats . . . . . . . . . . . .  34
       11.1.18. Note on the use of default attributes to define
               Mandatory EBML Elements . . . . . . . . . . . . . . .  35
     11.2.  EBML Header Elements . . . . . . . . . . . . . . . . . .  35
       11.2.1.  EBML Element . . . . . . . . . . . . . . . . . . . .  36
       11.2.2.  EBMLVersion Element  . . . . . . . . . . . . . . . .  36
       11.2.3.  EBMLReadVersion Element  . . . . . . . . . . . . . .  36
       11.2.4.  EBMLMaxIDLength Element  . . . . . . . . . . . . . .  37
       11.2.5.  EBMLMaxSizeLength Element  . . . . . . . . . . . . .  37
       11.2.6.  DocType Element  . . . . . . . . . . . . . . . . . .  38
       11.2.7.  DocTypeVersion Element . . . . . . . . . . . . . . .  38
       11.2.8.  DocTypeReadVersion Element . . . . . . . . . . . . .  39
       11.2.9.  DocTypeExtension Element . . . . . . . . . . . . . .  39
       11.2.10. DocTypeExtensionName Element . . . . . . . . . . . .  40
       11.2.11. DocTypeExtensionVersion Element  . . . . . . . . . .  40
     11.3.  Global Elements  . . . . . . . . . . . . . . . . . . . .  41
       11.3.1.  CRC-32 Element . . . . . . . . . . . . . . . . . . .  41
       11.3.2.  Void Element . . . . . . . . . . . . . . . . . . . .  42
   12. Considerations for Reading EBML Data  . . . . . . . . . . . .  42
   13. Terminating Elements  . . . . . . . . . . . . . . . . . . . .  42
   14. Guidelines for Updating Elements  . . . . . . . . . . . . . .  43
     14.1.  Reducing a Element Data in Size  . . . . . . . . . . . .  43
       14.1.1.  Adding a Void Element  . . . . . . . . . . . . . . .  43
       14.1.2.  Extending the Element Data Size  . . . . . . . . . .  43
       14.1.3.  Terminating Element Data . . . . . . . . . . . . . .  45
     14.2.  Considerations when Updating Elements with Cyclic
            Redundancy Check (CRC) . . . . . . . . . . . . . . . . .  45
   15. Backward and Forward Compatibility  . . . . . . . . . . . . .  45
     15.1.  Backward Compatibility . . . . . . . . . . . . . . . . .  45
     15.2.  Forward Compatibility  . . . . . . . . . . . . . . . . .  46
   16. Security Considerations . . . . . . . . . . . . . . . . . . .  46
   17. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  47
     17.1.  CELLAR EBML Element ID Registry  . . . . . . . . . . . .  48
     17.2.  CELLAR EBML DocType Registry . . . . . . . . . . . . . .  51
   18. Normative References  . . . . . . . . . . . . . . . . . . . .  51
   19. Informative References  . . . . . . . . . . . . . . . . . . .  52
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  53

1.  Introduction

   EBML, short for Extensible Binary Meta Language, specifies a binary
   and octet (byte) aligned format inspired by the principle of XML (a
   framework for structuring data).




Lhomme, et al.            Expires 23 April 2020                 [Page 3]
=0C
Internet-Draft                    EBML                      October 2019


   The goal of this document is to define a generic, binary, space-
   efficient format that can be used to define more complex formats
   using an EBML Schema.  EBML is used by the multimedia container
   Matroska (https://github.com/Matroska-Org/matroska-specification/).
   The applicability of EBML for other use cases is beyond the scope of
   this document.

   The definition of the EBML format recognizes the idea behind HTML and
   XML as a good one: separate structure and semantics allowing the same
   structural layer to be used with multiple, possibly widely differing
   semantic layers.  Except for the EBML Header and a few Global
   Elements this specification does not define particular EBML format
   semantics; however this specification is intended to define how other
   EBML-based formats can be defined, such as the audio-video container
   formats Matroska and WebM.

   EBML uses a simple approach of building Elements upon three pieces of
   data (tag, length, and value) as this approach is well known, easy to
   parse, and allows selective data parsing.  The EBML structure
   additionally allows for hierarchical arrangement to support complex
   structural formats in an efficient manner.

   A typical EBML file has the following structure:

   EBML Header (master)
     + DocType (string)
     + DocTypeVersion (unsigned integer)
   EBML Body Root (master)
     + ElementA (utf-8)
     + Parent (master)
       + ElementB (integer)
     + Parent (master)
       + ElementB (integer)

2.  Notation and Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   This document defines specific terms in order to define the format
   and application of "EBML".  Specific terms are defined below:

   "EBML": Extensible Binary Meta Language





Lhomme, et al.            Expires 23 April 2020                 [Page 4]
=0C
Internet-Draft                    EBML                      October 2019


   "EBML Document Type": A name provided by an "EBML Schema" to
   designate a particular implementation of "EBML" for a data format
   (e.g.: matroska and webm).

   "EBML Schema": A standardized definition for the structure of an
   "EBML Document Type".

   "EBML Document": A datastream comprised of only two components, an
   "EBML Header" and an "EBML Body".

   "EBML Reader": A data parser that interprets the semantics of an
   "EBML Document" and creates a way for programs to use "EBML".

   "EBML Stream": A file that consists of one or more "EBML Documents"
   that are concatenated together.

   "EBML Header": A declaration that provides processing instructions
   and identification of the "EBML Body".  The "EBML Header" is
   analogous to an XML Declaration [W3C.REC-xml-20081126] (see section
   2.8 on Prolog and Document Type Declaration).

   "EBML Body": All data of an "EBML Document" following the "EBML
   Header".

   "Variable Size Integer": A compact variable-length binary value which
   defines its own length.

   "VINT": Also known as "Variable Size Integer".

   "EBML Element": A foundation block of data that contains three parts:
   an "Element ID", an "Element Data Size", and "Element Data".

   "Element ID": The "Element ID" is a binary value, encoded as a
   "Variable Size Integer", used to uniquely identify a defined "EBML
   Element" within a specific "EBML Schema".

   "EBML Class": A representation of the octet length of an "Element
   ID".

   "Element Data Size": An expression, encoded as a "Variable Size
   Integer", of the length in octets of "Element Data".

   "VINTMAX": The maximum possible value that can be stored as "Element
   Data Size".

   "Unknown-Sized Element": An "Element" with an unknown "Element Data
   Size".




Lhomme, et al.            Expires 23 April 2020                 [Page 5]
=0C
Internet-Draft                    EBML                      October 2019


   "Element Data": The value(s) of the "EBML Element" which is
   identified by its "Element ID" and "Element Data Size".  The form of
   the "Element Data" is defined by this document and the corresponding
   "EBML Schema" of the Element's "EBML Document Type".

   "Root Level": The starting level in the hierarchy of an "EBML
   Document".

   "Root Element": A mandatory, non-repeating "EBML Element" which
   occurs at the top level of the path hierarchy within an "EBML Body"
   and contains all other "EBML Elements" of the "EBML Body", excepting
   optional "Void Elements".

   "Top-Level Element": An "EBML Element" defined to only occur as a
   "Child Element" of the "Root Element".

   "Master Element": The "Master Element" contains zero, one, or many
   other "EBML Elements".

   "Child Element": A "Child Element" is a relative term to describe the
   "EBML Elements" immediately contained within a "Master Element".

   "Parent Element": A relative term to describe the "Master Element"
   which contains a specified element.  For any specified "EBML Element"
   that is not at "Root Level", the "Parent Element" refers to the
   "Master Element" in which that "EBML Element" is contained.

   "Descendant Element": A relative term to describe any "EBML Elements"
   contained within a "Master Element", including any of the "Child
   Elements" of its "Child Elements", and so on.

   "Void Element": A "Void Element" is an "Element" used to overwrite
   data or reserve space within a "Master Element" for later use.

   "Element Name": The human-readable name of the "EBML Element".

   "Element Path": The hierarchy of "Parent Element" where the "EBML
   Element" is expected to be found in the "EBML Body".

   "Empty Element": An "EBML Element" that has an "Element Data Size"
   with all "VINT_DATA" bits set to zero, which indicates that the
   "Element Data" of the "Element" is zero octets in length.









Lhomme, et al.            Expires 23 April 2020                 [Page 6]
=0C
Internet-Draft                    EBML                      October 2019


3.  Structure

   EBML uses a system of Elements to compose an EBML Document.  EBML
   Elements incorporate three parts: an Element ID, an Element Data
   Size, and Element Data.  The Element Data, which is described by the
   Element ID, includes either binary data, one or more other EBML
   Elements, or both.

4.  Variable Size Integer

   The Element ID and Element Data Size are both encoded as a Variable
   Size Integer.  The Variable Size Integer is composed of a VINT_WIDTH,
   VINT_MARKER, and VINT_DATA, in that order.  Variable Size Integers
   MUST left-pad the VINT_DATA value with zero bits so that the whole
   Variable Size Integer is octet-aligned.  Variable Size Integer will
   be referred to as VINT for shorthand.

4.1.  VINT_WIDTH

   Each Variable Size Integer begins with a VINT_WIDTH which consists of
   zero or many zero-value bits.  The count of consecutive zero-values
   of the VINT_WIDTH plus one equals the length in octets of the
   Variable Size Integer.  For example, a Variable Size Integer that
   starts with a VINT_WIDTH which contains zero consecutive zero-value
   bits is one octet in length and a Variable Size Integer that starts
   with one consecutive zero-value bit is two octets in length.  The
   VINT_WIDTH MUST only contain zero-value bits or be empty.

   Within the EBML Header the VINT_WIDTH of a VINT MUST NOT exceed three
   bits in length (meaning that the Variable Size Integer MUST NOT
   exceed four octets in length) except if said VINT is used to express
   the Element Data Size of an EBML Element with Element Name EBML and
   Element ID "0x1A45DFA3" (see the definition of the EBML Element
   (#ebml-element)) in which case the VINT_WIDTH MUST NOT exceed seven
   bits in length.  Within the EBML Body, when a VINT is used to express
   an Element ID, the maximum length allowed for the VINT_WIDTH is one
   less than the value set in the EBMLMaxIDLength Element.  Within the
   EBML Body, when a VINT is used to express an Element Data Size, the
   maximum length allowed for the VINT_WIDTH is one less than the value
   set in the EBMLMaxSizeLength Element.

4.2.  VINT_MARKER

   The VINT_MARKER serves as a separator between the VINT_WIDTH and
   VINT_DATA.  Each Variable Size Integer MUST contain exactly one
   VINT_MARKER.  The VINT_MARKER is one bit in length and contain a bit
   with a value of one.  The first bit with a value of one within the
   Variable Size Integer is the VINT_MARKER.



Lhomme, et al.            Expires 23 April 2020                 [Page 7]
=0C
Internet-Draft                    EBML                      October 2019


4.3.  VINT_DATA

   The VINT_DATA portion of the Variable Size Integer includes all data
   that follows (but not including) the VINT_MARKER until end of the
   Variable Size Integer whose length is derived from the VINT_WIDTH.
   The bits required for the VINT_WIDTH and the VINT_MARKER use one out
   of every eight bits of the total length of the Variable Size Integer.
   Thus a Variable Size Integer of 1 octet length supplies 7 bits for
   VINT_DATA, a 2 octet length supplies 14 bits for VINT_DATA, and a 3
   octet length supplies 21 bits for VINT_DATA.  If the number of bits
   required for VINT_DATA are less than the bit size of VINT_DATA, then
   VINT_DATA MUST be zero-padded to the left to a size that fits.  The
   VINT_DATA value MUST be expressed as a big-endian unsigned integer.

4.4.  VINT Examples

   This table shows examples of Variable Size Integers with lengths from
   1 to 5 octets.  The Usable Bits column refers to the number of bits
   that can be used in the VINT_DATA.  The Representation column depicts
   a binary expression of Variable Size Integers where VINT_WIDTH is
   depicted by "0", the VINT_MARKER as "1", and the VINT_DATA as "x".

      +--------------+-------------+-------------------------------+
      | Octet Length | Usable Bits | Representation                |
      +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
      | 1            | 7           | 1xxx xxxx                     |
      +--------------+-------------+-------------------------------+
      | 2            | 14          | 01xx xxxx xxxx xxxx           |
      +--------------+-------------+-------------------------------+
      | 3            | 21          | 001x xxxx xxxx xxxx xxxx xxxx |
      +--------------+-------------+-------------------------------+
      | 4            | 28          | 0001 xxxx xxxx xxxx xxxx xxxx |
      |              |             | xxxx xxxx                     |
      +--------------+-------------+-------------------------------+
      | 5            | 35          | 0000 1xxx xxxx xxxx xxxx xxxx |
      |              |             | xxxx xxxx xxxx xxxx           |
      +--------------+-------------+-------------------------------+

                                 Table 1

   Data encoded as a Variable Size Integer may be rendered at octet
   lengths larger than needed to store the data in order to facilitate
   overwriting it at a later date, e.g. when its final size isn't known
   in advance.  In this table a binary value of 0b10 is shown encoded as
   different Variable Size Integers with lengths from one octet to four
   octets.  All four encoded examples have identical semantic meaning
   though the VINT_WIDTH and the padding of the VINT_DATA vary.




Lhomme, et al.            Expires 23 April 2020                 [Page 8]
=0C
Internet-Draft                    EBML                      October 2019


          +--------------+--------------+-----------------------+
          | Binary Value | Octet Length | As Represented in     |
          |              |              | Variable Size Integer |
          +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D+
          | 10           | 1            | 1000 0010             |
          +--------------+--------------+-----------------------+
          | 10           | 2            | 0100 0000 0000 0010   |
          +--------------+--------------+-----------------------+
          | 10           | 3            | 0010 0000 0000 0000   |
          |              |              | 0000 0010             |
          +--------------+--------------+-----------------------+
          | 10           | 4            | 0001 0000 0000 0000   |
          |              |              | 0000 0000 0000 0010   |
          +--------------+--------------+-----------------------+

                                  Table 2

5.  Element ID

   The Element ID is encoded as a Variable Size Integer.  By default,
   Element IDs are encoded in lengths from one octet to four octets,
   although Element IDs of greater lengths MAY be used if the
   EBMLMaxIDLength Element of the EBML Header is set to a value greater
   than four (see the section on the EBMLMaxIDLength Element
   (#ebmlmaxidlength-element)).  The VINT_DATA component of the Element
   ID MUST NOT be either defined or written as either all zero values or
   all one values.  Any Element ID with the VINT_DATA component set as
   all zero values or all one values MUST be ignored.  The VINT_DATA
   component of the Element ID MUST be encoded at the shortest valid
   length.  For example, an Element ID with binary encoding of "1011
   1111" is valid, whereas an Element ID with binary encoding of "0100
   0000 0011 1111" stores a semantically equal VINT_DATA but is invalid
   because a shorter VINT encoding is possible.  Additionally, an
   Element ID with binary encoding of "1111 1111" is invalid since the
   VINT_DATA section is set to all one values, whereas an Element ID
   with binary encoding of "0100 0000 0111 1111" stores a semantically
   equal VINT_DATA and is the shortest possible VINT encoding.

   The following table details these specific examples further:












Lhomme, et al.            Expires 23 April 2020                 [Page 9]
=0C
Internet-Draft                    EBML                      October 2019


    +------------+-------------+----------------+--------------------+
    | VINT_WIDTH | VINT_MARKER |      VINT_DATA | Element ID Status  |
    +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
    |            |           1 |        0000000 | Invalid: VINT_DATA |
    |            |             |                | MUST NOT be set to |
    |            |             |                | all 0              |
    +------------+-------------+----------------+--------------------+
    |          0 |           1 | 00000000000000 | Invalid: VINT_DATA |
    |            |             |                | MUST NOT be set to |
    |            |             |                | all 0              |
    +------------+-------------+----------------+--------------------+
    |            |           1 |        0000001 | Valid              |
    +------------+-------------+----------------+--------------------+
    |          0 |           1 | 00000000000001 | Invalid: A shorter |
    |            |             |                | VINT_DATA encoding |
    |            |             |                | is available.      |
    +------------+-------------+----------------+--------------------+
    |            |           1 |        0111111 | Valid              |
    +------------+-------------+----------------+--------------------+
    |          0 |           1 | 00000000111111 | Invalid: A shorter |
    |            |             |                | VINT_DATA encoding |
    |            |             |                | is available.      |
    +------------+-------------+----------------+--------------------+
    |            |           1 |        1111111 | Invalid: VINT_DATA |
    |            |             |                | MUST NOT be set to |
    |            |             |                | all 1              |
    +------------+-------------+----------------+--------------------+
    |          0 |           1 | 00000001111111 | Valid              |
    +------------+-------------+----------------+--------------------+

                                 Table 3

   The octet length of an Element ID determines its EBML Class.

     +------------+--------+-------------------------+---------------+
     | EBML Class | Length |       Possible IDs      | Number of IDs |
     +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
     |  Class A   |   1    |       0x81 - 0xFE       |           126 |
     +------------+--------+-------------------------+---------------+
     |  Class B   |   2    |     0x407F - 0x7FFE     |        16,256 |
     +------------+--------+-------------------------+---------------+
     |  Class C   |   3    |   0x203FFF - 0x3FFFFE   |     2,080,768 |
     +------------+--------+-------------------------+---------------+
     |  Class D   |   4    | 0x101FFFFF - 0x1FFFFFFE |   268,338,304 |
     +------------+--------+-------------------------+---------------+

                                  Table 4




Lhomme, et al.            Expires 23 April 2020                [Page 10]
=0C
Internet-Draft                    EBML                      October 2019


6.  Element Data Size

6.1.  Data Size Format

   The Element Data Size expresses the length in octets of Element Data.
   The Element Data Size itself is encoded as a Variable Size Integer.
   By default, Element Data Sizes can be encoded in lengths from one
   octet to eight octets, although Element Data Sizes of greater lengths
   MAY be used if the octet length of the longest Element Data Size of
   the EBML Document is declared in the EBMLMaxSizeLength Element of the
   EBML Header (see the section on the EBMLMaxSizeLength Element
   (#ebmlmaxsizelength-element)).  Unlike the VINT_DATA of the Element
   ID, the VINT_DATA component of the Element Data Size is not mandated
   to be encoded at the shortest valid length.  For example, an Element
   Data Size with binary encoding of 1011 1111 or a binary encoding of
   0100 0000 0011 1111 are both valid Element Data Sizes and both store
   a semantically equal value (both 0b00000000111111 and 0b0111111, the
   VINT_DATA sections of the examples, represent the integer 63).

   Although an Element ID with all VINT_DATA bits set to zero is
   invalid, an Element Data Size with all VINT_DATA bits set to zero is
   allowed for EBML Element Types which do not mandate a non-zero length
   (see the section on EBML Element Types (#ebml-element-types)).  An
   Element Data Size with all VINT_DATA bits set to zero indicates that
   the Element Data is zero octets in length.  Such an EBML Element is
   referred to as an Empty Element.  If an Empty Element has a default
   value declared then the EBML Reader MUST interpret the value of the
   Empty Element as the default value.  If an Empty Element has no
   default value declared then the EBML Reader MUST use the value of the
   Empty Element for the corresponding EBML Element Type of the Element
   ID, 0 for numbers and an empty string for strings.

6.2.  Unknown Data Size

   An Element Data Size with all VINT_DATA bits set to one is reserved
   as an indicator that the size of the EBML Element is unknown.  The
   only reserved value for the VINT_DATA of Element Data Size is all
   bits set to one.  An EBML Element with an unknown Element Data Size
   is referred to as an Unknown-Sized Element.  A Master Element MAY be
   an Unknown-Sized Element; however an EBML Element that is not a
   Master Element MUST NOT be an Unknown-Sized Element.  Master Elements
   MUST NOT use an unknown size unless the unknownsizeallowed attribute
   of their EBML Schema is set to true (see the section on the
   unknownsizeallowed attribute (#unknownsizeallowed)).

   The use of Unknown-Sized Elements allows for an EBML Element to be
   written and read before the size of the EBML Element is known.
   Unknown-Sized Element MUST NOT be used or defined unnecessarily;



Lhomme, et al.            Expires 23 April 2020                [Page 11]
=0C
Internet-Draft                    EBML                      October 2019


   however if the Element Data Size is not known before the Element Data
   is written, such as in some cases of data streaming, then Unknown-
   Sized Elements MAY be used.  The end of an Unknown-Sized Element is
   determined by whichever comes first:

   *  Any EBML Element that is a valid Parent Element of the Unknown-
      Sized Element according to the EBML Schema, Global Elements
      (#global-elements) excluded.

   *  Any valid EBML Element according to the EBML Schema, Global
      Elements (#global-elements) excluded, that is not a Descendant
      Element of the Unknown-Sized Element but share a common direct
      parent, such as a Top-Level Element.

   *  Any EBML Element that is a valid Root Element according to the
      EBML Schema, Global Elements (#global-elements) excluded.

   *  The end of the Parent Element with a known size has been reached.

   *  The end of the EBML Document, either when reaching the end of the
      file or because a new EBML Header started.

   Consider an Unknown-Sized Element which EBML path is
   "\root\level1\level2\elt".  When reading a new Element ID, assuming
   the EBML Path of that new Element is valid, here are some possible
   and impossible ways that this new Element is ending "elt":

























Lhomme, et al.            Expires 23 April 2020                [Page 12]
=0C
Internet-Draft                    EBML                      October 2019


    +------------------------------------+----------------------------+
    | EBML Path of new element           | Status                     |
    +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
    | "\root\level1\level2"              | Ends the Unknown-Sized     |
    |                                    | Element, as it is a new    |
    |                                    | Parent Element             |
    +------------------------------------+----------------------------+
    | "\root\level1"                     | Ends the Unknown-Sized     |
    |                                    | Element, as it is a new    |
    |                                    | Parent Element             |
    +------------------------------------+----------------------------+
    | "\root"                            | Ends the Unknown-Sized     |
    |                                    | Element, as it is a new    |
    |                                    | Root Element               |
    +------------------------------------+----------------------------+
    | "\root2"                           | Ends the Unknown-Sized     |
    |                                    | Element, as it is a new    |
    |                                    | Root Element               |
    +------------------------------------+----------------------------+
    | "\root\level1\level2\other"        | Ends the Unknown-Sized     |
    |                                    | Element, as they share the |
    |                                    | same parent                |
    +------------------------------------+----------------------------+
    | "\root\level1\level2\elt"          | Ends the Unknown-Sized     |
    |                                    | Element, as they share the |
    |                                    | same parent                |
    +------------------------------------+----------------------------+
    | "\root\level1\level2\elt\inside"   | Doesn't end the Unknown-   |
    |                                    | Sized Element, it's a      |
    |                                    | child of "elt"             |
    +------------------------------------+----------------------------+
    | "\root\level1\level2\elt\" | Global Element is valid,   |
    |                                    | it's a child of "elt"      |
    +------------------------------------+----------------------------+
    | "\root\level1\level2\"     | Global Element cannot be   |
    |                                    | assumed to have this path, |
    |                                    | while parsing "elt" it can |
    |                                    | only be a child of "elt"   |
    +------------------------------------+----------------------------+

                                  Table 5










Lhomme, et al.            Expires 23 April 2020                [Page 13]
=0C
Internet-Draft                    EBML                      October 2019


6.3.  Data Size Values

   For Element Data Sizes encoded at octet lengths from one to eight,
   this table depicts the range of possible values that can be encoded
   as an Element Data Size.  An Element Data Size with an octet length
   of 8 is able to express a size of 2^56-2 or 72,057,594,037,927,934
   octets (or about 72 petabytes).  The maximum possible value that can
   be stored as Element Data Size is referred to as VINTMAX.

                  +--------------+----------------------+
                  | Octet Length | Possible Value Range |
                  +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
                  | 1            | 0 to 2^(7-2)         |
                  +--------------+----------------------+
                  | 2            | 0 to 2^(14-2)        |
                  +--------------+----------------------+
                  | 3            | 0 to 2^(21-2)        |
                  +--------------+----------------------+
                  | 4            | 0 to 2^(28-2)        |
                  +--------------+----------------------+
                  | 5            | 0 to 2^(35-2)        |
                  +--------------+----------------------+
                  | 6            | 0 to 2^(42-2)        |
                  +--------------+----------------------+
                  | 7            | 0 to 2^(49-2)        |
                  +--------------+----------------------+
                  | 8            | 0 to 2^(56-2)        |
                  +--------------+----------------------+

                                  Table 6

   If the length of Element Data equals 2^(n*7)-1 then the octet length
   of the Element Data Size MUST be at least n+1.  This rule prevents an
   Element Data Size from being expressed as the unknown size value.
   The following table clarifies this rule by showing a valid and
   invalid expression of an Element Data Size with a VINT_DATA of 127
   (which is equal to 2^(1*7)-1) and 16,383 (which is equal to 2^((2*7)-
   1).)













Lhomme, et al.            Expires 23 April 2020                [Page 14]
=0C
Internet-Draft                    EBML                      October 2019


    +------------+-------------+-----------------------+--------------+
    | VINT_WIDTH | VINT_MARKER |             VINT_DATA | Element Data |
    |            |             |                       | Size Status  |
    +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
    |            |           1 |               1111111 | Reserved     |
    |            |             |                       | (meaning     |
    |            |             |                       | Unknown)     |
    +------------+-------------+-----------------------+--------------+
    |          0 |           1 |        00000001111111 | Valid        |
    |            |             |                       | (meaning 127 |
    |            |             |                       | octets)      |
    +------------+-------------+-----------------------+--------------+
    |         00 |           1 | 000000000000001111111 | Valid        |
    |            |             |                       | (meaning 127 |
    |            |             |                       | octets)      |
    +------------+-------------+-----------------------+--------------+
    |          0 |           1 |        11111111111111 | Reserved     |
    |            |             |                       | (meaning     |
    |            |             |                       | Unknown)     |
    +------------+-------------+-----------------------+--------------+
    |         00 |           1 | 000000011111111111111 | Valid        |
    |            |             |                       | (16,383      |
    |            |             |                       | octets)      |
    +------------+-------------+-----------------------+--------------+

                                  Table 7

7.  EBML Element Types

   EBML Elements are defined by an EBML Schema (see Section 11.1) which
   MUST declare one of the following EBML Element Types for each EBML
   Element.  An EBML Element Type defines a concept of storing data
   within an EBML Element that describes such characteristics as length,
   endianness, and definition.

   EBML Elements which are defined as a Signed Integer Element, Unsigned
   Integer Element, Float Element, or Date Element use big endian
   storage.

7.1.  Signed Integer Element

   A Signed Integer Element MUST declare a length from zero to eight
   octets.  If the EBML Element is not defined to have a default value,
   then a Signed Integer Element with a zero-octet length represents an
   integer value of zero.

   A Signed Integer Element stores an integer (meaning that it can be
   written without a fractional component) which could be negative,



Lhomme, et al.            Expires 23 April 2020                [Page 15]
=0C
Internet-Draft                    EBML                      October 2019


   positive, or zero.  Signed Integers are stored with two's complement
   notation with the leftmost bit being the sign bit.  Because EBML
   limits Signed Integers to 8 octets in length a Signed Integer Element
   stores a number from -9,223,372,036,854,775,808 to
   +9,223,372,036,854,775,807.

7.2.  Unsigned Integer Element

   An Unsigned Integer Element MUST declare a length from zero to eight
   octets.  If the EBML Element is not defined to have a default value,
   then an Unsigned Integer Element with a zero-octet length represents
   an integer value of zero.

   An Unsigned Integer Element stores an integer (meaning that it can be
   written without a fractional component) which could be positive or
   zero.  Because EBML limits Unsigned Integers to 8 octets in length an
   Unsigned Integer Element stores a number from 0 to
   18,446,744,073,709,551,615.

7.3.  Float Element

   A Float Element MUST declare a length of either zero octet (0 bit),
   four octets (32 bit) or eight octets (64 bit).  If the EBML Element
   is not defined to have a default value, then a Float Element with a
   zero-octet length represents a numerical value of zero.

   A Float Element stores a floating-point number as defined in
   [IEEE.754.1985].

7.4.  String Element

   A String Element MUST declare a length in octets from zero to
   VINTMAX.  If the EBML Element is not defined to have a default value,
   then a String Element with a zero-octet length represents an empty
   string.

   A String Element MUST either be empty (zero-length) or contain
   printable ASCII characters [RFC0020] in the range of 0x20 to 0x7E,
   with an exception made for termination (see the section on the
   Terminating Elements (#terminating-elements)).

7.5.  UTF-8 Element

   A UTF-8 Element MUST declare a length in octets from zero to VINTMAX.
   If the EBML Element is not defined to have a default value, then a
   UTF-8 Element with a zero-octet length represents an empty string.





Lhomme, et al.            Expires 23 April 2020                [Page 16]
=0C
Internet-Draft                    EBML                      October 2019


   A UTF-8 Element contains only a valid Unicode string as defined in
   [RFC3629], with an exception made for termination (see the section on
   the Terminating Elements (#terminating-elements)).

7.6.  Date Element

   A Date Element MUST declare a length of either zero octets or eight
   octets.  If the EBML Element is not defined to have a default value,
   then a Date Element with a zero-octet length represents a timestamp
   of 2001-01-01T00:00:00.000000000 UTC [RFC3339].

   The Date Element stores an integer in the same format as the Signed
   Integer Element that expresses a point in time referenced in
   nanoseconds from the precise beginning of the third millennium of the
   Gregorian Calendar in Coordinated Universal Time (also known as
   2001-01-01T00:00:00.000000000 UTC).  This provides a possible
   expression of time from 1708-09-11T00:12:44.854775808 UTC to
   2293-04-11T11:47:16.854775807 UTC.

7.7.  Master Element

   A Master Element MUST declare a length in octets from zero to
   VINTMAX.  The Master Element MAY also use an unknown length.  See the
   section on Element Data Size (#element-data-size) for rules that
   apply to elements of unknown length.

   The Master Element contains zero, one, or many other elements.  EBML
   Elements contained within a Master Element MUST have the
   EBMLParentPath of their Element Path equal to the EBMLMasterPath of
   the Master Element Element Path (see the section on the EBML Path
   (#path)).  Element Data stored within Master Elements SHOULD only
   consist of EBML Elements and SHOULD NOT contain any data that is not
   part of an EBML Element.  The EBML Schema identifies what Element IDs
   are valid within the Master Elements for that version of the EBML
   Document Type.  Any data contained within a Master Element that is
   not part of a Child Element MUST be ignored.

7.8.  Binary Element

   A Binary Element MUST declare a length in octets from zero to
   VINTMAX.

   The contents of a Binary Element should not be interpreted by the
   EBML Reader.







Lhomme, et al.            Expires 23 April 2020                [Page 17]
=0C
Internet-Draft                    EBML                      October 2019


8.  EBML Document

   An EBML Document is comprised of only two components, an EBML Header
   and an EBML Body.  An EBML Document MUST start with an EBML Header
   that declares significant characteristics of the entire EBML Body.
   An EBML Document consists of EBML Elements and MUST NOT contain any
   data that is not part of an EBML Element.

8.1.  EBML Header

   The EBML Header is a declaration that provides processing
   instructions and identification of the EBML Body.  The EBML Header of
   an EBML Document is analogous to the XML Declaration of an XML
   Document.

   The EBML Header documents the EBML Schema (also known as the EBML
   DocType) that is used to semantically interpret the structure and
   meaning of the EBML Document.  Additionally the EBML Header documents
   the versions of both EBML and the EBML Schema that were used to write
   the EBML Document and the versions required to read the EBML
   Document.

   The EBML Header MUST contain a single Master Element with an Element
   Name of EBML and Element ID of 0x1A45DFA3 (see the definition of the
   EBML Element (#ebml-element)) and any number of additional EBML
   Elements within it.  The EBML Header of an EBML Document that uses an
   EBMLVersion of 1 MUST only contain EBML Elements that are defined as
   part of this document.

8.2.  EBML Body

   All data of an EBML Document following the EBML Header is the EBML
   Body.  The end of the EBML Body, as well as the end of the EBML
   Document that contains the EBML Body, is reached at whichever comes
   first: the beginning of a new EBML Header at the Root Level or the
   end of the file.  The EBML Body MUST NOT contain any data that is not
   part of an EBML Element.  This document defines precisely which EBML
   Elements are to be used within the EBML Header, but does not name or
   define which EBML Elements are to be used within the EBML Body.  The
   definition of which EBML Elements are to be used within the EBML Body
   is defined by an EBML Schema.

9.  EBML Stream

   An EBML Stream is a file that consists of one or more EBML Documents
   that are concatenated together.  An occurrence of a EBML Header at
   the Root Level marks the beginning of an EBML Document.




Lhomme, et al.            Expires 23 April 2020                [Page 18]
=0C
Internet-Draft                    EBML                      October 2019


10.  EBML Versioning

   An EBML Document handles 2 different versions: the version of the
   EBML Header and the version of the EBML Body.  Both versions are
   meant to be backward compatible.

10.1.  EBML Header Version

   The version of the EBML Header is found in EBMLVersion.  An EBML
   parser can read an EBML Header if it can read either the EBMLVersion
   version or a version equal or higher than the one found in
   EBMLReadVersion.

10.2.  EBML Document Version

   The version of the EBML Body is found in EBMLDocTypeVersion.  A
   parser for the particular DocType format can read the EBML Document
   if it can read either the EBMLDocTypeVersion version of that format
   or a version equal or higher than the one found in
   EBMLDocTypeReadVersion.

11.  Elements semantic

11.1.  EBML Schema

   An EBML Schema is a well-formed XML Document [W3C.REC-xml-20081126]
   that defines the properties, arrangement, and usage of EBML Elements
   that compose a specific EBML Document Type.  The relationship of an
   EBML Schema to an EBML Document is analogous to the relationship of
   an XML Schema [W3C.REC-xmlschema-0-20041028] to an XML Document
   [W3C.REC-xml-20081126].  An EBML Schema MUST be clearly associated
   with one or more EBML Document Types.  An EBML Document Type is
   identified by a string stored within the EBML Header in the DocType
   Element; for example matroska or webm (see the definition of the
   DocType Element (#doctype-element)).  The DocType value for an EBML
   Document Type MUST be unique and persistent.

   An EBML Schema MUST declare exactly one EBML Element at Root Level
   (referred to as the Root Element) that occurs exactly once within an
   EBML Document.  The Void Element MAY also occur at Root Level but is
   not a Root Element (see the definition of the Void Element (#void-
   element)).

   The EBML Schema MUST document all Elements of the EBML Body.  The
   EBML Schema does not document Global Elements (#global-elements) that
   are defined by this document (namely the Void Element and the CRC-32
   Element).




Lhomme, et al.            Expires 23 April 2020                [Page 19]
=0C
Internet-Draft                    EBML                      October 2019


   The EBML Schema MUST NOT use the Element ID "0x1A45DFA3" which is
   reserved for the EBML Header for resynchronization purpose.

   An EBML Schema MAY constrain the use of EBML Header Elements (see
   EBML Header Elements (#ebml-header-elements)) by adding or
   constraining that Element's "range" attribute.  For example, an EBML
   Schema MAY constrain the EBMLMaxSizeLength to a maximum value of "8"
   or MAY constrain the EBMLVersion to only support a value of "1".  If
   an EBML Schema adopts the EBML Header Element as-is, then it is not
   required to document that Element within the EBML Schema.  If an EBML
   Schema constrains the range of an EBML Header Element, then that
   Element MUST be documented within an "" node of the EBML
   Schema.  This document provides an example of an EBML Schema, see
   EBML Schema Example (#ebml-schema-example).

11.1.1.  EBML Schema Example

   
   
    
    
    
    
    
     Container of data =
and
     attributes representing one or many files.
    
    
     
       An attached file.
     
    
    
     
       Filename of the attached file.
     
    
    
     
       MIME type of the file.
     
    
    
     
       Modification timestamp of the file.
     
    
    
     
       The data of the file.
     
    
   

11.1.2.   Element

   As an XML Document, the EBML Schema MUST use "" as the
   top level element.  The "" element can contain
   "" sub-elements.

11.1.3.   Attributes

   Within an EBML Schema the "" element uses the following
   attributes:

11.1.3.1.  docType

   The docType lists the official name of the EBML Document Type that is
   defined by the EBML Schema; for example, "".

   The docType attribute is REQUIRED within the "" Element.

11.1.3.2.  version

   The version lists a non-negative integer that specifies the version
   of the docType documented by the EBML Schema.  Unlike XML Schemas, an
   EBML Schema documents all versions of a docType's definition rather
   than using separate EBML Schemas for each version of a docType.  EBML
   Elements may be introduced and deprecated by using the minver and
   maxver attributes of "".




Lhomme, et al.            Expires 23 April 2020                [Page 21]
=0C
Internet-Draft                    EBML                      October 2019


   The version attribute is REQUIRED within the "" Element.

11.1.4.   Element

   Each "" defines one EBML Element through the use of several
   attributes that are defined in EBML Schema Element Attributes
   (#ebmlschema-attributes).  EBML Schemas MAY contain additional
   attributes to extend the semantics but MUST NOT conflict with the
   definitions of the "" attributes defined within this
   document.

   The "" nodes contain a description of the meaning and use of
   the EBML Element stored within one or more "" sub-
   elements, followed by optional "" sub-elements,
   followed by zero or one "" sub-element, followed by
   optional "" sub-elements.  All "" nodes MUST be
   sub-elements of the "".

11.1.5.   Attributes

   Within an EBML Schema the "" uses the following attributes
   to define an EBML Element:

11.1.5.1.  name

   The name provides the human-readable name of the EBML Element.  The
   value of the name MUST be in the form of characters "A" to "Z", "a"
   to "z", "0" to "9", "-" and ".".

   The name attribute is REQUIRED.

11.1.5.2.  path

   The path defines the allowed storage locations of the EBML Element
   within an EBML Document.  This path MUST be defined with the full
   hierarchy of EBML Elements separated with a "\".  The top EBML
   Element in the path hierarchy being the first in the value.  The
   syntax of the path attribute is defined using this Augmented Backus-
   Naur Form (ABNF) [RFC5234] with the case sensitive update [RFC7405]
   notation:

   The path attribute is REQUIRED.









Lhomme, et al.            Expires 23 April 2020                [Page 22]
=0C
Internet-Draft                    EBML                      October 2019


   EBMLFullPath             =3D EBMLEltOccurrence "(" EBMLMasterPath ")"
   EBMLMasterPath           =3D [EBMLParentPath] EBMLElementPath
   EBMLParentPath           =3D EBMLFixedParent EBMLLastParent
   EBMLFixedParent          =3D *(EBMLPathAtom)
   EBMLElementPath          =3D EBMLPathAtom / EBMLPathAtomRecursive
   EBMLPathAtom             =3D PathDelimiter EBMLAtomName
   EBMLPathAtomRecursive    =3D "(1*(" EBMLPathAtom "))"
   EBMLLastParent           =3D EBMLPathAtom / EBMLGlobalParent
   EBMLGlobalParent         =3D "(" GlobalParentOccurence "\)"
   EBMLAtomName             =3D 1*(EBMLNameChar)
   EBMLNameChar             =3D ALPHA / DIGIT / "-" / "."
   PathDelimiter            =3D "\"
   EBMLEltOccurrence        =3D [EBMLMinOccurrence] "*" =
[EBMLMaxOccurrence]
   EBMLMinOccurrence        =3D 1*DIGIT ; no upper limit
   EBMLMaxOccurrence        =3D 1*DIGIT ; no upper limit
   GlobalParentOccurence    =3D [PathMinOccurrence] "*" =
[PathMaxOccurrence]
   PathMinOccurrence        =3D 1*DIGIT ; no upper limit
   PathMaxOccurrence        =3D 1*DIGIT ; no upper limit

   The "*", "(" and ")" symbols are interpreted as defined in [RFC5234].

   The EBMLPathAtom part of the EBMLElementPath MUST be equal to the
   name attribute of the EBML Schema.

   The starting PathDelimiter of the path corresponds to the root of the
   EBML Document.

   The EBMLEltOccurrence part is interpreted as an ABNF Variable
   Repetition.  The repetition amounts correspond to how many times the
   EBML Element can be found in its Parent Element.

   The EBMLMinOccurrence represents the minimum permitted number of
   occurrences of this EBML Element within its Parent Element.  Each
   instance of the Parent Element MUST contain at least this many
   instances of this EBML Element.  If the EBML Element has an empty
   EBMLParentPath then EBMLMinOccurrence refers to constraints on the
   occurrence of the EBML Element within the EBML Document.  If
   EBMLMinOccurrence is not present then that EBML Element has an
   EBMLMinOccurrence value of 0.  The semantic meaning of
   EBMLMinOccurrence within an EBML Schema is analogous to the meaning
   of minOccurs within an XML Schema.  EBML Elements with
   EBMLMinOccurrence set to "1" that also have a default value (see
   default (#default)) declared are not REQUIRED to be stored but are
   REQUIRED to be interpreted, see Note on the Use of default attributes
   to define Mandatory EBML Elements (#note-on-the-use-of-default-
   attributes-to-define-mandatory-ebml-elements).  An EBML Element
   defined with a EBMLMinOccurrence value greater than zero is called a
   Mandatory EBML Element.



Lhomme, et al.            Expires 23 April 2020                [Page 23]
=0C
Internet-Draft                    EBML                      October 2019


   The EBMLMaxOccurrence represents the maximum permitted number of
   occurrences of this EBML Element within its Parent Element.  Each
   instance of the Parent Element MUST contain at most this many
   instances of this EBML Element.  If the EBML Element has an empty
   EBMLParentPath then EBMLMaxOccurrence refers to constraints on the
   occurrence of the EBML Element within the EBML Document.  If
   EBMLMaxOccurrence is not present then there is no upper bound for the
   permitted number of occurrences of this EBML Element within its
   Parent Element resp. within the EBML Document depending on whether
   the EBMLParentPath of the EBML Element is empty or not.  The semantic
   meaning of EBMLMaxOccurrence within an EBML Schema path is analogous
   to the meaning of maxOccurs within an XML Schema.

   In some cases the EBMLLastParent part of the path is an
   EBMLGlobalParent.  A path with a EBMLGlobalParent defines a Global
   Element (#global-elements).  Any path that starts with the
   EBMLFixedParent of the Global Element and matches the occurrences
   found in the GlobalParentOccurence is a valid path for the Global
   Element.

   The GlobalParentOccurence part is interpreted as an ABNF Variable
   Repetition.  The repetition amounts correspond to the amount of
   unspecified Parent Element levels there can be between the
   EBMLFixedParent and the actual EBMLElementPath.

   PathMinOccurrence represents the minimum number of element path
   required between the EBMLFixedParent and the Global Element
   EBMLElementPath.  For example 0 means the EBMLElementPath can be
   right after the EBMLFixedParent, 1 means there has to be at least an
   element between the EBMLFixedParent and the EBMLElementPath.  If
   PathMinOccurrence is not present then that EBML Element has an
   PathMinOccurrence value of 0.

   PathMaxOccurrence represents the maximum number of element path
   possible between the EBMLFixedParent and the Global Element
   EBMLElementPath.  It cannot have the value 0 as it would be the
   Global Element can only be found right after the EBMLFixedParent, in
   which case it's not a Global Element anymore.  If PathMaxOccurrence
   is not present then there is no upper bound for the permitted number
   of occurrences of element path possible between the EBMLFixedParent
   and the Global Element EBMLElementPath.

   If the path contains an EBMLPathAtomRecursive part, the EBML Element
   can occur within itself recursively (see the recursive attribute
   (#recursive)).

   As an example, a "path" of "1*(\Segment\Info)" means the element Info
   is found inside the Segment elements at least once and with no



Lhomme, et al.            Expires 23 April 2020                [Page 24]
=0C
Internet-Draft                    EBML                      October 2019


   maximum iteration.  An element SeekHead with path
   "0*2(\Segment\SeekHead)" may not be found at all in its Segment
   parent, once or twice but no more than that.

11.1.5.3.  id

   The Element ID encoded as a Variable Size Integer expressed in
   hexadecimal notation prefixed by a 0x that is read and stored in big-
   endian order.  To reduce the risk of false positives while parsing
   EBML Streams, the Element IDs of the Root Element and Top-Level
   Elements SHOULD be at least 4 octets in length.  Element IDs defined
   for use at Root Level or directly under the Root Level MAY use
   shorter octet lengths to facilitate padding and optimize edits to
   EBML Documents; for instance, the Void Element uses an Element ID
   with a one octet length to allow its usage in more writing and
   editing scenarios.

   The id attribute is REQUIRED.

11.1.5.4.  minOccurs

   An integer expressing the minimum permitted number of occurrences of
   this EBML Element within its Parent Element.  The minOccurs value
   MUST be equal to the EBMLMinOccurrence value of the path.

   The minOccurs attribute is OPTIONAL.  If the minOccurs attribute is
   not present then that EBML Element has a minOccurs value of 0.

11.1.5.5.  maxOccurs

   An integer expressing the maximum permitted number of occurrences of
   this EBML Element within its Parent Element.  The maxOccurs value
   MUST be equal to the EBMLMaxOccurrence value of the path.

   The maxOccurs attribute is OPTIONAL.  If the maxOccurs attribute is
   not present then that EBML Element has no maximum occurrence, similar
   to unbounded in the XML world.

11.1.5.6.  range

   A numerical range for EBML Elements which are of numerical types
   (Unsigned Integer, Signed Integer, Float, and Date).  If specified
   the value of the EBML Element MUST be within the defined range.  See
   section of Expressions of range (#expression-of-range) for rules
   applied to expression of range values.

   The range attribute is OPTIONAL.  If the range attribute is not
   present then any value legal for the type attribute is valid.



Lhomme, et al.            Expires 23 April 2020                [Page 25]
=0C
Internet-Draft                    EBML                      October 2019


11.1.5.6.1.  Expression of range

   The range attribute MUST only be used with EBML Elements that are
   either signed integer, unsigned integer, float, or date.  The
   expression defines the upper, lower, exact or excluded value of the
   EBML Element and optionally an upper boundary value combined with a
   lower boundary.  The range expression may contain whitespace (using
   the ASCII 0x20 character) for readability but whitespace within a
   range expression MUST NOT convey meaning.

   To set a fixed value for the range, the value is used as the
   attribute value.  For example "1234" means the EBML element always
   has the value 1234.  The value can be prefixed with "not" to indicate
   that the fixed value MUST NOT be used for that Element.  For example
   "not 1234" means the Element can use all values of its type except
   1234.

   For an exclusive lower boundary the ">" sign is used and the ">=3D"
   sign is used for an inclusive lower boundary.  For example ">3"
   meaning the Element value MUST be greater than 3 or ">=3D0x1p+0"
   meaning the Element value MUST be greater than or equal to the
   floating value 1.0, see textual expression of floats (#textual-
   expression-of-floats).

   For an exclusive upper boundary the "<" sign is used and the "<=3D"
   sign is used for an inclusive upper boundary.  For example "<-2"
   meaning the Element value MUST be less than -2 or "<=3D10" meaning =
the
   Element value MUST be less than or equal to the 10.

   The lower and upper bounds can be combined into an expression to form
   a closed boundary.  The lower boundary coming first followed by the
   upper boundary, separated by a comma.  For example ">3,<=3D 20" means
   the Element value MUST be greater than 3 and less than or equal to
   20.

   A special form of lower and upper bounds using the "-" separator is
   possible, meaning the Element value MUST be greater than or to the
   first value and MUST be less than or equal to the second value.  For
   example "1-10" is equivalent to ">=3D1,<=3D10".  If the upper =
boundary is
   negative, only the latter form MUST be used.











Lhomme, et al.            Expires 23 April 2020                [Page 26]
=0C
Internet-Draft                    EBML                      October 2019


11.1.5.7.  length

   A value to express the valid length of the Element Data as written
   measured in octets.  The length provides a constraint in addition to
   the Length value of the definition of the corresponding EBML Element
   Type.  This length MUST be expressed as either a non-negative integer
   or a range (see expression of range (#expression-of-range)) that
   consists of only non-negative integers and valid operators.

   The length attribute is OPTIONAL.  If the length attribute is not
   present for that EBML Element then that EBML Element is only limited
   in length by the definition of the associated EBML Element Type.

11.1.5.8.  default

   If an Element is mandatory (has a EBMLMinOccurrence value greater
   than zero) but not written within its Parent Element or stored as an
   Empty Element, then the EBML Reader of the EBML Document MUST
   semantically interpret the EBML Element as present with this
   specified default value for the EBML Element.  EBML Elements that are
   Master Elements MUST NOT declare a default value.  EBML Elements with
   a minOccurs value greater than 1 MUST NOT declare a default value.

   The default attribute is OPTIONAL.

11.1.5.9.  type

   The type MUST be set to one of the following values: "integer"
   (signed integer), "uinteger" (unsigned integer), "float", "string",
   "date", "utf-8", "master", or "binary".  The content of each type is
   defined within section on EBML Element Types (#ebml-element-types).

   The type attribute is REQUIRED.

11.1.5.10.  unknownsizeallowed

   A boolean to express if an EBML Element is permitted to be Unknown-
   Sized Element (having all VINT_DATA bits of Element Data Size set to
   1).  EBML Elements that are not Master Elements MUST NOT set
   unknownsizeallowed to true.  An EBML Element that is defined with an
   unknownsizeallowed attribute set to 1 MUST also have the
   unknownsizeallowed attribute of its Parent Element set to 1.

   An EBML Element with the unknownsizeallowed attribute set to 1 MUST
   NOT have its recursive attribute set to 1.

   The unknownsizeallowed attribute is OPTIONAL.  If the




Lhomme, et al.            Expires 23 April 2020                [Page 27]
=0C
Internet-Draft                    EBML                      October 2019


   unknownsizeallowed attribute is not used then that EBML Element is
   not allowed to use an unknown Element Data Size.

11.1.5.11.  recursive

   A boolean to express if an EBML Element is permitted to be stored
   recursively.  In this case the EBML Element MAY be stored within
   another EBML Element that has the same Element ID.  Which itself can
   be stored in an EBML Element that has the same Element ID, and so on.
   EBML Elements that are not Master Elements MUST NOT set recursive to
   true.

   If the path contains an EBMLPathAtomRecursive part then the recursive
   value MUST be true and false otherwise.

   An EBML Element with the recursive attribute set to 1 MUST NOT have
   its unknownsizeallowed attribute set to 1.

   The recursive attribute is OPTIONAL.  If the recursive attribute is
   not present then the EBML Element MUST NOT be used recursively.

11.1.5.12.  recurring

   A boolean to express if an EBML Element is defined as an Identically
   Recurring Element or not.

   The recurring attribute is OPTIONAL.  If the recurring attribute is
   not present then the EBML Element is not an Identically Recurring
   Element.

11.1.5.13.  minver

   The minver (minimum version) attribute stores a non-negative integer
   that represents the first version of the docType to support the EBML
   Element.

   The minver attribute is OPTIONAL.  If the minver attribute is not
   present, then the EBML Element has a minimum version of "1".

11.1.5.14.  maxver

   The maxver (maximum version) attribute stores a non-negative integer
   that represents the last or most recent version of the docType to
   support the element. maxver MUST be greater than or equal to minver.

   The maxver attribute is OPTIONAL.  If the maxver attribute is not
   present then the EBML Element has a maximum version equal to the
   value stored in the version attribute of "".



Lhomme, et al.            Expires 23 April 2020                [Page 28]
=0C
Internet-Draft                    EBML                      October 2019


11.1.6.   Element

   The "" element provides additional information about
   the EBML Element.  Within the "" element the following
   XHTML [W3C.SPSD-xhtml-basic-20180327] elements MAY be used: "",
   "
", "".

11.1.7.   Attributes

11.1.7.1.  lang

   A lang attribute which is set to the [RFC5646] value of the language
   of the element's documentation.

   The lang attribute is OPTIONAL.

11.1.7.2.  purpose

   A purpose attribute distinguishes the meaning of the documentation.
   Values for the "" sub-element's purpose attribute MUST
   include one of the following: "definition", "rationale", "usage
   notes", and "references".

   The purpose attribute is REQUIRED.

11.1.8.   Element

   In some cases within an EBML Document Type, the attributes of the
   "" element are not sufficient to clearly communicate how the
   defined EBML Element is intended to be implemented.  For instance,
   one EBML Element might only be mandatory if another EBML Element is
   present, or as another example, the default value of an EBML Element
   might derive from a related Element's content.  In these cases where
   the Element's definition is conditional or advanced implementation
   notes are needed, one or many "" elements can be
   used to store that information.  The "" refer to
   a specific attribute of the parent "" as expressed by the
   "note_attribute" attribute Section 11.1.9.1.

11.1.9.   Attributes

11.1.9.1.  note_attribute

   The note_attribute attribute references which of the ""'s
   attributes that the implementation_note is in regards to.  The
   note_attribute attribute MUST be set to one of the following values
   (corresponding to that attribute of the parent ""):
   "minOccurs", "maxOccurs", "range", "length", "default", "minver", or



Lhomme, et al.            Expires 23 April 2020                [Page 29]
=0C
Internet-Draft                    EBML                      October 2019


   "maxver".  The "" SHALL supersede the parent
   ""'s attribute that is named in the "note_attribute"
   attribute.  An "" SHALL NOT have more than one
   "" of the same "note_attribute".

   The note_attribute attribute is REQUIRED.

11.1.10.   Element

   The "" element provides information about restrictions
   to the allowable values for the EBML Element which are listed in
   "" elements.

11.1.11.   Element

   The "" element stores a list of values allowed for storage in
   the EBML Element.  The values MUST match the type of the EBML Element
   (for example "" cannot be a valid value for a =
EBML
   Element that is defined as an unsigned integer).  An "" element
   MAY also store "" elements to further describe the
   "".

11.1.12.   Attributes

11.1.12.1.  label

   The label provides a concise expression for human consumption that
   describes what the value of the "" represents.

   The label attribute is OPTIONAL.

11.1.12.2.  value

   The value represents data that MAY be stored within the EBML Element.

   The value attribute is REQUIRED.

11.1.13.   Element

   The "" element provides an unconstrained element to
   contain information about the associated EBML "" which is
   undefined by this document but MAY be defined by the associated EBML
   Document Type.  The "" element MUST contain a "type"
   attribute and also MAY contain any other attribute or sub-element as
   long as the EBML Schema remains as a well-formed XML Document.  All
   "" elements MUST be sub-elements of the "".





Lhomme, et al.            Expires 23 April 2020                [Page 30]
=0C
Internet-Draft                    EBML                      October 2019


11.1.14.   Attributes

11.1.14.1.  type

   The type attribute should reference a name or identifier of the
   project or authority associated with the contents of the
   "" element.

   The type attribute is REQUIRED.

11.1.15.  XML Schema for EBML Schema

   This following provides an XML Schema [W3C.REC-xmlschema-0-20041028]
   for facilitating verification of an EBML Schema to the definition
   described in Section 8.1.

   
   

     
     

     

     
       
         
       
       
       
     

     
       
         
         
         
         



Lhomme, et al.            Expires 23 April 2020                [Page 31]
=0C
Internet-Draft                    EBML                      October 2019


       
       
       
       
       
       
       
       
       
       
       
       
       
       
     

     
       
         
       
     

     
       
         
       
       
       
     

     
       
         
       
       
       
     

     
       
         
         
         
       
       
       
         
           
             
             
             
             
           
         
       
     

     
       
         
           
             
               
                 
                 
                 
                 
                 
                 
                 
               
             
           
         
       
     
   

11.1.16.  Identically Recurring Elements

   An Identically Recurring Element is an EBML Element that MAY occur
   within its Parent Element more than once but that each recurrence
   within that Parent Element MUST be identical both in storage and
   semantics.  Identically Recurring Elements are permitted to be stored
   multiple times within the same Parent Element in order to increase
   data resilience and optimize the use of EBML in transmission.  For
   instance a pertinent Top-Level Element could be periodically resent
   within a data stream so that an EBML Reader which starts reading the
   stream from the middle could better interpret the contents.
   Identically Recurring Elements SHOULD include a CRC-32 Element as a



Lhomme, et al.            Expires 23 April 2020                [Page 33]
=0C
Internet-Draft                    EBML                      October 2019


   Child Element; this is especially recommended when EBML is used for
   long-term storage or transmission.  If a Parent Element contains more
   than one copy of an Identically Recurring Element which includes a
   CRC-32 Element as a Child Element then the first instance of the
   Identically Recurring Element with a valid CRC-32 value should be
   used for interpretation.  If a Parent Element contains more than one
   copy of an Identically Recurring Element which does not contain a
   CRC-32 Element or if CRC-32 Elements are present but none are valid
   then the first instance of the Identically Recurring Element should
   be used for interpretation.

11.1.17.  Textual expression of floats

   When a float value is represented textually in an EBML Schema, such
   as within a default or range value, the float values MUST be
   expressed as Hexadecimal Floating-Point Constants as defined in the
   C11 standard [ISO.9899.2011] (see section 6.4.4.2 on Floating
   Constants).  The following table provides examples of expressions of
   float ranges.

      +-------------------+-----------------------------------------+
      | as decimal        | as Hexadecimal Floating-Point Constants |
      +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
      | 0.0               | "0x0p+1"                                |
      +-------------------+-----------------------------------------+
      | 0.0-1.0           | "0x0p+1-0x1p+0"                         |
      +-------------------+-----------------------------------------+
      | 1.0-256.0         | "0x1p+0-0x1p+8"                         |
      +-------------------+-----------------------------------------+
      | 0.857421875       | "0x1.b7p-1"                             |
      +-------------------+-----------------------------------------+
      | -1.0--0.857421875 | "-0x1p+0--0x1.b7p-1"                    |
      +-------------------+-----------------------------------------+

                                  Table 8

   Within an expression of a float range, as in an integer range, the -
   (hyphen) character is the separator between the minimal and maximum
   value permitted by the range.  Hexadecimal Floating-Point Constants
   also use a - (hyphen) when indicating a negative binary power.
   Within a float range, when a - (hyphen) is immediately preceded by a
   letter p, then the - (hyphen) is a part of the Hexadecimal Floating-
   Point Constant which notes negative binary power.  Within a float
   range, when a - (hyphen) is not immediately preceded by a letter p,
   then the - (hyphen) represents the separator between the minimal and
   maximum value permitted by the range.





Lhomme, et al.            Expires 23 April 2020                [Page 34]
=0C
Internet-Draft                    EBML                      October 2019


11.1.18.  Note on the use of default attributes to define Mandatory EBML
          Elements

   If a Mandatory EBML Element has a default value declared by an EBML
   Schema and the value of the EBML Element is equal to the declared
   default value then that EBML Element is not required to be present
   within the EBML Document if its Parent Element is present.  In this
   case, the default value of the Mandatory EBML Element MUST be read by
   the EBML Reader although the EBML Element is not present within its
   Parent Element.

   If a Mandatory EBML Element has no default value declared by an EBML
   Schema and its Parent Element is present then the EBML Element MUST
   be present as well.  If a Mandatory EBML Element has a default value
   declared by an EBML Schema and its Parent Element is present and the
   value of the EBML Element is NOT equal to the declared default value
   then the EBML Element MUST be present.

   This table clarifies if a Mandatory EBML Element MUST be written,
   according to if the default value is declared, if the value of the
   EBML Element is equal to the declared default value, and if the
   Parent Element is used.

   +-----------------+-------------+---------------+------------------+
   |  Is the default |    Is the   | Is the Parent | Then is storing  |
   | value declared? | value equal |    Element    | the EBML Element |
   |                 | to default? |    present?   |    REQUIRED?     |
   +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
   |       Yes       |     Yes     |      Yes      |        No        |
   +-----------------+-------------+---------------+------------------+
   |       Yes       |     Yes     |       No      |        No        |
   +-----------------+-------------+---------------+------------------+
   |       Yes       |      No     |      Yes      |       Yes        |
   +-----------------+-------------+---------------+------------------+
   |       Yes       |      No     |       No      |        No        |
   +-----------------+-------------+---------------+------------------+
   |        No       |     n/a     |      Yes      |       Yes        |
   +-----------------+-------------+---------------+------------------+
   |        No       |     n/a     |       No      |        No        |
   +-----------------+-------------+---------------+------------------+

                                 Table 9

11.2.  EBML Header Elements

   This document contains definitions of all EBML Elements of the EBML
   Header.




Lhomme, et al.            Expires 23 April 2020                [Page 35]
=0C
Internet-Draft                    EBML                      October 2019


11.2.1.  EBML Element

   name: EBML

   path: "1*1(\EBML)"

   id: 0x1A45DFA3

   minOccurs: 1

   maxOccurs: 1

   type: Master Element

   description: Set the EBML characteristics of the data to follow.
   Each EBML Document has to start with this.

11.2.2.  EBMLVersion Element

   name: EBMLVersion

   path: "1*1(\EBML\EBMLVersion)"

   id 0x4286

   minOccurs: 1

   maxOccurs: 1

   range: not 0

   default: 1

   type: Unsigned Integer

   description: The version of EBML specifications used to create the
   EBML Document.  The version of EBML defined in this document is 1, so
   EBMLVersion SHOULD be 1.

11.2.3.  EBMLReadVersion Element

   name: EBMLReadVersion

   path: "1*1(\EBML\EBMLReadVersion)"

   id: 0x42F7

   minOccurs: 1



Lhomme, et al.            Expires 23 April 2020                [Page 36]
=0C
Internet-Draft                    EBML                      October 2019


   maxOccurs: 1

   range: 1

   default: 1

   type: Unsigned Integer

   description: The minimum EBML version an EBML Reader has to support
   to read this EBML Document.  The EBMLReadVersion Element MUST be less
   than or equal to EBMLVersion.

11.2.4.  EBMLMaxIDLength Element

   name: EBMLMaxIDLength

   path: "1*1(\EBML\EBMLMaxIDLength)"

   id 0x42F2

   minOccurs: 1

   maxOccurs: 1

   range: >=3D4

   default: 4

   type: Unsigned Integer

   description: The EBMLMaxIDLength Element stores the maximum permitted
   length in octets of the Element IDs to be found within the EBML Body.
   An EBMLMaxIDLength Element value of four is RECOMMENDED, though
   larger values are allowed.

11.2.5.  EBMLMaxSizeLength Element

   name: EBMLMaxSizeLength

   path: "1*1(\EBML\EBMLMaxSizeLength)"

   id 0x42F3

   minOccurs: 1

   maxOccurs: 1

   range: not 0



Lhomme, et al.            Expires 23 April 2020                [Page 37]
=0C
Internet-Draft                    EBML                      October 2019


   default: 8

   type: Unsigned Integer

   description: The EBMLMaxSizeLength Element stores the maximum
   permitted length in octets of the expressions of all Element Data
   Sizes to be found within the EBML Body.  The EBMLMaxSizeLength
   Element documents an upper bound for the "length" of all Element Data
   Size expressions within the EBML Body and not an upper bound for the
   "value" of all Element Data Size expressions within the EBML Body.
   EBML Elements that have an Element Data Size expression which is
   larger in octets than what is expressed by EBMLMaxSizeLength Element
   are invalid.

11.2.6.  DocType Element

   name: DocType

   path: "1*1(\EBML\DocType)"

   id 0x4282

   minOccurs: 1

   maxOccurs: 1

   length: >0

   type: String

   description: A string that describes and identifies the content of
   the EBML Body that follows this EBML Header.

11.2.7.  DocTypeVersion Element

   name: DocTypeVersion

   path: "1*1(\EBML\DocTypeVersion)"

   id 0x4287

   minOccurs: 1

   maxOccurs: 1

   range: not 0

   default: 1



Lhomme, et al.            Expires 23 April 2020                [Page 38]
=0C
Internet-Draft                    EBML                      October 2019


   type: Unsigned Integer

   description: The version of DocType interpreter used to create the
   EBML Document.

11.2.8.  DocTypeReadVersion Element

   name: DocTypeReadVersion

   path: "1*1(\EBML\DocTypeReadVersion)"

   id 0x4285

   minOccurs: 1

   maxOccurs: 1

   range: not 0

   default: 1

   type: Unsigned Integer

   description: The minimum DocType version an EBML Reader has to
   support to read this EBML Document.  The value of the
   DocTypeReadVersion Element MUST be less than or equal to the value of
   the DocTypeVersion Element.

11.2.9.  DocTypeExtension Element

   name: DocTypeExtension

   path: "0*(\EBML\DocTypeExtension)"

   id 0x4281

   minOccurs: 0

   type: Master Element

   description: A DocTypeExtension adds extra Elements to the main
   DocType+DocTypeVersion tuple it's attached to.  An EBML Reader MAY
   know these extra Elements and how to use them.  A DocTypeExtension
   MAY be used to iterate between experimental Elements before they are
   integrated in a regular DocTypeVersion.  Reading one DocTypeExtension
   version of a DocType+DocTypeVersion tuple doesn't imply one should be
   able to read upper versions of this DocTypeExtension.




Lhomme, et al.            Expires 23 April 2020                [Page 39]
=0C
Internet-Draft                    EBML                      October 2019


11.2.10.  DocTypeExtensionName Element

   name: DocTypeExtensionName

   path: "1*1(\EBML\DocTypeExtension\Name)"

   id 0x4283

   minOccurs: 1

   maxOccurs: 1

   length: >0

   type: String

   description: The name of the DocTypeExtension to differentiate it
   from other DocTypeExtension of the same DocType+DocTypeVersion tuple.
   A DocTypeExtensionName value MUST be unique within the EBML Header.

11.2.11.  DocTypeExtensionVersion Element

   name: DocTypeExtensionVersion

   path: "1*1(\EBML\DocTypeExtension\Version)"

   id 0x4284

   minOccurs: 1

   maxOccurs: 1

   range: not 0

   type: Unsigned Integer

   description: The version of the DocTypeExtension.  Different
   DocTypeExtensionVersion values of the same
   DocType+DocTypeVersion+DocTypeExtensionName tuple MAY contain
   completely different sets of extra Elements.  An EBML Reader MAY
   support multiple versions of the same DocTypeExtension, only one or
   none.









Lhomme, et al.            Expires 23 April 2020                [Page 40]
=0C
Internet-Draft                    EBML                      October 2019


11.3.  Global Elements

   EBML allows some special Elements to be found within more than one
   parent in an EBML Document or optionally at the Root Level of an EBML
   Body.  These Elements are called Global Elements.  There are 2 Global
   Elements that can be found in any EBML Document: the CRC-32 Element
   and the Void Element.  An EBML Schema MAY add other Global Elements
   to the format it defines.  These extra elements apply only to the
   EBML Body, not the EBML Header.

   Global Elements are EBML Elements whose path have a EBMLGlobalParent
   as their EBMLLastParent.  Because it is the last Parent part of the
   path, a Global Element might also have non-EBMLGlobalParent parts in
   its path.  In this case the Global Element can only be found within
   this non-EBMLGlobalParent path, i.e. it's not fully "global".

   The EBMLEltOccurrence of a Global Element is the number of
   occurrences the Element can be found in a Parent Element.  But the
   Global Element can be found in many Parent Elements, allowing the
   same number of occurrences in each Parent where this Element is
   found.

11.3.1.  CRC-32 Element

   name: CRC-32

   path: "*1((1*\)\CRC-32)"

   id: 0xBF

   minOccurs: 0

   maxOccurs: 1

   length: 4

   type: Binary

   description: The CRC-32 Element contains a 32-bit Cyclic Redundancy
   Check value of all the Element Data of the Parent Element as stored
   except for the CRC-32 Element itself.  When the CRC-32 Element is
   present, the CRC-32 Element MUST be the first ordered EBML Element
   within its Parent Element for easier reading.  All Top-Level Elements
   of an EBML Document that are Master Elements SHOULD include a CRC-32
   Element as a Child Element.  The CRC in use is the IEEE-CRC-32
   algorithm as used in the [ISO.3309.1979] standard and in section
   8.1.1.6.2 of [ITU.V42.1994], with initial value of 0xFFFFFFFF.  The




Lhomme, et al.            Expires 23 April 2020                [Page 41]
=0C
Internet-Draft                    EBML                      October 2019


   CRC value MUST be computed on a little endian bitstream and MUST use
   little endian storage.

11.3.2.  Void Element

   name: Void

   path: "*((*\)\Void)"

   id: 0xEC

   minOccurs: 0

   type: Binary

   description: Used to void data or to avoid unexpected behaviors when
   using damaged data.  The content is discarded.  Also used to reserve
   space in a sub-element for later use.

12.  Considerations for Reading EBML Data

   The following scenarios describe events to consider when reading EBML
   Documents and the recommended design of an EBML Reader.

   If a Master Element contains a CRC-32 Element that doesn't validate,
   then the EBML Reader MAY ignore all contained data except for
   Descendant Elements that contain their own valid CRC-32 Element.

   If a Master Element contains more occurrences of a Child Master
   Element than permitted according to the maxOccurs and recurring
   attributes of the definition of that Element then the occurrences in
   addition to maxOccurs MAY be ignored.

   If a Master Element contains more occurrences of a Child Element than
   permitted according to the maxOccurs attribute of the definition of
   that Element then all instances of that Element after the first
   maxOccur occurrences from the beginning of its Parent Element SHOULD
   be ignored.

13.  Terminating Elements

   Null Octets, which are octets with all bits set to zero, MAY follow
   the value of a String Element or UTF-8 Element to serve as a
   terminator.  An EBML Writer MAY terminate a String Element or UTF-8
   Element with Null Octets in order to overwrite a stored value with a
   new value of lesser length while maintaining the same Element Data
   Size (this can prevent the need to rewrite large portions of an EBML
   Document); otherwise the use of Null Octets within a String Element



Lhomme, et al.            Expires 23 April 2020                [Page 42]
=0C
Internet-Draft                    EBML                      October 2019


   or UTF-8 Element is NOT RECOMMENDED.  An EBML Reader MUST consider
   the value of the String Element or UTF-8 Element to be terminated
   upon the first read Null Octet and MUST ignore any data following the
   first Null Octet within that Element.  A string value and a copy of
   that string value terminated by one or more Null Octets are
   semantically equal.

   The following table shows examples of semantics and validation for
   the use of Null Octets.  Values to represent Stored Values and the
   Semantic Meaning as represented as hexadecimal values.

               +---------------------+---------------------+
               | Stored Value        | Semantic Meaning    |
               +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
               | 0x65 0x62 0x6D 0x6C | 0x65 0x62 0x6D 0x6C |
               +---------------------+---------------------+
               | 0x65 0x62 0x00 0x6C | 0x65 0x62           |
               +---------------------+---------------------+
               | 0x65 0x62 0x00 0x00 | 0x65 0x62           |
               +---------------------+---------------------+
               | 0x65 0x62           | 0x65 0x62           |
               +---------------------+---------------------+

                                  Table 10

14.  Guidelines for Updating Elements

   An EBML Document can be updated without requiring that the entire
   EBML Document be rewritten.  These recommendations describe
   strategies to change the Element Data of a written EBML Element with
   minimal disruption to the rest of the EBML Document.

14.1.  Reducing a Element Data in Size

   There are three methods to reduce the size of Element Data of a
   written EBML Element.

14.1.1.  Adding a Void Element

   When an EBML Element is changed to reduce its total length by more
   than one octet, an EBML Writer SHOULD fill the freed space with a
   Void Element.

14.1.2.  Extending the Element Data Size

   The same value for Element Data Size MAY be written in variable
   lengths, so for minor reductions in octet length the Element Data
   Size MAY be written to a longer octet length to fill the freed space.



Lhomme, et al.            Expires 23 April 2020                [Page 43]
=0C
Internet-Draft                    EBML                      October 2019


   For example, the first row of the following table depicts a String
   Element that stores an Element ID (3 octets), Element Data Size (1
   octet), and Element Data (4 octets).  If the Element Data is changed
   to reduce the length by one octet and if the current length of the
   Element Data Size is less than its maximum permitted length, then the
   Element Data Size of that Element MAY be rewritten to increase its
   length by one octet.  Thus before and after the change the EBML
   Element maintains the same length of 8 octets and data around the
   Element does not need to be moved.

      +-------------+------------+-------------------+--------------+
      | Status      | Element ID | Element Data Size | Element Data |
      +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
      | Before edit | 0x3B4040   | 0x84              | 0x65626D6C   |
      +-------------+------------+-------------------+--------------+
      | After edit  | 0x3B4040   | 0x4003            | 0x6D6B76     |
      +-------------+------------+-------------------+--------------+

                                  Table 11

   This method is RECOMMENDED when the Element Data is reduced by a
   single octet; for reductions by two or more octets it is RECOMMENDED
   to fill the freed space with a Void Element.

   Note that if the Element Data length needs to be rewritten as
   shortened by one octet and the Element Data Size could be rewritten
   as a shorter VINT then it is RECOMMENDED to rewrite the Element Data
   Size as one octet shorter, shorten the Element Data by one octet, and
   follow that Element with a Void Element.  For example, the following
   table depicts a String Element that stores an Element ID (3 octets),
   Element Data Size (2 octets, but could be rewritten in one octet),
   and Element Data (3 octets).  If the Element Data is to be rewritten
   to a two octet length, then another octet can be taken from Element
   Data Size so that there is enough space to add a two octet Void
   Element.

   +--------+------------+-------------------+--------------+---------+
   | Status | Element ID | Element Data Size | Element Data | Void    |
   |        |            |                   |              | Element |
   +=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D+
   | Before | 0x3B4040   | 0x4003            | 0x6D6B76     |         |
   +--------+------------+-------------------+--------------+---------+
   | After  | 0x3B4040   | 0x82              | 0x6869       | 0xEC80  |
   +--------+------------+-------------------+--------------+---------+

                                 Table 12





Lhomme, et al.            Expires 23 April 2020                [Page 44]
=0C
Internet-Draft                    EBML                      October 2019


14.1.3.  Terminating Element Data

   For String Elements and UTF-8 Elements the length of Element Data MAY
   be reduced by adding Null Octets to terminate the Element Data (see
   the section on Terminating Elements (#terminating-elements)).

   In the following table, a four octets long Element Data is changed to
   a three octet long value followed by a Null Octet; the Element Data
   Size includes any Null Octets used to terminate Element Data so
   remains unchanged.

      +-------------+------------+-------------------+--------------+
      | Status      | Element ID | Element Data Size | Element Data |
      +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
      | Before edit | 0x3B4040   | 0x84              | 0x65626D6C   |
      +-------------+------------+-------------------+--------------+
      | After edit  | 0x3B4040   | 0x84              | 0x6D6B7600   |
      +-------------+------------+-------------------+--------------+

                                  Table 13

   Note that this method is NOT RECOMMENDED.  For reductions of one
   octet, the method for Extending the Element Data Size SHOULD be used.
   For reduction by more than one octet, the method for Adding a Void
   Element SHOULD be used.

14.2.  Considerations when Updating Elements with Cyclic Redundancy
       Check (CRC)

   If the Element to be changed is a Descendant Element of any Master
   Element that contains a CRC-32 Element (see Section 11.3.1) then the
   CRC-32 Element MUST be verified before permitting the change.
   Additionally the CRC-32 Element value MUST be subsequently updated to
   reflect the changed data.

15.  Backward and Forward Compatibility

   Elements of an EBML format SHOULD be designed with backward and
   forward compatibility in mind.

15.1.  Backward Compatibility

   Backward compatibility of new EBML Elements can be achieved by using
   default values for mandatory elements.  The default value MUST
   represent the state that was assumed for previous versions of the
   EBML Schema, without this new EBML Element.  If such a state doesn't
   make sense for previous versions, then the new EBML Element SHOULD
   NOT be mandatory.



Lhomme, et al.            Expires 23 April 2020                [Page 45]
=0C
Internet-Draft                    EBML                      October 2019


   Non mandatory EBML Elements can be added in a new EBMLDocTypeVersion.
   Since they are not mandatory they won't be found in older versions of
   the EBMLDocTypeVersion, just as they might not be found in newer
   versions.  This causes no compatibility issue.

15.2.  Forward Compatibility

   EBML Elements MAY be marked as deprecated in a new EBMLDocTypeVersion
   using the maxver attribute of the EBML Schema.  If such an Element is
   found in an EBML Document with newer version of the
   EBMLDocTypeVersion it SHOULD be discarded.

16.  Security Considerations

   EBML itself does not offer any kind of security and does not provide
   confidentiality.  EBML does not provide any kind of authorization.
   EBML only offers marginally useful and effective data integrity
   options, such as CRC elements.

   Even if the semantic layer offers any kind of encryption, EBML itself
   could leak information at both the semantic layer (as declared via
   the DocType Element) and within the EBML structure (the presence of
   EBML Elements can be derived even with an unknown semantic layer
   using a heuristic approach; not without errors, of course, but with a
   certain degree of confidence).

   An EBML Document that has the following issues may still be handled
   by the EBML Reader and the data accepted as such, depending on how
   strict the EBML Reader wants to be:

   *  Invalid Element IDs that are longer than the limit stated in the
      EBMLMaxIDLength Element of the EBML Header.

   *  Invalid Element IDs that are not encoded in the shortest-possible
      way.

   *  Invalid Element Data Size values that are longer than the limit
      stated in the EBMLMaxSizeLength Element of the EBML Header.

   Element IDs that are unknown to the EBML Reader MAY be accepted as
   valid EBML IDs in order to skip such elements.

   EBML Elements with a string type may contain extra data after the
   first 0x00.  These data MUST be discarded according to the Section 13
   rules.

   An EBML Reader may discard some or all data if the following errors
   are found in the EBML Document:



Lhomme, et al.            Expires 23 April 2020                [Page 46]
=0C
Internet-Draft                    EBML                      October 2019


   *  Invalid Element Data Size values (e.g. extending the length of the
      EBML Element beyond the scope of the Parent Element; possibly
      triggering access-out-of-bounds issues).

   *  Very high lengths in order to force out-of-memory situations
      resulting in a denial of service, access-out-of-bounds issues etc.

   *  Missing EBML Elements that are mandatory in a Master Element and
      have no declared default value, making the semantic invalid at
      that Master Element level.

   *  Usage of invalid UTF-8 encoding in EBML Elements of UTF-8 type
      (e.g. in order to trigger access-out-of-bounds or buffer overflow
      issues).

   *  Usage of invalid data in EBML Elements with a date type,
      triggering bogus date accesses.

   Side channel attacks could exploit:

   *  The semantic equivalence of the same string stored in a String
      Element or UTF-8 Element with and without zero-bit padding, making
      comparison at the semantic level invalid.

   *  The semantic equivalence of VINT_DATA within Element Data Size
      with two different lengths due to left-padding zero bits, making
      comparison at the semantic level invalid.

   *  Data contained within a Master Element which is not itself part of
      a Child Element can trigger incorrect parsing behavior in EBML
      Readers.

   *  Extraneous copies of Identically Recurring Element, making parsing
      unnecessarily slow to the point of not being usable.

   *  Copies of Identically Recurring Element within a Parent Element
      that contain invalid CRC-32 Elements.  EBML Readers not checking
      the CRC-32 might use the version of the element with mismatching
      CRC-32.

   *  Use of Void Elements which could be used to hide content or create
      bogus resynchronization points seen by some EBML Reader and not
      others.

17.  IANA Considerations






Lhomme, et al.            Expires 23 April 2020                [Page 47]
=0C
Internet-Draft                    EBML                      October 2019


17.1.  CELLAR EBML Element ID Registry

   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 Section 4 can
   be between one and five octets long.  Five octet long Element IDs are
   possible only if declared in the header.

   This IANA Registry only applies to Elements that can be contained in
   the EBML Header, thus including Global Elements (#global-elements).
   Elements only found in the EBML Body have their own set of
   independent Element IDs and are not part of this IANA Registry.

   The VINT Data value of one-octet Element IDs MUST be between 0x01 and
   0x7E.  These items are valuable because they are short, and need to
   be used for commonly repeated elements.  Values from 1 to 126 are to
   be allocated according to the "RFC Required" policy [RFC8126].

   The VINT Data value of two-octet Element IDs MUST be between 0x007F
   and 0x3FFE.  Numbers are to be allocated within this range according
   to the "Specification Required" policy [RFC8126].

   The numbers 0x3FFF and 0x4000 are RESERVED.

   The VINT Data value of three-octet Element IDs MUST be between 0x4001
   and 0x1FFFFE.  Numbers may be allocated within this range according
   to the "First Come First Served" policy [RFC8126].

   The numbers 0x1FFFFF and 0x200000 are RESERVED.

   Four-octet Element IDs are numbers between 0x101FFFFF and 0x1FFFFFFE.
   Four-octet 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-octet Element IDs are split into
   two categories.  Four-octet Element IDs whose lower three octets (as
   encoded) would make printable 7-bit ASCII values (0x20 to 0x7E,
   inclusive) MUST be allocated by the "Specification Required" policy.
   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-octet Element IDs always
   start with hex 0x10 to 0x1F, and that octet may be chosen so that the
   entire number has some desirable property, such as a specific CRC.
   The other three octets, when ALL having values between 0x21 (33,
   ASCII !) and 0x7E (126, ASCII ~), fall into this category.



Lhomme, et al.            Expires 23 April 2020                [Page 48]
=0C
Internet-Draft                    EBML                      October 2019


   Other four-octet Element IDs may be allocated by the "First Come
   First Served" policy.

   The numbers 0xFFFFFFF and 0x1000000 are RESERVED.

   Five octet Element IDs (values from 0x10000001 upwards) are RESERVED
   according to the "Experimental Use" policy [RFC8126]: they may be
   used by anyone at any time, but there is no coordination.

   ID Values found in this document are assigned as initial values as
   follows:








































Lhomme, et al.            Expires 23 April 2020                [Page 49]
=0C
Internet-Draft                    EBML                      October 2019


        +------------+-------------------------+-----------------+
        |         ID | Element Name            | Reference       |
        +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D+
        | 0x1A45DFA3 | EBML                    | Described in    |
        |            |                         | Section 11.2.1  |
        +------------+-------------------------+-----------------+
        |     0x4286 | EBMLVersion             | Described in    |
        |            |                         | Section 11.2.2  |
        +------------+-------------------------+-----------------+
        |     0x42F7 | EBMLReadVersion         | Described in    |
        |            |                         | Section 11.2.3  |
        +------------+-------------------------+-----------------+
        |     0x42F2 | EBMLMaxIDLength         | Described in    |
        |            |                         | Section 11.2.4  |
        +------------+-------------------------+-----------------+
        |     0x42F3 | EBMLMaxSizeLength       | Described in    |
        |            |                         | Section 11.2.5  |
        +------------+-------------------------+-----------------+
        |     0x4282 | DocType                 | Described in    |
        |            |                         | Section 11.2.6  |
        +------------+-------------------------+-----------------+
        |     0x4287 | DocTypeVersion          | Described in    |
        |            |                         | Section 11.2.7  |
        +------------+-------------------------+-----------------+
        |     0x4285 | DocTypeReadVersion      | Described in    |
        |            |                         | Section 11.2.8  |
        +------------+-------------------------+-----------------+
        |     0x4281 | DocTypeExtension        | Described in    |
        |            |                         | Section 11.2.9  |
        +------------+-------------------------+-----------------+
        |     0x4283 | DocTypeExtensionName    | Described in    |
        |            |                         | Section 11.2.10 |
        +------------+-------------------------+-----------------+
        |     0x4284 | DocTypeExtensionVersion | Described in    |
        |            |                         | Section 11.2.11 |
        +------------+-------------------------+-----------------+
        |       0xBF | CRC-32                  | Described in    |
        |            |                         | Section 11.3.1  |
        +------------+-------------------------+-----------------+
        |       0xEC | Void                    | Described in    |
        |            |                         | Section 11.3.2  |
        +------------+-------------------------+-----------------+

                                 Table 14







Lhomme, et al.            Expires 23 April 2020                [Page 50]
=0C
Internet-Draft                    EBML                      October 2019


17.2.  CELLAR EBML DocType Registry

   This document creates a new IANA Registry called "CELLAR EBML DocType
   Registry".

   To register a new DocType in this registry one needs a DocType name,
   a Description of the DocType, a Change Controller (IESG or email of
   registrant) and an optional Reference to a document describing the
   DocType.

   DocType values are described in this section (#doctype).  DocTypes
   are ASCII strings, defined in the String Element section (#string-
   element), which label the official name of the EBML Document Type.
   The strings may be allocated according to the "First Come First
   Served" policy.

   The use of ASCII corresponds to the types and code already in use,
   the value is not meant to be visible to the user.

   DocType string values of "matroska" and "webm" are RESERVED to the
   IETF for future use.  These can be assigned via the "IESG Approval"
   or "RFC Required" policies [RFC8126].

18.  Normative References

   [IEEE.754.1985]
              Institute of Electrical and Electronics Engineers,
              "Standard for Binary Floating-Point Arithmetic", August
              1985.

   [ISO.3309.1979]
              International Organization for Standardization, "Data
              communication - High-level data link control procedures -
              Frame structure", 1979.

   [ISO.9899.2011]
              International Organization for Standardization,
              "Programming languages - C", 2011.

   [ITU.V42.1994]
              International Telecommunications Union, "Error-correcting
              Procedures for DCEs Using Asynchronous-to-Synchronous
              Conversion", 1994.

   [RFC0020]  Cerf, V., "ASCII format for network interchange", STD 80,
              RFC 20, DOI 10.17487/RFC0020, October 1969,
              .




Lhomme, et al.            Expires 23 April 2020                [Page 51]
=0C
Internet-Draft                    EBML                      October 2019


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              .

   [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
              Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
              .

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
              2003, .

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              .

   [RFC5646]  Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
              Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
              September 2009, .

   [RFC7405]  Kyzivat, P., "Case-Sensitive String Support in ABNF",
              RFC 7405, DOI 10.17487/RFC7405, December 2014,
              .

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              .

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, .

   [W3C.REC-xml-20081126]
              Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
              F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
              Edition)", World Wide Web Consortium Recommendation REC-
              xml-20081126, 26 November 2008,
              .

   [W3C.SPSD-xhtml-basic-20180327]
              McCarron, S., "XHTML(tm) Basic 1.1 - Second Edition", 27
              March 2018.

19.  Informative References




Lhomme, et al.            Expires 23 April 2020                [Page 52]
=0C
Internet-Draft                    EBML                      October 2019


   [W3C.REC-xmlschema-0-20041028]
              Fallside, D. and P. Walmsley, "XML Schema Part 0: Primer
              Second Edition", World Wide Web Consortium Recommendation=20=

              REC-xmlschema-0-20041028, 28 October 2004,
              .

Authors' Addresses

   Steve Lhomme

   Email: slhomme@matroska.org


   Dave Rice

   Email: dave@dericed.com


   Moritz Bunkus

   Email: moritz@bunkus.org






























Lhomme, et al.            Expires 23 April 2020                [Page 53]

--Apple-Mail=_3CEF22D2-68BC-49E3-ABE9-E337F8FEA435
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii


--Apple-Mail=_3CEF22D2-68BC-49E3-ABE9-E337F8FEA435--

--Apple-Mail=_826F171C-452B-41F2-8E91-66701F5AD401--


From nobody Mon Oct 21 11:28:54 2019
Return-Path: 
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D289120105; Mon, 21 Oct 2019 11:28:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.096
X-Spam-Level: 
X-Spam-Status: No, score=-1.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=no 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 0Tz11E5EpcO2; Mon, 21 Oct 2019 11:28:44 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C50C4120025; Mon, 21 Oct 2019 11:28:44 -0700 (PDT)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:63513 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1iMcQ7-0005M8-AB; Mon, 21 Oct 2019 11:28:43 -0700
To: Dave Rice , Michael Richardson 
References: <157167166904.31800.14436237517062444902@ietfa.amsl.com> <2259.1571680217@localhost> 
Cc: cellar@ietf.org, tools-discuss@ietf.org
From: Henrik Levkowetz 
Message-ID: <7d488832-92f7-5e8c-896f-d4a3bb3ada61@levkowetz.com>
Date: Mon, 21 Oct 2019 20:28:35 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ptLoU8KVSwCl7oBJ4xObAT0v5In8IGXGN"
X-SA-Exim-Connect-IP: 158.174.202.242
X-SA-Exim-Rcpt-To: tools-discuss@ietf.org, cellar@ietf.org, mcr@sandelman.ca,  dave@dericed.com
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org)
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: 
Subject: Re: [Tools-discuss] [Cellar] I-D Action: draft-ietf-cellar-ebml-12.txt
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2019 18:28:46 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--ptLoU8KVSwCl7oBJ4xObAT0v5In8IGXGN
Content-Type: multipart/mixed; boundary="bObqwQqt16vqvERonClErPtS781OCnT8D";
 protected-headers="v1"
From: Henrik Levkowetz 
To: Dave Rice , Michael Richardson 
Cc: cellar@ietf.org, tools-discuss@ietf.org
Message-ID: <7d488832-92f7-5e8c-896f-d4a3bb3ada61@levkowetz.com>
Subject: Re: [Tools-discuss] [Cellar] I-D Action:
 draft-ietf-cellar-ebml-12.txt
References: <157167166904.31800.14436237517062444902@ietfa.amsl.com>
 <2259.1571680217@localhost>
 
In-Reply-To: 

--bObqwQqt16vqvERonClErPtS781OCnT8D
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Dave,

On 2019-10-21 20:22, Dave Rice wrote:
> Hi Michael,
>=20
>> On Oct 21, 2019, at 1:50 PM, Michael Richardson > > wrote:
>>
>>
>> Dave, is ebml in XML v3, uploaded as such?
>=20
> It was uploaded via https://datatracker.ietf.org/submit/.
>=20
>> Were the txt and HTML generated by you or the datatracker?
>=20
> With xml2rfc 2.32.0 locally the files look ok, I=E2=80=99m attaching th=
em.
>=20
> I haven=E2=80=99t tested but in the XML within the  we have=
 0x0A for line=20
> breaks. I wonder if an 0x0d (carriage return) would make a difference, =
though I=20
> feel guilty using up version numbers just to test that.

Using 0x0D will not make a difference.

I've run into this for at least one other draft, and I believe that the
upcoming new datatracker release deployment will pull in the latest xml2r=
fc
and address this.

I will do some additional testing in my dev copy, though.


Best regards,

	Henrik

>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cellar-ebml-12
>>
>> looking at the diff of the txt, there are a bunch of relative referenc=
es which=20
>> did not
>> get expanded correctly from the markdown:
>>
>>    unknownsizeallowed attribute (#unknownsizeallowed)).
>=20
> I=E2=80=99ll address that separately.
>=20
>> Looks like a tooling issue somewhere.
>> Looking at this:
>> https://www.ietf.org/id/draft-ietf-cellar-ebml-12.html
>>
>> I don't see #unknownsizeallowed in the same way, but the reference tha=
t is
>> generated looks off to me.
>>
>> --
>> ]               Never tell me the odds!                 | ipv6 mesh ne=
tworks [
>> ]   Michael Richardson, Sandelman Software Works        |    IoT archi=
tect   [
>> ] mcr@sandelman.ca  http://www.sandelman.ca/ =
       |=20
>>   ruby on rails    [
>>
>>
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> ___________________________________________________________
> Tools-discuss mailing list
> Tools-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/tools-discuss
>=20
> Please report datatracker.ietf.org and mailarchive.ietf.org
> bugs at http://tools.ietf.org/tools/ietfdb
> or send email to datatracker-project@ietf.org
>=20
> Please report tools.ietf.org bugs at
> http://tools.ietf.org/tools/issues
> or send email to webmaster@tools.ietf.org
>=20


--bObqwQqt16vqvERonClErPtS781OCnT8D--

--ptLoU8KVSwCl7oBJ4xObAT0v5In8IGXGN
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl2t+NMACgkQTptXS4+7
FxofIQ//eu1v12zg/TADV7CnBDxDgaQ6AzVfNhtT4+J+4SSDnT86aKTo2XG08PPr
0XoQhYqUUx1UO0Pn/d40SymCYXjE2sj6AMpzLuv5tI1RA7K6qnYJG0P/8ZZek1cB
ZDTgxaRohwAaYgpog4LSuVoDghtvCyFhlJD4klpMsdyOeOGMTEPdu6DWH/So7xzZ
AY1aLJpXQuUq6yJl2zmk5DXnOgw1Z7pLMfN5sE8dqMiroSzIva0nJtlNfkFEq1zT
9b6HpnFKEUSx5iSDh0vuKVKG/vnnLSnci8RaTk5iOmBaQaKLsu+dsqzs9QzAVRXf
Fteb3rzQ4WJLEU12Wa9Kqhcepv+tRZIdnol1XfxaUfZl4dMhP/WGTAkxO/hOTHlm
KWPffdF0tPIIn+cYHOPuqIkoigx3rEVVOmNLW2RaIc24Pmn+CVg3lCDmizoaWtdA
WRyJbMoljQ0+xQCXjP30gwfy4oVxBG+lx0AkyTmDetOL1zLRkqvhovMoU/jX60JJ
gtGbwOe/WdYD+sRzqN2cpHnL8xdbxchQzvEmixFknhUWCELetermc8F21POtCtj6
i8BXUAKL20s0simWZV95NZtQU4uy1fuSYUprsYWd+t1FaXEK8VU1hrAJMrTfNSTR
0g8H0uAm/E1DxdqqIeHZ6T5z/MyIYhUlcYrzZroe40jxnvBFmt8=
=QO6b
-----END PGP SIGNATURE-----

--ptLoU8KVSwCl7oBJ4xObAT0v5In8IGXGN--


From nobody Mon Oct 21 12:37:47 2019
Return-Path: 
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D45F2120830; Mon, 21 Oct 2019 12:37:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level: 
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 iq9D2NFq9ajR; Mon, 21 Oct 2019 12:37:39 -0700 (PDT)
Received: from server172-3.web-hosting.com (server172-3.web-hosting.com [68.65.122.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AACD1202A0; Mon, 21 Oct 2019 12:37:39 -0700 (PDT)
Received: from [146.96.19.240] (port=62484 helo=[10.10.201.23]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1iMdUj-000eR0-M3; Mon, 21 Oct 2019 15:37:38 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Dave Rice 
In-Reply-To: <7d488832-92f7-5e8c-896f-d4a3bb3ada61@levkowetz.com>
Date: Mon, 21 Oct 2019 15:37:27 -0400
Cc: Michael Richardson , cellar@ietf.org, tools-discuss@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <157167166904.31800.14436237517062444902@ietfa.amsl.com> <2259.1571680217@localhost>  <7d488832-92f7-5e8c-896f-d4a3bb3ada61@levkowetz.com>
To: Henrik Levkowetz 
X-Mailer: Apple Mail (2.3445.104.8)
X-OutGoing-Spam-Status: No, score=-2.1
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server172.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - dericed.com
X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com
X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-From-Rewrite: unmodified, already matched
Archived-At: 
Subject: Re: [Tools-discuss] [Cellar] I-D Action: draft-ietf-cellar-ebml-12.txt
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2019 19:37:41 -0000

Hi Henrik,

> On Oct 21, 2019, at 2:28 PM, Henrik Levkowetz  =
wrote:
>=20
> Hi Dave,
>=20
> On 2019-10-21 20:22, Dave Rice wrote:
>> Hi Michael,
>>=20
>>> On Oct 21, 2019, at 1:50 PM, Michael Richardson >> > wrote:
>>>=20
>>>=20
>>> Dave, is ebml in XML v3, uploaded as such?
>>=20
>> It was uploaded via https://datatracker.ietf.org/submit/.
>>=20
>>> Were the txt and HTML generated by you or the datatracker?
>>=20
>> With xml2rfc 2.32.0 locally the files look ok, I=E2=80=99m attaching =
them.
>>=20
>> I haven=E2=80=99t tested but in the XML within the  we =
have 0x0A for line=20
>> breaks. I wonder if an 0x0d (carriage return) would make a =
difference, though I=20
>> feel guilty using up version numbers just to test that.
>=20
> Using 0x0D will not make a difference.
>=20
> I've run into this for at least one other draft, and I believe that =
the
> upcoming new datatracker release deployment will pull in the latest =
xml2rfc
> and address this.
>=20
> I will do some additional testing in my dev copy, though.

Is there a way to tell which version of xml2rfc is used in the =
datatracker at any particular time? It would be helpful to ensure my =
local testing matches.
Dave

> Best regards,
>=20
> 	Henrik
>=20
>>>> A diff from the previous version is available at:
>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cellar-ebml-12
>>>=20
>>> looking at the diff of the txt, there are a bunch of relative =
references which=20
>>> did not
>>> get expanded correctly from the markdown:
>>>=20
>>>   unknownsizeallowed attribute (#unknownsizeallowed)).
>>=20
>> I=E2=80=99ll address that separately.
>>=20
>>> Looks like a tooling issue somewhere.
>>> Looking at this:
>>> https://www.ietf.org/id/draft-ietf-cellar-ebml-12.html
>>>=20
>>> I don't see #unknownsizeallowed in the same way, but the reference =
that is
>>> generated looks off to me.
>>>=20
>>> --
>>> ]               Never tell me the odds!                 | ipv6 mesh =
networks [
>>> ]   Michael Richardson, Sandelman Software Works        |    IoT =
architect   [
>>> ] mcr@sandelman.ca  =
http://www.sandelman.ca/        |=20
>>>  ruby on rails    [
>>>=20
>>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>> ___________________________________________________________
>> Tools-discuss mailing list
>> Tools-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/tools-discuss
>>=20
>> Please report datatracker.ietf.org and mailarchive.ietf.org
>> bugs at http://tools.ietf.org/tools/ietfdb
>> or send email to datatracker-project@ietf.org
>>=20
>> Please report tools.ietf.org bugs at
>> http://tools.ietf.org/tools/issues
>> or send email to webmaster@tools.ietf.org
>>=20
>=20
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar


From nobody Mon Oct 21 12:39:59 2019
Return-Path: 
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B4E120837; Mon, 21 Oct 2019 12:39:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.096
X-Spam-Level: 
X-Spam-Status: No, score=-1.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=no 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 XIJxEk74jqrT; Mon, 21 Oct 2019 12:39:50 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 545051202A0; Mon, 21 Oct 2019 12:39:50 -0700 (PDT)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:64101 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1iMdWu-0002qe-NA; Mon, 21 Oct 2019 12:39:49 -0700
To: Dave Rice 
References: <157167166904.31800.14436237517062444902@ietfa.amsl.com> <2259.1571680217@localhost>  <7d488832-92f7-5e8c-896f-d4a3bb3ada61@levkowetz.com> 
Cc: Michael Richardson , cellar@ietf.org, tools-discuss@ietf.org
From: Henrik Levkowetz 
Message-ID: 
Date: Mon, 21 Oct 2019 21:39:40 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wJKroo1t9T3AdDmhv6i75ErP0UTQvwIIg"
X-SA-Exim-Connect-IP: 158.174.202.242
X-SA-Exim-Rcpt-To: tools-discuss@ietf.org, cellar@ietf.org, mcr@sandelman.ca,  dave@dericed.com
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org)
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: 
Subject: Re: [Tools-discuss] [Cellar] I-D Action: draft-ietf-cellar-ebml-12.txt
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2019 19:39:52 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--wJKroo1t9T3AdDmhv6i75ErP0UTQvwIIg
Content-Type: multipart/mixed; boundary="4uDoTpChFoWiTqd2W5aHeadllnEBQJkBc";
 protected-headers="v1"
From: Henrik Levkowetz 
To: Dave Rice 
Cc: Michael Richardson , cellar@ietf.org,
 tools-discuss@ietf.org
Message-ID: 
Subject: Re: [Cellar] [Tools-discuss] I-D Action:
 draft-ietf-cellar-ebml-12.txt
References: <157167166904.31800.14436237517062444902@ietfa.amsl.com>
 <2259.1571680217@localhost>
 
 <7d488832-92f7-5e8c-896f-d4a3bb3ada61@levkowetz.com>
 
In-Reply-To: 

--4uDoTpChFoWiTqd2W5aHeadllnEBQJkBc
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Dave,

On 2019-10-21 21:37, Dave Rice wrote:
> Hi Henrik,
>=20
>> On Oct 21, 2019, at 2:28 PM, Henrik Levkowetz  w=
rote:
>>=20
>> Hi Dave,
>>=20
>> On 2019-10-21 20:22, Dave Rice wrote:
>>> Hi Michael,
>>>=20
>>>> On Oct 21, 2019, at 1:50 PM, Michael Richardson >>> > wrote:
>>>>=20
>>>>=20
>>>> Dave, is ebml in XML v3, uploaded as such?
>>>=20
>>> It was uploaded via https://datatracker.ietf.org/submit/.
>>>=20
>>>> Were the txt and HTML generated by you or the datatracker?
>>>=20
>>> With xml2rfc 2.32.0 locally the files look ok, I=E2=80=99m attaching =
them.
>>>=20
>>> I haven=E2=80=99t tested but in the XML within the  we ha=
ve 0x0A for line=20
>>> breaks. I wonder if an 0x0d (carriage return) would make a difference=
, though I=20
>>> feel guilty using up version numbers just to test that.
>>=20
>> Using 0x0D will not make a difference.
>>=20
>> I've run into this for at least one other draft, and I believe that th=
e
>> upcoming new datatracker release deployment will pull in the latest xm=
l2rfc
>> and address this.
>>=20
>> I will do some additional testing in my dev copy, though.
>=20
> Is there a way to tell which version of xml2rfc is used in the datatrac=
ker at any particular time? It would be helpful to ensure my local testin=
g matches.

The generated HTML file should have the xml2rfc version in a meta tag:



Best regards,

	Henrik

> Dave
>=20
>> Best regards,
>>=20
>> 	Henrik
>>=20
>>>>> A diff from the previous version is available at:
>>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cellar-ebml-12
>>>>=20
>>>> looking at the diff of the txt, there are a bunch of relative refere=
nces which=20
>>>> did not
>>>> get expanded correctly from the markdown:
>>>>=20
>>>>   unknownsizeallowed attribute (#unknownsizeallowed)).
>>>=20
>>> I=E2=80=99ll address that separately.
>>>=20
>>>> Looks like a tooling issue somewhere.
>>>> Looking at this:
>>>> https://www.ietf.org/id/draft-ietf-cellar-ebml-12.html
>>>>=20
>>>> I don't see #unknownsizeallowed in the same way, but the reference t=
hat is
>>>> generated looks off to me.
>>>>=20
>>>> --
>>>> ]               Never tell me the odds!                 | ipv6 mesh =
networks [
>>>> ]   Michael Richardson, Sandelman Software Works        |    IoT arc=
hitect   [
>>>> ] mcr@sandelman.ca  http://www.sandelman.ca=
/        |=20
>>>>  ruby on rails    [
>>>>=20
>>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> ___________________________________________________________
>>> Tools-discuss mailing list
>>> Tools-discuss@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tools-discuss
>>>=20
>>> Please report datatracker.ietf.org and mailarchive.ietf.org
>>> bugs at http://tools.ietf.org/tools/ietfdb
>>> or send email to datatracker-project@ietf.org
>>>=20
>>> Please report tools.ietf.org bugs at
>>> http://tools.ietf.org/tools/issues
>>> or send email to webmaster@tools.ietf.org
>>>=20
>>=20
>> _______________________________________________
>> Cellar mailing list
>> Cellar@ietf.org
>> https://www.ietf.org/mailman/listinfo/cellar
>=20
>=20


--4uDoTpChFoWiTqd2W5aHeadllnEBQJkBc--

--wJKroo1t9T3AdDmhv6i75ErP0UTQvwIIg
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl2uCX0ACgkQTptXS4+7
Fxqhzw/+InMd+ubMKnbkcWOwW03ZNLoHhWqVySVopyrJKW+PL0b0eBus4F4kcehO
//hh4OVO0a6Zp3ZUGVO+xqh/2YFjPgLdaK93jq5iqa37+rer7TEy3NMu9ZVPYLOF
OEvce+deQs+b0PaEnwn9fjjpt7nbivdOt/I6IzrC/D7geQrPiwuFW9WHLjVcXCF8
ZdN464fdlERgwH+EPuol2rzrvub0AAY+CpXGKSVoR6vmanUaqKtVYFrifGR4zs6D
fGaeL6VBIyGobIP7ZhbKPX6lmTMqiXWGdi4ZtY3+jjQvpbRfFJ31rQCIposnCNmU
pVUoOqkYneNXWZm5VR5PNHqhKWwPUA38oXnbx64atIlzJMpnd8X0mt4YulFH2aNf
CAw294MR3iBrWpEU7sFelqPHA27WuzqfHjOTiOF3kPH5DNPxAGU0yBP5akosvNTk
aVFWzd3GKfgYZCp67wEcA0v7VR8qcQ5CDv8zFMabmrYTXFDeLb2eqSjARageTyuP
SdAcYBy7w4LZf+1X9DT3SwQXZ9MwFl9lP8UUr9Sf28uoTnOAbHPgzKzS1h2A6xUj
FF8/BUR7brAmhBoWc40PD/eCgbEmfCp7jpxa828tKn1KlBEW95ZPUJtV1nBLIEUn
6/Ijhmg9RpDzb7kEI9NLoeiH2zZFbD3DhMH9UVIDHY0H189dYCA=
=JKUU
-----END PGP SIGNATURE-----

--wJKroo1t9T3AdDmhv6i75ErP0UTQvwIIg--


From nobody Mon Oct 21 12:45:55 2019
Return-Path: 
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 245E91208C3; Mon, 21 Oct 2019 12:45:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 hXGPI_5DacOK; Mon, 21 Oct 2019 12:45:41 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 2C1E2120860; Mon, 21 Oct 2019 12:45:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1571687071; bh=AEzExdO46XpKfK60v7Pa8jnRRaqWMKiqawbe8oyy1p8=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=a2R/+/xHb3+cFW11x9DcPF4zBBPtNeQ2Xe5FJpaTwJMiYaA8PZYVxmIdnt8JyXGFt rKe1w3MkTeDqg7fVNfIJUnobe/4rl0o6oY36v7dBGCBmUHqW/24OKa2X8tYesuTeMS wNBrrCc3Krsw64chm2S99UmLSQJwyCLhFgEcYOj4=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.124] ([217.251.143.142]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MFbRs-1iEQvx0EGc-00HA7F; Mon, 21 Oct 2019 21:44:31 +0200
To: Henrik Levkowetz , Dave Rice 
Cc: cellar@ietf.org, tools-discuss@ietf.org
References: <157167166904.31800.14436237517062444902@ietfa.amsl.com> <2259.1571680217@localhost>  <7d488832-92f7-5e8c-896f-d4a3bb3ada61@levkowetz.com>  
From: Julian Reschke 
Message-ID: 
Date: Mon, 21 Oct 2019 21:44:29 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:6Vm06aimjB3pH2UBgO5gHlQvwfWYf/bcoQOwdBWDayEMX2FB+Vv Nwow/b5Z5ZC8MP2CtDWgQwKcYh3FpQoBLvItMJ1d4G0eXF2GHGpKe+MmzC39pmOpkfhU/we veDk1+gGNTWNhPSYqQkQ8c1jH6/2U30cGoAwE5/N9GqwhSPyaOaD1yi6DrY2gMQbXeOCLgS BGKXCg2gZOoINyxVGquoA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:Ko/K3aMSPg4=:+xUdpIkYLwbyq9suySM7nx vMQEqJYXKf49397Wwpu4qTAvdfFFgC8/NY1eZtvs9nSLex/MdfY1NMmdGWiOnM0CggPmGC1MZ 99BCvaB9kul1JfjMM2/LPnouYlO1nI8SUnVzlRJm91cIv2qwaAbJ6fRTjjM5T1KWfrsC6pIa3 A+XDo8ZbEJgKo7v+BP40xuF5V7qm7qNwE1b/rGgKZEIPx73TGjefwAJOZPdyL+Xue/1quIXlu SP86t9yz/oW06AjfantiPxC4tgMMO7KiEclOGmSaOMJ/ccvycYiptanEzKjHeJ0jcv45Vn+kO LPO8DMY+OyOk9Cvd7xWFZASVJlGuFUn7ekKWHAi4n08dLhFj65ksh85ENvWvuIb6hLsLjnyIO +P9ZjbnuASjypZz72sTy23D7+Ij73Yc4kuKOlO7ZeguW0WvV0aCyZabW6Vn0gNF7YVaOVsybO 7Ug9/w3XoHFdLF5cok/ZyAV/d5cfNOBEkPZd8V3VL98KToAo7fwBSmE3Zp2ELapl4VEox0z2R TKxpEj02Y/eSJq3DIHsv118kmOHPl7VVHohbBfFibd/zWjoVsNi1NB8l/bF787lCS90Wzg4ol q8kGzVUHZKoq26oAgJDanAMlkj83Hmi0DdudQbAyi6v7023RGBkJC4gfFxdC4JSlqN2MeDL02 xaQvWuhyma6wz2NMpSpXtFtuUhlGikg/EvcIH+OMbEPnaW+QoeMaO1QsJ+abRR9djPEik311O n/ij4l45MOo78w7g3aPftN2EVjPRpQt5M5hCHR28pqe3ijBWgZaNBHqhIEihbbo+8kD14g2By vwCqIS167ObiAtKpzDkOI8NgOmeNPUYTDop+VQW21omWnWTnrUXJuBMwyiHh9D52RFdybi9Fy 7pVK3VDzbe7Y0Qo3ATt2q1rHnsL9QNUBsG9McF0WX46j+5YTLoYojkiBWL5HFWAaRfAb272J3 Azayx7L3xSXyGKuIT+DmCwC/7L3F3976AEir2DWlnDP7QWjqkaBoYxgHeexlrOAHTaeQpOR/s FjT6yRXT35ya58XwOGDRsuSPtDMojzNWwK2eKCClU+1tnGjFGQkuflue1V037KImsQapNPhZO gzAGdT1WOjPajpSqdu1BsrZTAFgIeHjArvIwaUdL1/a8Ws7g+XclzGwyOzTqE9yRmpDskcavN sNYvUyGcQLE4sQra0YVrjlWy+NshQmYUUo7lulUdXXe5Bvz/DezqFh7I0vnvkTGfUny2Bb/PK arswYcs+dO+4h2nvJNUR7HPDc74Qwl3CGbc50KdR1cBvx6uF7tTTJIvOz/rY=
Archived-At: 
Subject: Re: [Tools-discuss] [Cellar] I-D Action: draft-ietf-cellar-ebml-12.txt
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2019 19:45:44 -0000

On 21.10.2019 21:39, Henrik Levkowetz wrote:
> ...
>> Is there a way to tell which version of xml2rfc is used in the datatrac=
ker at any particular time? It would be helpful to ensure my local testing=
 matches.
>
> The generated HTML file should have the xml2rfc version in a meta tag:
> 
> ...

 shows the issue
and has a generator tag of 2.32.0.

Best regards, Julian


From nobody Tue Oct 22 03:49:13 2019
Return-Path: 
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33E331201EA for ; Tue, 22 Oct 2019 03:49:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.899
X-Spam-Level: 
X-Spam-Status: No, score=-2.899 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rub.de
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 6P9WDvXNX572 for ; Tue, 22 Oct 2019 03:49:09 -0700 (PDT)
Received: from out2.mail.ruhr-uni-bochum.de (out2.mail.ruhr-uni-bochum.de [IPv6:2a05:3e00:c:1001::8693:2ae5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C140120086 for ; Tue, 22 Oct 2019 03:49:09 -0700 (PDT)
Received: from mx2.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by out2.mail.ruhr-uni-bochum.de (Postfix mo-ext) with ESMTP id 46y9H61pBKz4xkZ for ; Tue, 22 Oct 2019 12:49:06 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rub.de; s=mail-2017; t=1571741346; bh=SJyf6tNSbPUd/kG6OLJV0dbjnVc6QjbNCiI6z0jmw+U=; h=To:From:Subject:Date:From; b=dxlbrxj8O+zVSsQ25KkGsYZfp1IusxR6dYdOIJ6LYkcr9/DyiMSH22xP982CKbapL fH/WVYxYWeRMFvihZj4OhRL0MG5hQ7Tvz0b2DThZJbMAKHhB5CXVudF8yt8p1eY6wP MRSeuzBk6nKzJBKMKQGvgnEyzEmvMuWviEnfFA7o=
Received: from out2.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by mx2.mail.ruhr-uni-bochum.de (Postfix idis) with ESMTP id 46y9H608b1z4xnp for ; Tue, 22 Oct 2019 12:49:06 +0200 (CEST)
X-Envelope-Sender: 
X-RUB-Notes: Internal origin=134.147.42.227
Received: from mail1.mail.ruhr-uni-bochum.de (mail.ruhr-uni-bochum.de [134.147.42.227]) by out2.mail.ruhr-uni-bochum.de (Postfix mi-int) with ESMTP id 46y9H56R2jz4xkZ for ; Tue, 22 Oct 2019 12:49:05 +0200 (CEST)
Received: from [IPv6:2a05:3e00:9:2100:999e:8979:16ac:d7da] (dyn-ad7dca619798e99900129000.nds.ipv6.ruhr-uni-bochum.de [IPv6:2a05:3e00:9:2100:999e:8979:16ac:d7da]) by mail1.mail.ruhr-uni-bochum.de (Postfix) with ESMTPSA id 46y9H45zzdzyvC for ; Tue, 22 Oct 2019 12:49:04 +0200 (CEST)
To: tools-discuss@ietf.org
From: Marcus Brinkmann 
Message-ID: <66f87f5f-7ed1-3092-e112-5de8cb3036c7@rub.de>
Date: Tue, 22 Oct 2019 12:49:05 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.4 at mail1.mail.ruhr-uni-bochum.de
X-Virus-Status: Clean
Archived-At: 
Subject: [Tools-discuss] Broken HTML output
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Oct 2019 10:49:12 -0000

Hi,

Please see https://tools.ietf.org/html/rfc7515#section-4.1.8 for some
problem in the HTML version of the RFCs.

The section header is:
"x5t#S256" (X.509 certificate SHA-256 thumbprint) Header Parameter.

Possibly due to the use of the hash sign (which is also used as the
anchor for page links), the rendering of the page is incorrect.

Thanks for providing the tools pages!

Marcus

-- 
Dipl.-Math. Marcus Brinkmann

Lehrstuhl für Netz- und Datensicherheit
Ruhr Universität Bochum
Universitätsstr. 150, Geb. ID 2/461
D-44780 Bochum

Telefon: +49 (0) 234 / 32-25030
http://www.nds.rub.de/chair/people/mbrinkmann


From nobody Tue Oct 22 04:18:40 2019
Return-Path: 
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C64EA1201E3 for ; Tue, 22 Oct 2019 04:18:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 NFb-p313GSFk for ; Tue, 22 Oct 2019 04:18:32 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 863B812081C for ; Tue, 22 Oct 2019 04:18:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1571743097; bh=q0HTHvYOJEmfMk4GvDsleoxK1VA53PUwRWlxTJdEkdg=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=Y2AP2LKWdz3iZPmnqbkW078qT2yCeKqEsPIhvoyPprKZ7zK9q6lVpg9SI6sXjSih9 k0BVVLeD/QrnnQtX8F3M5QnArcEwlTrdq+8DJ16/ZZ9loDTn76CzTkoYWozo485YIm IzyhO2tTqxFqXzJyBRdxJs4nEoUlLNcHVpP728Rk=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.1.81] ([217.91.35.233]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MacOQ-1hknWc2zJC-00cCvz; Tue, 22 Oct 2019 13:13:04 +0200
To: Marcus Brinkmann , tools-discuss@ietf.org
References: <66f87f5f-7ed1-3092-e112-5de8cb3036c7@rub.de>
From: Julian Reschke 
Message-ID: <034ce10b-b1e4-e264-df3f-d9121b5d5af0@gmx.de>
Date: Tue, 22 Oct 2019 13:13:00 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <66f87f5f-7ed1-3092-e112-5de8cb3036c7@rub.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:fEWOM45pnj1npUwh39pefde3M166s1gfo8y2SMbdtKZdZTqizgB NVg3A9NP7B/YhACUS7nwx6OrcgZGCNuDyJGpDDigSk1zgw+RyozPe3efwUhvNfO7owNiveS z9Fregl+k4XiXx81gbK3jakRNnM5oQrqwqlrPcmz06xMbdYeuWAkirm+oIddgXWHCipecNy cci5+oxle5PhafPjbI3FA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:6YTdmsi8JL8=:PMyrjxpTnyxNPK71PnLzOl 36yDHsCqk97nY/vMiG9g/oyR2lIN9n18ZuaHi6fFP3j3FMaWOLBdJQfGJGeL8EYw+44YuyxdA /l50iJYu+eWmZOOyRyjEjjL2mp4rioZ7201SqaSOspk4ULnhOB5Z1K98Mbj2b8LNpvCR0m1Yv LbwAxFUdQ9CGR5GWRj3zxfQz2B2dqi/vCR5VuS1E9q4bjxxM1ulKEoRipxTV79da4Y4Jv38LJ mm0djrOuEvRAycKSndc0hqfqIApRMFMcx4gfSbiecsrTNIoeEli98UkiEvK/mmeEXJHH6WMYe tJBR5Tqz3Mr38Aqxopt1Itqzcj91GgNz1XIjbfPhNSQtfUCSxEecMt+zYLY4ZpN7MJG92tupH 7XzOFMvJGFHOGY7P5xM9aXLyhxqCgAPivVfbbLIxZILI8PTg4VkceKpJvamIRLFx/e1Z45AgP MJbmUzVeQzMPlSkiUMALIC59BTTMkq59Nm/mjVYl8ti4ZW01EP8DJFqqkDSuIjoDRhoRN++wj eUqIPmOuWz72BHq2cU09I2iwY8hVj4mtM9ZSATowJlwmBjJ9ztGJmRnB7QmyTtGPX+QLxKHOe GIJPQC8pTtBtLyHFNyIIeSUP8YtlbV7qB0f0uBlegjT81Df3av2ozGooGuqi5BlNGEBMsE9wB tf3NE7gAUspHQ0+RX7ZXOhycjWe1X5v8Jy/+OPYF8ILdrnsGE62IcmsIyxPgJUGN+27yPsywl u3I2W+U+mJZSZuysN58hupaI97FDDTT9XDuQ4DagVA7gfmDmFVpHBcXv7ssEIY2uFM0gSnA/d 9l8lY5cO666YxygjqE8FWlMtiPbBQ5yZjSlJM71hEKosSlsFMh0BzlhzkloRKvgq17XeDdlr4 HK+9/6rJm7VxE/0P4by+E9scvjF9lDLj98h/NoamSCScUf4jyv7hMWsi3SwzN4L0CwK4LUEVQ RKetLPCegAfP4s/3K534J3/Vn5FhiSjec6i4zCyPtp7nMBEofaE24b3Xpyx+ZEuNhJWCW4axS HRa32knOs8xT46dIzj/X9RMHSmZqFpvGrIAoZMjLpaKO8oQPJtb3nEvfahCGunVgGIuTtu96j vDhZfWLGo03+QDzcqPaBBwDVu7p6pNxDJPI3ufuLThHoGS1wbRuZEJXsTPz9iHHeM3bap40ou OHGJgeMensxW6x8+LOuBvYGcMTb6nRgL8QCRx4Jw5luIuSI3f3QBKRz4FAclJu+1edIXg5zMr lICaOU+e1J82TF2zx6PR6zOXl9e0D1A/jRH2F7Q7fQqaG/qxx56hv9r/D8QA=
Archived-At: 
Subject: Re: [Tools-discuss] Broken HTML output
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Oct 2019 11:18:33 -0000

On 22.10.2019 12:49, Marcus Brinkmann wrote:
> Hi,
>
> Please see https://tools.ietf.org/html/rfc7515#section-4.1.8 for some
> problem in the HTML version of the RFCs.
>
> The section header is:
> "x5t#S256" (X.509 certificate SHA-256 thumbprint) Header Parameter.
>
> Possibly due to the use of the hash sign (which is also used as the
> anchor for page links), the rendering of the page is incorrect.
>
> Thanks for providing the tools pages!
>
> Marcus

...in Chrome, failing for multi-line section titles. I don't think this
has anything to do with the "#"; it's a CSS issue that was raised some
time ago already.

Best regards, Julian



From nobody Thu Oct 24 23:18:39 2019
Return-Path: 
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E06F1200F8 for ; Thu, 24 Oct 2019 23:18:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 JGHa_5BbzXTo for ; Thu, 24 Oct 2019 23:18:34 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 8E69512006F for ; Thu, 24 Oct 2019 23:18:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1571984210; bh=wWsugAkn33tnso8AnyHZUUAKFqvV2hhsZEwSdEj9Ir8=; h=X-UI-Sender-Class:Subject:From:To:Cc:References:Date:In-Reply-To; b=QXYf9c0NwUfYS7W/RZQSWWNRY4/lkvZvGfZO+8zgnAtNpwMxRLgyL2baVj/vt/NFO 4UhClYcajpdM5WeDsog7sdxFjLp5fTc49NWRg3Ft4TBPGQydckWyXRd5RBYbN9M5w6 drDIWcwZxwz1tqiINiKT19NrwP11Rq2J138sxu+8=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.124] ([84.171.151.92]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MgNct-1hnARJ1Bd9-00hune; Fri, 25 Oct 2019 08:16:50 +0200
From: Julian Reschke 
To: Dave Rice , Henrik Levkowetz 
Cc: rfc-interest , tools-discuss@ietf.org
References: <20285.1568652805@localhost> <705AA16B-68B1-4B5E-AE47-0714F6781C1A@dericed.com> <26105.1568818137@localhost>  <1268.1568828850@localhost>  <15814.1569013442@localhost> <3a8f5865-9f5c-8c65-63be-bca31c5f1c86@levkowetz.com> <3650B5EF-A442-4291-928A-2FCB2144134C@dericed.com> <06122b6d-d5f9-30b9-2db4-a2427d299a1f@levkowetz.com>  <97e68838-ac0c-25e4-67a9-a2a998b6e8af@gmx.de>
Message-ID: <3ef6a53c-e18a-9fc7-8324-67f388acd32f@gmx.de>
Date: Fri, 25 Oct 2019 08:16:45 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <97e68838-ac0c-25e4-67a9-a2a998b6e8af@gmx.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:MBnJAnVKOgM+sjCWIdFt2lyL84dXkIg63W5f9p0iG2MBbzzi6gk ey0/NMAsCmueR+gv8mgHF6XjYeKXz0OSsd9zHIrC4s1KX91ke1f7EdD71h1qT1eDZfkqdPG seHJVYVEYFKEMyKpeqObTJBBnyWOJBiqaIbhHAXFIcL4S+1j+jvqN3SaSS6zXzN9DwrI+lu 03e6ul0w6Oar6X5MinjsQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:om9Edv4WLmA=:93xq7t0leOVvFtWFw7qR3l OXKbHgt9PD437BXTm2/QZhFbBxIl/OwnOXfNl42k6u4ORZ3kZkfBbHw/991uH2QfAkpePJcP+ rxrQnu2fKlV48NCD6T8zZQX+gz8HlSVpcpo7sf0+H0DObxFEIwe3DEjw12U9rc8TGcpg1bqP4 fYFH2vRbgx73uhp3B3Gzesa1/G2kmf6L8Q84fgtuu4I/eTGfrT4XTJrDetLb12Qke4Z4re02M evo3mKL8pIqm88CjhkJcDyyzDOCqEgJ+6GkEZ2jLEBo4hyex0qdmNSZGOc2ICuD40gjBLYjaV 7+0+jDnfqWY+OaVeCRmzHjsSN2yXsBzKIjmc5Lb33v2ivBinULtntWJALBx3ic+QhASH5eWoT rOHfuNID5NA9mg/cNcd5q3wb/aFmtF/eTGsQus8j63nSobSec3QeUNuxNImDbtRrKUgNvJalb wywVj/f1T1q8CWEW2sQ3x+d+rHSSn36daqafxn6Jm3Pzxzsvsv7dN6JCDFSlIK2rFwOWVJN0F +0StPzomoLJ9cjx/zj8I4WOXfbanYCVMnL5Ymt4q2HzLe8hgOswTWttLpAvIuuvDflNqpQ0q+ ShdM3I3TkT72gMebPzhmMgGBMgaQoHAeRu0KK+CWd+sZnFyoB6IWwDZvc23tYIZ7Aq9TAynM/ H7AKt0R1+8SE4j6DVZwaz6c89X0LxsFqSnQDkseeDjB3BtqBbZ9K3QldZtm99KCyPpvVp+k5k hkhRdcr5JhKxoNpQGYrXeaYoYf5dmXGUOBIUXP2XWxQADdZAl7b37Qboskqq9HLidY86baW5X xoxoZoOmkmMl2Rc9UtVg6Y8m3WwnhfTq7xQv7H1Kk/zB/oW0C2DfhEQazYFApQKnqy3xFYSSm TapfjUykPtFjvLmbB2EMUaUCTPQUXU3J6ajTGADecKAOjME8/9a2jPVo+iZJhSAuYTn2tFyUL 2gp0DaaZC7S/UxCTqsNfjizXuha3aOJLgkmHpaKwO3Co/hMph1/H7LBM9sQK5nGzSL+gnt/rY sLwxAKa1C2lpteUSn8JyVBCSTxrpK4kXIk1wQ6fmwlqSQOYxU4XwIm8jLXkVBgWoFuutzAnOK bNGME9SxdHGFBDpRIWaHj+BSNJJOfkgf+0eQ5i21yWsGFuaMxqlzqYS2DCL2zyrIhzH+0H+I/ rXdlrtWU6n5uit9WV34TvUpDxa+sLKK4WdCLwUsAmHgpjQAhyAFMk+yOY2fEM/H2QwwoeMNfP lbszT88bsluOycA44sGr85myUx7SHkPG5EmzySVQiEMtxg9US5RQ2zxivyOA=
Archived-At: 
Subject: [Tools-discuss] missing line ends in generated TXT (from datatracker)
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2019 06:18:37 -0000

On 21.10.2019 18:46, Julian Reschke wrote:
> On 21.10.2019 18:14, Dave Rice wrote:
>> Hi all,
>>
>>> On Oct 9, 2019, at 1:38 PM, Henrik Levkowetz >> > wrote:
>>>
>>> Hi David,
>>>
>>> On 2019-10-09 17:32, Dave Rice wrote:
>>>> Thanks Henrik,
>>>>
>>>>> On Sep 20, 2019, at 5:26 PM, Henrik Levkowetz >>>> > wrote:
>>>>>
>>>>> Hi Michael, David,
>>>>>
>>>>> On 2019-09-20 23:04, Michael Richardson wrote:
>>>>>>
>>>>>> Dave Rice > wrote:
>>>>>>> Another annoyance here is the the xml processor in the submission
>>>>>>> tool
>>>>>>> and the xml processor at
>>>>>>> https://xml2rfc.tools.ietf.org/experimental.html
>>>>>>>  perform
>>>>>>> differently,
>>>>>>> so there=E2=80=99s effectively no test environment to use before s=
ubmitting.
>>>>>>> Dave
>>>>>>
>>>>>> Dave, can you please try xml2rfc.ietf.org
>>>>>> , which is a different installation,
>>>>>> supported by a different entity?
>>>>>
>>>>> Michael: =C2=A0Umm, no, that redirects to tools.ietf.org
>>>>> , too, and the processor
>>>>> behind that, and behind
>>>>> https://xml2rfc.tools.ietf.org/experimental.html,
>>>>> _and_ behind the submission tool are all the latest release of
>>>>> xml2rfc.
>>>>>
>>>>> David: I'd be happy to look into any discrepancies you see, but I
>>>>> can only
>>>>> do so if you provide observations and input XML files for me to work
>>>>> with. =C2=A0It won't happen if I don't know about it :-)
>>>>
>>>
>>>> When I use the tool at https://xml2rfc.tools.ietf.org or
>>>> https://xml2rfc.tools.ietf.org/experimental.html, the plain text
>>>> output appears ok, but when I use
>>>> https://datatracker.ietf.org/submit/
>>>> , the contents of the
>>>>  elements (which are new in xml2rfc version 3) have their
>>>> line breaks stripped out and thus cause an error when the line length
>>>> limits are exceeded.
>>>
>>> That sounds like a bug.
>>>
>>>> For the moment, I=E2=80=99m proposing a find and replace to convert t=
he newer
>>>>  elements back to  elements as in
>>>> https://github.com/FFmpeg/FFV1/pull/171/commits/a018f091534678f45cc15=
7bfd154518ad6267c7e
>>>>
>>>> ,
>>>>
>>>> thus an xml2rfc version 2 processor or version 3 processor should
>>>> proceed accurate results though not as semantically clear in the
>>>> xml.
>>>>
>>>>> FWIW, if you have atools.ietf.org login, you
>>>>> can use the xml2rfc
>>>>> issue
>>>>> tracker athttps://trac.tools.ietf.org/tools/xml2rfc/trac/newticket,
>>>>> for
>>>>> xml2rfc issues, andhttps://trac.tools.ietf.org/tools/ietfdb/newticke=
t
>>>>> for datatracker issues.
>>>>
>>>> I don=E2=80=99t have a login, but I=E2=80=99ll see if I can make a ti=
ny test file for
>>>> this issue and file a concise ticket.
>>>
>>> Please don't put time into this; I'm perfectly happy to work from the
>>> xml
>>> file you found problematic on submission. =C2=A0Just let me know the n=
ame
>>> of the
>>> draft in question, so I can pull it.
>>
>> I just uploaded this new version of the EBML specification to the
>> datatracker.
>>
>>
>> On lines 559-609 and 824-939 there are  nodes that contain
>> multi-line xml expressions. During the upload the idnit test showed no
>> issues or nits at all. =C2=A0However in the resulting files at
>> https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/12/=C2=A0the ou=
tputs
>> remove the line-breaks of the multi-line xml within the 
>> nodes. So in the HTML version the  is shown as a single
>> line, see
>> https://www.ietf.org/id/draft-ietf-cellar-ebml-12.html#name-ebml-schema=
-example,
>>
>> and in the plain text as well, see Section 11.1.1 of
>> https://www.ietf.org/id/draft-ietf-cellar-ebml-12.txt.
>>
>> In another document, I have been find/replacing the  node
>> with the older  node as a workaround.
>>
>> Best Regards,
>>
>> Dave Rice
>> ...
>
> I had the same problem and reported it as
> .
>
> Best regards, Julian

Henrik,

could you please let us know what the status is? Does it make sense to
retry now?

Best regards, Julian


From nobody Sat Oct 26 09:03:21 2019
Return-Path: 
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F441200B5 for ; Sat, 26 Oct 2019 09:03:20 -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_HELO_NONE=0.001, 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 fV2Zx2z3jT4C for ; Sat, 26 Oct 2019 09:03:17 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43E0312004E for ; Sat, 26 Oct 2019 09:03:17 -0700 (PDT)
Received: from [192.168.217.110] (p5089AE1C.dip0.t-ipconnect.de [80.137.174.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 470m3l2b6SzybH; Sat, 26 Oct 2019 18:03:15 +0200 (CEST)
From: Carsten Bormann 
Content-Type: text/plain; charset=utf-8
X-Mao-Original-Outgoing-Id: 593798234.413775-588f9fe8c5d4f83b9cfe14d7a62ddd48
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Sat, 26 Oct 2019 18:03:14 +0200
Message-Id: <31DB1003-A913-4F31-9C41-50C0636382F6@tzi.org>
To: "tools-discuss@ietf.org" 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: [Tools-discuss] Xml2rfc web service at https://xml2rfc.tools.ietf.org/experimental.html does not do v3 plaintext
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 26 Oct 2019 16:03:20 -0000

FYI: I cannot make the xml2rfc web service at =
https://xml2rfc.tools.ietf.org/experimental.html work for v3 plaintext.  =
It complains that it cannot encode a character in ascii, but I didn=E2=80=99=
t specify ASCII, I asked for plaintext.

Gr=C3=BC=C3=9Fe, Carsten


From nobody Sat Oct 26 09:24:11 2019
Return-Path: 
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 932841200B6 for ; Sat, 26 Oct 2019 09:24:10 -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_HELO_NONE=0.001, 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 ZsrQt6WPbJfb for ; Sat, 26 Oct 2019 09:24:08 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C004120024 for ; Sat, 26 Oct 2019 09:24:08 -0700 (PDT)
Received: from [192.168.217.110] (p5089AE1C.dip0.t-ipconnect.de [80.137.174.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 470mWp5JyfzyQp; Sat, 26 Oct 2019 18:24:06 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann 
In-Reply-To: <31DB1003-A913-4F31-9C41-50C0636382F6@tzi.org>
Date: Sat, 26 Oct 2019 18:24:06 +0200
X-Mao-Original-Outgoing-Id: 593799802.057294-345fbdf80dd3444fce49a477637a3781
Content-Transfer-Encoding: quoted-printable
Message-Id: <300D8DE9-7372-4978-ABB9-64809BBCBC65@tzi.org>
References: <31DB1003-A913-4F31-9C41-50C0636382F6@tzi.org>
To: "tools-discuss@ietf.org" 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [Tools-discuss] Xml2rfc web service at https://xml2rfc.tools.ietf.org/experimental.html does not do v3 plaintext
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 26 Oct 2019 16:24:11 -0000

On Oct 26, 2019, at 18:03, Carsten Bormann  wrote:
>=20
> FYI: I cannot make the xml2rfc web service at =
https://xml2rfc.tools.ietf.org/experimental.html work for v3 plaintext.  =
It complains that it cannot encode a character in ascii, but I didn=E2=80=99=
t specify ASCII, I asked for plaintext.

Ha, the tail of the traceback is:

 File "/usr/local/lib/python2.7/dist-packages/xml2rfc/util/postal.py", =
line 179, in get_normalized_address_info
    writer.note(x, "Postal address check failed for author %s." % =
full_author_name(author, latin))
  File "/usr/local/lib/python2.7/dist-packages/xml2rfc/writers/base.py", =
line 1735, in note
    self.log(self.msg(e, label, text))
  File "/usr/local/lib/python2.7/dist-packages/xml2rfc/writers/base.py", =
line 1677, in log
    xml2rfc.log.write(msg)
  File "/usr/local/lib/python2.7/dist-packages/xml2rfc/log.py", line 28, =
in write
    write_err.write(' '.join(args))
UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in =
position 95: ordinal not in range(128)

So it wanted to complain in ASCII about an author, but couldn=E2=80=99t, =
because the author isn=E2=80=99t an ASCII person.

(BTW, I=E2=80=99m still trying to figure out the postal address messages =
for the ASCII authors.)

Source file: =
https://tools.ietf.org/id/draft-ietf-core-resource-directory-23.xml

Gr=C3=BC=C3=9Fe, Carsten


From nobody Sat Oct 26 10:02:14 2019
Return-Path: 
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2BD1200DE for ; Sat, 26 Oct 2019 10:02:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.096
X-Spam-Level: 
X-Spam-Status: No, score=-1.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=no 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 Nycel_0DNZJz for ; Sat, 26 Oct 2019 10:02:12 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87E531200C5 for ; Sat, 26 Oct 2019 10:02:12 -0700 (PDT)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:54897 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1iOPRn-0006L1-2V; Sat, 26 Oct 2019 10:02:11 -0700
To: Carsten Bormann , "tools-discuss@ietf.org" 
References: <31DB1003-A913-4F31-9C41-50C0636382F6@tzi.org> <300D8DE9-7372-4978-ABB9-64809BBCBC65@tzi.org>
From: Henrik Levkowetz 
Message-ID: <4e926c4e-d47b-94e5-0874-87b8ec242d8a@levkowetz.com>
Date: Sat, 26 Oct 2019 19:01:42 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <300D8DE9-7372-4978-ABB9-64809BBCBC65@tzi.org>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="w3Xs3j9o58O1pOOToDHxx3ILjWXUG9HQ5"
X-SA-Exim-Connect-IP: 158.174.202.242
X-SA-Exim-Rcpt-To: tools-discuss@ietf.org, cabo@tzi.org
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org)
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: 
Subject: Re: [Tools-discuss] Xml2rfc web service at https://xml2rfc.tools.ietf.org/experimental.html does not do v3 plaintext
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 26 Oct 2019 17:02:13 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--w3Xs3j9o58O1pOOToDHxx3ILjWXUG9HQ5
Content-Type: multipart/mixed; boundary="ear4DqaukGeko0Qtv0ctK48n6QkXfdfL1";
 protected-headers="v1"
From: Henrik Levkowetz 
To: Carsten Bormann ,
 "tools-discuss@ietf.org" 
Message-ID: <4e926c4e-d47b-94e5-0874-87b8ec242d8a@levkowetz.com>
Subject: Re: [Tools-discuss] Xml2rfc web service at
 https://xml2rfc.tools.ietf.org/experimental.html does not do v3 plaintext
References: <31DB1003-A913-4F31-9C41-50C0636382F6@tzi.org>
 <300D8DE9-7372-4978-ABB9-64809BBCBC65@tzi.org>
In-Reply-To: <300D8DE9-7372-4978-ABB9-64809BBCBC65@tzi.org>

--ear4DqaukGeko0Qtv0ctK48n6QkXfdfL1
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Carsten,

This is baffling.  If I download this file and run it locally, I don't ge=
t
any errors, but the web service should be using the latest release, so I
wonder where the difference is.  I'll dig further.

	Henrik

On 2019-10-26 18:24, Carsten Bormann wrote:
> On Oct 26, 2019, at 18:03, Carsten Bormann  wrote:
>>=20
>> FYI: I cannot make the xml2rfc web service at https://xml2rfc.tools.ie=
tf.org/experimental.html work for v3 plaintext.  It complains that it can=
not encode a character in ascii, but I didn=E2=80=99t specify ASCII, I as=
ked for plaintext.
>=20
> Ha, the tail of the traceback is:
>=20
>  File "/usr/local/lib/python2.7/dist-packages/xml2rfc/util/postal.py", =
line 179, in get_normalized_address_info
>     writer.note(x, "Postal address check failed for author %s." % full_=
author_name(author, latin))
>   File "/usr/local/lib/python2.7/dist-packages/xml2rfc/writers/base.py"=
, line 1735, in note
>     self.log(self.msg(e, label, text))
>   File "/usr/local/lib/python2.7/dist-packages/xml2rfc/writers/base.py"=
, line 1677, in log
>     xml2rfc.log.write(msg)
>   File "/usr/local/lib/python2.7/dist-packages/xml2rfc/log.py", line 28=
, in write
>     write_err.write(' '.join(args))
> UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in pos=
ition 95: ordinal not in range(128)
>=20
> So it wanted to complain in ASCII about an author, but couldn=E2=80=99t=
, because the author isn=E2=80=99t an ASCII person.
>=20
> (BTW, I=E2=80=99m still trying to figure out the postal address message=
s for the ASCII authors.)
>=20
> Source file: https://tools.ietf.org/id/draft-ietf-core-resource-directo=
ry-23.xml

 =20


--ear4DqaukGeko0Qtv0ctK48n6QkXfdfL1--

--w3Xs3j9o58O1pOOToDHxx3ILjWXUG9HQ5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl20e/cACgkQTptXS4+7
FxpCWBAAuqqrEsjhsOPKv+XexyHupkBVqrzN3i1GcUBLZ29LrwoX/6h9uUFqBXdH
zGB8Hg7eoMD7vCzLHa49TzzahXupYnbYlHC9ggv1TEKWAo2h85ivMVUrfz5ZToLo
2OmvXDHBACRRhL58HOBnE3wENU1MAZJ/4Z15VstF55ZOPYE0NOtO6/emMRLgb9HH
UBpAmDQKbh3j9aA9xxekt29d5smbQvB4+HKJirRE5qlBVwnY/qSfuJs6rkKtW2YP
eY4MHQz8/20OdwmRfpVBWHdiSOO2hNIXzjvJ4CbrA/ClxuhKvfL0ozhiyg33vFDW
XNqWBNOTsC4IgitcokwLqHY2jVjD2VAn5Gz3IT4HiopfGqHayWu7Mxa7PL6BYhGb
G11aO2NZaGMy060ahL+MvRkivcTMYB1GF6Gz6xfNQm3IHySXX7OqlRdnLx4IH0qa
fVX+GGZiQ7eHXPeLMLvZX/4Bk3Ekx4H1YCEm+yfVbCNDfE3I4kob+aRE76adPLOJ
zLD4R+Ul9BH5VViJ/2Z4FD5oNY5yiNMCGokfAhT0CN6F9h1e8z4v7D3Icqry2NoH
FP+4hNczL+N6XVxYI2Hp2kWsBahEbHFZiwk/EY9EcrWIAj44d8HzjaLgTnlpXxZ1
CTDI3PgUXlEdSVaiMLYjx1EQ8h1SX2Oj9aoMwFtDJlwsZubLaOI=
=bKwf
-----END PGP SIGNATURE-----

--w3Xs3j9o58O1pOOToDHxx3ILjWXUG9HQ5--


From nobody Sat Oct 26 10:57:57 2019
Return-Path: 
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7BA1200D5 for ; Sat, 26 Oct 2019 10:57:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.096
X-Spam-Level: 
X-Spam-Status: No, score=-1.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=no 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 jOtGsedCqxkn for ; Sat, 26 Oct 2019 10:57:54 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ACEA1200B6 for ; Sat, 26 Oct 2019 10:57:54 -0700 (PDT)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:55138 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1iOQJg-0004VD-Jo; Sat, 26 Oct 2019 10:57:53 -0700
To: Carsten Bormann , "tools-discuss@ietf.org" 
References: <31DB1003-A913-4F31-9C41-50C0636382F6@tzi.org> <300D8DE9-7372-4978-ABB9-64809BBCBC65@tzi.org> <4e926c4e-d47b-94e5-0874-87b8ec242d8a@levkowetz.com>
From: Henrik Levkowetz 
Message-ID: <3e5898d6-b220-a3e3-6aff-fd43305231bf@levkowetz.com>
Date: Sat, 26 Oct 2019 19:57:24 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <4e926c4e-d47b-94e5-0874-87b8ec242d8a@levkowetz.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qKcuDmM7mFNJ6H6nVNBmCIDeBFeFvDJC7"
X-SA-Exim-Connect-IP: 158.174.202.242
X-SA-Exim-Rcpt-To: tools-discuss@ietf.org, cabo@tzi.org
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org)
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: 
Subject: Re: [Tools-discuss] Xml2rfc web service at https://xml2rfc.tools.ietf.org/experimental.html does not do v3 plaintext
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 26 Oct 2019 17:57:56 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--qKcuDmM7mFNJ6H6nVNBmCIDeBFeFvDJC7
Content-Type: multipart/mixed; boundary="AQuOwiiddNav8MKlSAa3AR67QRv1stjLJ";
 protected-headers="v1"
From: Henrik Levkowetz 
To: Carsten Bormann ,
 "tools-discuss@ietf.org" 
Message-ID: <3e5898d6-b220-a3e3-6aff-fd43305231bf@levkowetz.com>
Subject: Re: [Tools-discuss] Xml2rfc web service at
 https://xml2rfc.tools.ietf.org/experimental.html does not do v3 plaintext
References: <31DB1003-A913-4F31-9C41-50C0636382F6@tzi.org>
 <300D8DE9-7372-4978-ABB9-64809BBCBC65@tzi.org>
 <4e926c4e-d47b-94e5-0874-87b8ec242d8a@levkowetz.com>
In-Reply-To: <4e926c4e-d47b-94e5-0874-87b8ec242d8a@levkowetz.com>

--AQuOwiiddNav8MKlSAa3AR67QRv1stjLJ
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Carsten,

Ok, I've put a temporary fix in place for the web service.  A more
permanent fix that deals correctly with ascii-only log output media
will be part of the next release.


	Henrik

On 2019-10-26 19:01, Henrik Levkowetz wrote:
> Hi Carsten,
>=20
> This is baffling.  If I download this file and run it locally, I don't =
get
> any errors, but the web service should be using the latest release, so =
I
> wonder where the difference is.  I'll dig further.
>=20
> 	Henrik
>=20
> On 2019-10-26 18:24, Carsten Bormann wrote:
>> On Oct 26, 2019, at 18:03, Carsten Bormann  wrote:
>>>=20
>>> FYI: I cannot make the xml2rfc web service at https://xml2rfc.tools.i=
etf.org/experimental.html work for v3 plaintext.  It complains that it ca=
nnot encode a character in ascii, but I didn=E2=80=99t specify ASCII, I a=
sked for plaintext.
>>=20
>> Ha, the tail of the traceback is:
>>=20
>>  File "/usr/local/lib/python2.7/dist-packages/xml2rfc/util/postal.py",=
 line 179, in get_normalized_address_info
>>     writer.note(x, "Postal address check failed for author %s." % full=
_author_name(author, latin))
>>   File "/usr/local/lib/python2.7/dist-packages/xml2rfc/writers/base.py=
", line 1735, in note
>>     self.log(self.msg(e, label, text))
>>   File "/usr/local/lib/python2.7/dist-packages/xml2rfc/writers/base.py=
", line 1677, in log
>>     xml2rfc.log.write(msg)
>>   File "/usr/local/lib/python2.7/dist-packages/xml2rfc/log.py", line 2=
8, in write
>>     write_err.write(' '.join(args))
>> UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in po=
sition 95: ordinal not in range(128)
>>=20
>> So it wanted to complain in ASCII about an author, but couldn=E2=80=99=
t, because the author isn=E2=80=99t an ASCII person.
>>=20
>> (BTW, I=E2=80=99m still trying to figure out the postal address messag=
es for the ASCII authors.)
>>=20
>> Source file: https://tools.ietf.org/id/draft-ietf-core-resource-direct=
ory-23.xml
>=20
>  =20
>=20
>=20
>=20
> ___________________________________________________________
> Tools-discuss mailing list
> Tools-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/tools-discuss
>=20
> Please report datatracker.ietf.org and mailarchive.ietf.org
> bugs at http://tools.ietf.org/tools/ietfdb
> or send email to datatracker-project@ietf.org
>=20
> Please report tools.ietf.org bugs at
> http://tools.ietf.org/tools/issues
> or send email to webmaster@tools.ietf.org
>=20


--AQuOwiiddNav8MKlSAa3AR67QRv1stjLJ--

--qKcuDmM7mFNJ6H6nVNBmCIDeBFeFvDJC7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl20iQQACgkQTptXS4+7
Fxq7UhAAryL+85ZkV8bLLjNufyBUYlAhHGtcXLFjWW60111XrSbVNAlZMDHH0NXR
lM/aS2k25V+42NIaUPW1GK5diV8ChaIZW6+GXQWSosSwGBCW5nHcw3LTkdBnLPCI
TVIALL+k07hAvo5U+UurHrBgsseshhu/Ns7y/YRS+z2fL/Jhtso8+KU2bv8T+bLi
zegri1zYS9hfVc3CI/PXJ7vRDow+TvlvdA+pqKR491ORoM/fe/7LcBX3OrIEzNfi
QQCvB96Vzx17P/cQlELgnOOqA8LGSybB2S5KYKaQyoXDQ5tM6K7GXbCYop5qVVPO
64E2+6irw+I3i2zpiNjuYpDEuawbPKYCc0Pj/JfsnovLOoTc8ncyScHIgMDqGG4u
joyp+bC05YMGAmakW6nqgpWgwXsT21QN91ttvHE+yx9lZ2JtuGz1f3yeReFCAETE
kroqjm3WN7BHdqQNijTCVd61TcsXoNrGtAVGxipKT8sNmUvO4ibxjN7UerqZgN43
G1r9yNNYuwkOdoSQKY9dnjPS0m2eAdqAkmEc202ZVYIuiJmS/QB3wMwh91Pa8NfX
9raJsCYFNsluITx4yzePWuCEa0Su0Z1Z+WgiSdmsW9G9shyAEVhYnkbhIv9+0Kne
BPNh+eKhcKidlue0Qm5SrSxl52rr1paoJMfdTkIAGcu2qrfmKRU=
=3/qg
-----END PGP SIGNATURE-----

--qKcuDmM7mFNJ6H6nVNBmCIDeBFeFvDJC7--


From nobody Thu Oct 31 08:04:47 2019
Return-Path: 
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC2912095D for ; Thu, 31 Oct 2019 08:04:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 tYQFhQ6FYtqE for ; Thu, 31 Oct 2019 08:04:36 -0700 (PDT)
Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640094.outbound.protection.outlook.com [40.107.64.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57D921208B8 for ; Thu, 31 Oct 2019 08:04:36 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GRJZ0sRaouSNdLsU4BOH3mg8m/k5J2sKDLJXojvyBg6HdmPRq2z9fzGlYTfBPSg89+zESN2Bk0bMv1dlJ8MCCIRV3QcgK6rgkJyAFrsvK22dGoNJ/2f3NvK0a9D3dSspTJlVl/+DsvMFM9dLrXxEShIdazr53tZxEnEwl9JigzdB4cTYxz5/r7QAL8PP5hRfnPEiTLq9AjeeEGCTRHdl9i3wLib+VARvpVznPn5sm84n0sDhLpNsKzhzru1UgPYQsSJw0kkfPDnJSgmbNJBKZJxWdD3Z3gq0+usWcxtU3Nm5nprKCNy2oWQkMJwdWcjtm05rxzoTSo+mIztJ2YOZow==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JEYSMzB0XMmIi44bAziz1AVLdIEwN0HuX+iVQiAclj8=; b=duDXkpZ4JPid9zUwJYHF4XzZb7e6zzVz1OD8pYu2eR/RPvVUca4xIcHcCrI30JsU5KQ7eFsV4Zj/geNoCeD2aMuGcbo42RuAL764TGXUGyWCnQeoNnJzd6gstoyCogIiETEtWzTKdxfcD/dnyAlyKLHeUSSTR8NmGfcytwWVNAnfc2JPMsQTy/1gXLvwTLL698onRDwz2y1n/80SCbtjRbBhLBVSiZENxiqanziUkanbGAj3h0Nzoznf2ZqKtLXsT9oNZmjm2739IT2Az6rwbqgiCWyyJbDgQMBoWyv7TJ2WXOr41cZ40E/GawOozNPP7mnFN7ubTDXsdchktBezjA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JEYSMzB0XMmIi44bAziz1AVLdIEwN0HuX+iVQiAclj8=; b=EaGWs4Rl73bKh1z9+zJfpF4AAsCxioCy0VAHx4sevmeT/8prXYfF6bZRkHMlx+eUEZ+myq4NEcuzHcct5XHYk+aLcmC6ZpkF2jRoRZe8hShAsSPOdeLswQgf+NXgHbzM0pbkvS5bftvM1ALBjSmMs/5LhwuqcyY5ueBa40Xr7eE=
Received: from DM6PR00MB0569.namprd00.prod.outlook.com (20.179.51.12) by DM6PR00MB0587.namprd00.prod.outlook.com (20.179.51.206) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2447.0; Thu, 31 Oct 2019 15:04:32 +0000
Received: from DM6PR00MB0569.namprd00.prod.outlook.com ([fe80::49:30:b130:e9b3]) by DM6PR00MB0569.namprd00.prod.outlook.com ([fe80::49:30:b130:e9b3%7]) with mapi id 15.20.2450.000; Thu, 31 Oct 2019 15:04:32 +0000
From: Mike Jones 
To: "tools-discuss@ietf.org" 
Thread-Topic: Please retain the online V1 xml2rfc tool
Thread-Index: AdWP+/DUcFUYE4SWS9iBOpeS1kJ55Q==
Date: Thu, 31 Oct 2019 15:04:32 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=7752dd7b-6d30-4f44-86ea-00004f80c2a3; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-10-31T15:00:05Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; 
x-originating-ip: [50.47.93.218]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: f85fb865-81b6-4dd8-3572-08d75e13a2d9
x-ms-traffictypediagnostic: DM6PR00MB0587:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 02070414A1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(396003)(346002)(136003)(366004)(189003)(199004)(52544003)(186003)(26005)(486006)(54896002)(6306002)(66066001)(236005)(55016002)(22452003)(476003)(6436002)(256004)(6116002)(6506007)(21615005)(102836004)(33656002)(5660300002)(7696005)(99286004)(71190400001)(316002)(9686003)(71200400001)(5640700003)(790700001)(3846002)(2351001)(2906002)(64756008)(66476007)(66946007)(76116006)(66446008)(66556008)(25786009)(86362001)(14454004)(606006)(7736002)(10290500003)(74316002)(52536014)(6916009)(966005)(4744005)(81156014)(81166006)(10090500001)(8990500004)(8676002)(8936002)(478600001)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR00MB0587; H:DM6PR00MB0569.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: a2+FahYbuNZZO5fhNdZOqTEILvg9mMb1A3Jbz3ABDSWni1EIeh53cTHaEvQJQUTLVavPJlAn427qCaBZsGhwgkzt9LLwn3muAz/t+UcZg2z7jC1jB8agq0iwOrHaXokkHcAMPCNltwtzfw3tiwRv97jn+QvIqgmYihv/Dc0kDY1C/7aVZvY3ecYZMRyRHqF50LK0v4mu2MP4m2Wx7KbUzRtgLod5mGVokq9w9Pr/R3GJZGflpK0FBFZE2voylgILK5SnNxj1UDUtSuKjae95cf/qWCAdIcfhoMR5ZT63S/qWce0E31IafkUV67i9Ri5Nu+v3lSsIELkhV7Qt0nVXDbRw7D6UwN22pBoq5kERM6RbrfsGyegGYgWJGWycBS1cP82LxX19CiH1un1+2BFWu9z7UuzujEnhRQj7m4ejs6NBcUizdkQsoslOsV4wbTtO
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_DM6PR00MB056999E64629D9CEA2D4A5AFF5630DM6PR00MB0569namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f85fb865-81b6-4dd8-3572-08d75e13a2d9
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2019 15:04:32.4188 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: gXqts4BcJ2LQ/GL71f0f5DwQnmHLepgSLASAXjQnv2ogANU8O0mrdm4ZKBC2o1jF+gMASMbFEFFxSgK1VEVTvw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0587
Archived-At: 
Subject: [Tools-discuss] Please retain the online V1 xml2rfc tool
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Oct 2019 15:04:42 -0000

--_000_DM6PR00MB056999E64629D9CEA2D4A5AFF5630DM6PR00MB0569namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

The V1 xml2rfc tool can currently be run at http://xml2rfc.tools.ietf.org/o=
ld.html.  I continue to use this to make errata updates to some legacy spec=
ifications by the OpenID Foundation.  (I need the V1 tool because it emits =
HTML fragment targets using the section "anchor" value, rather than as a se=
ction number, as the V2 tool does.)

As the http://xml2rfc.tools.ietf.org/ site is being updated to support V3, =
I would very much appreciate it if you could leave http://xml2rfc.tools.iet=
f.org/old.html as is.

                                                       Thanks,
                                                       -- Mike


--_000_DM6PR00MB056999E64629D9CEA2D4A5AFF5630DM6PR00MB0569namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable












--_000_DM6PR00MB056999E64629D9CEA2D4A5AFF5630DM6PR00MB0569namp_--


From nobody Thu Oct 31 08:23:35 2019
Return-Path: 
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89B0C120804 for ; Thu, 31 Oct 2019 08:23:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 YRI1j_vkjkpq for ; Thu, 31 Oct 2019 08:23:32 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 5B24F120811 for ; Thu, 31 Oct 2019 08:23:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1572535406; bh=aGc58pVLe203LzC1bGNwC71uLT/VinOIFik7h4RGb2o=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=aoSWIWMW8lFYRpDZu+aI4F+ADCbRmnRQSeWozAGcuikP0JrlRxoO3WMAxM0ye2g/0 T+cPR1qJbBIETF+tR/HRxKA163dDFb3R4rNkSEnVMB8J8FWgI37cfdwhol4t//AfiL h3+z0QTiGRWc3auiIE8y5dzWcTA0Ty0jEENkSiXA=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MXGvM-1iSodM1oqc-00YfWk; Thu, 31 Oct 2019 16:23:26 +0100
To: Mike Jones , "tools-discuss@ietf.org" 
References: 
From: Julian Reschke 
Message-ID: <606c568f-7830-8463-de6b-86340d111f9f@gmx.de>
Date: Thu, 31 Oct 2019 16:23:21 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:MS3mNUa/LgtQGgkX1Wv7sol/MAzNjzIbJO21ja2geMBOk/Hh74e 0bTNpv+l9TRmRq64+dS03HE0pzGKKZV8F+BY4bFEyC3RuQHrRejih6HwyMV9YDoCS5j27V2 CgbkX9/as/uHHZih1rnh5G8fhKTi56rudT+z5vBzIIoia2g4FnM8fZHz0TLeB+4PbrGwxFA PgmIjnJMTiptMsniVIFSw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:9aYu24FnWyI=:+A5/4NruHq7iWO+9FFLsvk zq8AQus7jBl2NFV8JQDmtG0yX7ONtFVaS65xteXBNKjJxx0pPvtQQCcmXPAS5OwcBQoDMlVay Y//p44Ss0pCSb9n53bbaG5CwkZNcnSsco+lRpWbnnTAjqWN9FaVVT0qj8N0cQ0n9KL7RYqykk lRUba90WwpbTYzjwsStndlvkiIP+cO84t/Brz8bAimtoDES4mGphg/q/4Y7i26QQpmnIgUOfN vnyhkiJFuimWesGmU1puTzINDzdW9scrEowTcipCrqFGyswxrXBYDUbdr38jkIDt//6t5UqVS s96+9fWPLTO5xyyPfDucvorwVGdo6wcbbAJSfok7KS4OCJ3GbAmFuUNhHb611GwOH7nUhIIJm iIw0A81w9r7+lr+rq/J68R1x7vjWL3m5q3Lb/QGPTK6ml7JP+sfvHGQI0a5L6qfvmHAZJZr9D bmFM2rfJ/4cVsx6riZa9rSIN9yoAEx1cimpaD5QkOQUBHyIzZVoPXzESUzJlzwieNV/zE0Cod ML/KBuviFryH48gMl/F8wgHUputZQChkHfBGcLL1FeLj6K4dU2Dl8aObtbuohrQfq9yElPH+2 h14DrCwe4pxSQ1ndmYVB9F+Yh50q6Zw8zr1BrtF7aIcytzJ7tgX2xdgAVkSYPCrb7A7FJztZR j3L1Stqz8KKTJEdYcU8p0cZeCys8DcBDbY4CB8JoW2osKs6Im+rZ7Jg6nNLnVy83keZlSE9h5 wVJmAKuk5yYsWs7XaKrffR7Fy7ar4UQOMC2Wbz2Qa5ylmRmSaaH4uGkX1J7qyY3luCRV0mRZa FEHPXduuj8X9jjMUSTVb/UvL9wCgoFMwJocmLOFbXD64QOPRLS6LIRx1hMtrBPUE8ArYi2ba6 IoDoauwO4ZyQsSSh9Us/T65vaKfRuDn2xErFtWOg6X7QQVAS0PPye3XrSzfRJiVWHDlYdVhMA nQNyXxdTjO7I+0hTvWAVXlGvkPLrQacQWKSoZ+k6NngwUDsoNzvHrZu3FyxwmpsPhiEsIMqfP XVaJ0pSFYju2V+5BaxYcSiZ3LzdK/SRAR7QnO6JRn/mWqjs8NPX/ernG5e2501x10DvERpnFF Iz7NzLwSbe5rvOj90EVSGbhILjtI1diV0S1FSQ/O48Y1NoGEPd9czkJN3oR8tho4U5Uj0XWuR 0TsMWyZGw5jINTawPoYG9nkceJF2enDQsCbZLo6jh2ULibK0/Dzjb45NpMkWayEp2+MkdYyeT n7yhK5WhEC8KMHZV/h4b9VrcyewILqXIComCG+f7feqvrBJxzruHZiOGW4Nk=
Archived-At: 
Subject: Re: [Tools-discuss] Please retain the online V1 xml2rfc tool
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Oct 2019 15:23:34 -0000

On 31.10.2019 16:04, Mike Jones wrote:
> The V1 xml2rfc tool can currently be run at
> http://xml2rfc.tools.ietf.org/old.html.=A0 I continue to use this to mak=
e
> errata updates to some legacy specifications by the OpenID Foundation..
> (I need the V1 tool because it emits HTML fragment targets using the
> section =93anchor=94 value, rather than as a section number, as the V2 t=
ool
> does.)

Hmmm, that is something all versions of xml2rfc should do. The only
difference might be the actual placement...

> ...

Best regards, Julian

PS: the V1 tools works just fine locally; all you need is a TCL
installation.


From nobody Thu Oct 31 11:11:53 2019
Return-Path: 
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58EFE12010F for ; Thu, 31 Oct 2019 11:11:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 wxA8mw9bZX_7 for ; Thu, 31 Oct 2019 11:11:49 -0700 (PDT)
Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650129.outbound.protection.outlook.com [40.107.65.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1A4512006A for ; Thu, 31 Oct 2019 11:11:49 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TlYXN5Qn+qQruwhryOkNFKD6gD6iTcFkmD4VP0cx18EtUyUl9ZMdwij92tA1otUpDfIyza9u9bvbj73KDXA1S5C5xjBnTsDDRJ5ZwHes/eE8dzQJjfCgtc/JJo6xcVschljfj6z3n07lWaSwq5h5sgv3X1lQbf1nNmulZFIm0hm1f2GOaaLk2w1ES9CsrvE++jhSS9criRnouF1GyB7yQ4EJ9six9yaz1Q1tMHCF+dCiEo5uzz/p8u7sPVS9QoqrSved2xvKS/3ihi9ELfH+B+TMPO9J1Qv0xlHGp4X0O4o+ib/o682tJv3oM4oTIUBbD+8wi32+3vto9SOln+feeA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pu5jo/OMf4RSGce1zf6E+sG/O9PFpX3TahHkKjic3DA=; b=jIhBzF3G3eNwIxb4hxo4j9SonYYPnw1mj8JI3tdz+OZE0xoW0I9tneZZLr1d11gCEPpm4imtj2NSyIF539CJglf+L9QyoRejqOjzdqhvulS/40Vn9qmztEFHlK57B1OlvhEYf+hd1ewRjEMlXANWnCUtUXZM3J6LjkLLmewW8nIBKCmSV8hMVhVUaNPyavFhX8Byje3S0iFWHHV/SstW5kcvJKtiOgpYstBuy3MZjf+fKyJ6tuPazoNhkBbUyTb+35DXro0kr6YkQQ1gyi8amCF0pjGSSSm3X+asSsQXaCSX4iiCTvoPK3l+Tc243YxTKnb7t4QSkA3MugM/yPaBQg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pu5jo/OMf4RSGce1zf6E+sG/O9PFpX3TahHkKjic3DA=; b=K1kUHmlefcafhMN5WL6l5OuVoBeEBSwjvE6/NRnyymn4NWm3KcX6JxZTVtHwK69pXDKkJCmwGsBkKV6iNfYk83oK1fe5kl93vYbtUUWRfwSFbXyJEBvOJF2/GbAV9yCwl5PrtW2dvgZ60JnXHHr2eIiscR5DGKRhy1fc2FMkMug=
Received: from DM6PR00MB0569.namprd00.prod.outlook.com (20.179.51.12) by DM6PR00MB0587.namprd00.prod.outlook.com (20.179.51.206) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2447.0; Thu, 31 Oct 2019 18:11:45 +0000
Received: from DM6PR00MB0569.namprd00.prod.outlook.com ([fe80::49:30:b130:e9b3]) by DM6PR00MB0569.namprd00.prod.outlook.com ([fe80::49:30:b130:e9b3%7]) with mapi id 15.20.2450.000; Thu, 31 Oct 2019 18:11:45 +0000
From: Mike Jones 
To: Julian Reschke , "tools-discuss@ietf.org" 
Thread-Topic: [Tools-discuss] Please retain the online V1 xml2rfc tool
Thread-Index: AdWP+/DUcFUYE4SWS9iBOpeS1kJ55QAAzAmAAAWdEHA=
Date: Thu, 31 Oct 2019 18:11:45 +0000
Message-ID: 
References:  <606c568f-7830-8463-de6b-86340d111f9f@gmx.de>
In-Reply-To: <606c568f-7830-8463-de6b-86340d111f9f@gmx.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=1eebc840-646d-4e63-8885-00004e3b06d5; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-10-31T18:04:05Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; 
x-originating-ip: [50.47.93.218]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 1a40b97a-abcb-456d-684b-08d75e2dca54
x-ms-traffictypediagnostic: DM6PR00MB0587:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 02070414A1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(376002)(136003)(396003)(366004)(189003)(199004)(52544003)(13464003)(15374003)(76116006)(86362001)(66946007)(66476007)(14454004)(66556008)(66446008)(25786009)(64756008)(2906002)(10090500001)(8936002)(8676002)(8990500004)(81166006)(81156014)(478600001)(74316002)(52536014)(7736002)(10290500003)(305945005)(966005)(2501003)(6306002)(55016002)(11346002)(476003)(6436002)(256004)(446003)(22452003)(6246003)(26005)(486006)(186003)(66066001)(9686003)(71200400001)(316002)(71190400001)(110136005)(102836004)(53546011)(6506007)(6116002)(76176011)(99286004)(229853002)(33656002)(7696005)(5660300002)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR00MB0587; H:DM6PR00MB0569.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: xKYAdD16DJ/dMNhW+CRBSWuoKMmTqY9uZS3WiLt7HX63rkpJ3S+3QICDNli1W6lOaM9+VObXyqTpIKhqMiDrCJ1sRyJyS3bzDG4fX9+/1TFLcPGTuyY4L7rVjVM4N+5zAh4ftZ4mCVXrEGXhn6vSKJ/x1SaRNBYy031VkYPPMW8QCLmNoGHr/z28xKDwIEL4r7nk0JktmhBB4qm3wyV1ZC/j2p0regTgebteyh+ApGILPayTDma6u7Dw/YKD76s9aSmZ/P7NMlYpsVDsO2YxEVTV8haGjpgORuCxdnWTES1+ZoCy/4OSS18n84kWEarfc5L9fSN91bJLbTpFeOCIZsPI9MmV5YgYZagLeOKV6TMyopdbxod302/Lipx3ixH819qpU04YeUYo5XZdvpu6uNb7yc48Us9lJKg5E1EPzOJ8/89Fg3OyuBviKSm1D4db
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1a40b97a-abcb-456d-684b-08d75e2dca54
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2019 18:11:45.5464 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: WhbZg0AvLSKlP5mNkWOv8cTKJwY3w2pGozByQALMk/IicD+SysWbu+FVEBwWDAg60a4J0KLy5rqKch4dVHFAyw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0587
Archived-At: 
Subject: Re: [Tools-discuss] Please retain the online V1 xml2rfc tool
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Oct 2019 18:11:52 -0000

There are many minor differences between the V1 and V2 output for HTML.  Th=
e table of contents format is different.  The font rendering for  values is different.  The color of artwork is different.  Etc.=
  So I really need to keep using V1 to obtain equivalent output for these l=
egacy specs.

Yes, if need be, I'll figure out how to make a local installation work.  Bu=
t as a favor, I'd really appreciate it if you left http://xml2rfc.tools.iet=
f.org/old.html in place.

				Thanks again,
				-- Mike

-----Original Message-----
From: Julian Reschke =20
Sent: Thursday, October 31, 2019 8:23 AM
To: Mike Jones ; tools-discuss@ietf.org
Subject: Re: [Tools-discuss] Please retain the online V1 xml2rfc tool

On 31.10.2019 16:04, Mike Jones wrote:
> The V1 xml2rfc tool can currently be run at=20
> https://nam06.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fxml2r
> fc.tools.ietf.org%2Fold.html&data=3D02%7C01%7CMichael.Jones%40microso=
ft.com%7Ccd1fbda0caf74f34ac5c08d75e164ab7%7C72f988bf86f141af91ab2d7cd011db4=
7%7C1%7C0%7C637081322171173303&sdata=3DUHHhiBCIKGKsGNnZ2Ct1XWluEYApLR1m=
Uj83rdq%2BrUM%3D&reserved=3D0.=A0 I continue to use this to make errata=
 updates to some legacy specifications by the OpenID Foundation..
> (I need the V1 tool because it emits HTML fragment targets using the=20
> section "anchor" value, rather than as a section number, as the V2=20
> tool
> does.)

Hmmm, that is something all versions of xml2rfc should do. The only differe=
nce might be the actual placement...

> ...

Best regards, Julian

PS: the V1 tools works just fine locally; all you need is a TCL installatio=
n.




The V1 xml2rfc tool can currently be run at 
http://xml2rfc.tools.ietf.org/old.html.  I continue to use this to=
 make errata updates to some legacy specifications by the OpenID Foundation=
.  (I need the V1 tool because it emits HTML fragment targets using th=
e section “anchor” value, rather than as a
 section number, as the V2 tool does.)


 


As the ht=
tp://xml2rfc.tools.ietf.org/ site is being updated to support V3, I wou=
ld very much appreciate it if you could leave
http://xml2rfc.tools.iet=
f.org/old.html as is.


 


        &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;        Thanks,


        &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;        -- Mike