From nobody Wed Jul 3 05:07:08 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B691120780 for ; Wed, 3 Jul 2019 05:06:58 -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, 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 tSvMcvleeCCv for ; Wed, 3 Jul 2019 05:06:56 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [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 9569B120796 for ; Wed, 3 Jul 2019 05:06:56 -0700 (PDT) Received: from localhost ([::1]:37163 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1hie2J-0006ZP-6S; Wed, 03 Jul 2019 05:06:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Cc: xml2rfc@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: henrik@levkowetz.com, julian.reschke@gmx.de X-Trac-Project: xml2rfc Date: Wed, 03 Jul 2019 12:06:55 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/410 Message-ID: <069.99cf962db7a68299f8412ab7314e0f58@tools.ietf.org> X-Trac-Ticket-ID: 410 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, julian.reschke@gmx.de, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: [xml2rfc] #410 (Version 2 cli): misdetected sentence endings X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 12:07:02 -0000 #410: misdetected sentence endings There are cases where sentence endings are detected when there actually is an abbreviation inside a sentence. In the TCL version, this relied on heuristics, and may produced better results. Note that removes the "insert two spaces" requirement, so maybe it's time to stop trying. -- -----------------------------------+---------------------------------- Reporter: julian.reschke@gmx.de | Owner: henrik@levkowetz.com Type: defect | Status: new Priority: medium | Milestone: Component: Version 2 cli | Version: 2.22.* Keywords: | -----------------------------------+---------------------------------- Ticket URL: xml2rfc From nobody Wed Jul 3 09:50:03 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B130212035B for ; Wed, 3 Jul 2019 09:49:53 -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 t9556oI3RDOZ for ; Wed, 3 Jul 2019 09:49:52 -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 DB3A112034F for ; Wed, 3 Jul 2019 09:49:51 -0700 (PDT) Received: from [192.168.217.110] (p548DC676.dip0.t-ipconnect.de [84.141.198.118]) (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 45f6XY5QLPzyXs; Wed, 3 Jul 2019 18:49:49 +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: <069.99cf962db7a68299f8412ab7314e0f58@tools.ietf.org> Date: Wed, 3 Jul 2019 18:49:49 +0200 Cc: henrik@levkowetz.com, julian.reschke@gmx.de, xml2rfc@ietf.org X-Mao-Original-Outgoing-Id: 583865387.335062-263e7e63a796fe856c65d5790c26a29f Content-Transfer-Encoding: quoted-printable Message-Id: <6F9A982C-B474-4C81-A0E2-BF0C3CAD36C9@tzi.org> References: <069.99cf962db7a68299f8412ab7314e0f58@tools.ietf.org> To: xml2rfc issue tracker X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [xml2rfc] #410 (Version 2 cli): misdetected sentence endings X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 16:49:57 -0000 On Jul 3, 2019, at 14:06, xml2rfc issue tracker = wrote: >=20 > stop trying =E2=80=A6 would mean that we get massive diffs once this is in effect. Don=E2=80=99t do that. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jul 3 10:28:39 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A69361202A7 for ; Wed, 3 Jul 2019 10:28: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 NUuJYmIQbQNX for ; Wed, 3 Jul 2019 10:28:35 -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 5C611120077 for ; Wed, 3 Jul 2019 10:28:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1562174903; bh=xTEfEqqNrNa6ZRNhiSlmBX0hPQuTrdIm7WbM813gcFQ=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=EWNsREbJNYPY8nyhf1sAk3rdZqu3aIPyWVFYLZQqGp5IRkX7fiJlDDyZA3WdWJW6W 2J7nOks/aWUhxT7F8dEnUgvHK2iv/u8V/qsnLwqnDwJ6UR0Zo0aGqZaY/rpm7r4aGD sEuKtbgnLnyZZkHR9RmroJbaPKsgMGSIh1Kg0Bkw= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([217.251.137.56]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MwwZX-1iTZHA2yKZ-00yTje; Wed, 03 Jul 2019 19:28:23 +0200 To: Carsten Bormann , xml2rfc issue tracker Cc: xml2rfc@ietf.org References: <069.99cf962db7a68299f8412ab7314e0f58@tools.ietf.org> <6F9A982C-B474-4C81-A0E2-BF0C3CAD36C9@tzi.org> From: Julian Reschke Message-ID: <9e9b2d14-dda8-c8f7-cf66-013a808806df@gmx.de> Date: Wed, 3 Jul 2019 19:28:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <6F9A982C-B474-4C81-A0E2-BF0C3CAD36C9@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:+nHioAyv5ag0brRjF/4wJylbP/EdfB8jFUq6zsDXG/ICZ17Mf0W PL4S0RQD8xfFZAS8TbVm+/5gHs6pR8yEhvmEky9r+y3ty+pkCmAPfWaXY8hXjUYgb2lgoCK 0wiv5amN/Xjk3VQUwOx+QPA7krqZVfCY/dZm3sgjz48iADbSOwv/AK10QxaJgxRBmHPD3GO BEL6oDZD9YRbwKmUCEmDQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:bAk3o91Cfss=:EJkpvHPIpaYa0lkW9wIll7 DOu9euLpxmyPpxBm4TAGpo1ZgHqd+nsW1M86C1upYkPC9EpTqBRzCt0m2mv30V0yXsQ5Nz+If OWmLhuojb8rcd2xMxBhPqriH+P8oGZ6ewaKg3N9zojtUAU7arVQcZQqpzMGuPgVi96N7jiQG3 OuosKTnb11X1swin2ceqj+tEARPD00ePZpdRX73l1ousN+TBCIRUA+lZ4gaaRIbFrAl6CZgKl Fxz5+LedNGwLv3o//UDBHPj0uGhEJUg94ZO1polli1CYvkhG+OpClwIX8Xx4A+HYhHZFvUIkO YdNqJMWk5S7S2s/khEFrN4AjmDk15gmgpiB8mMAgH43VUQF0EI5CjDjhSQli4rBEfySuxk+ph U8ne56FFKsA8WRac1Wv3d/QyED51T9tiBSechP+pdgKuzRt1srB6vI4B6ncbwALI+jIKqo2ZO 2QAZR7uJ0tBDHK5to3Eif44ZWunOfx4Zz63CBLQz2it+401f8bQ4jP42/0pYikngfZXUduCsZ tdlKabx3CMKQxwbAlKIVaSmA56qkg8GN7n/oC/B0bCEcHncOgvhaak+ccz8vLSJhKHxTTRExH 293LyDq4gP4Blxt1+8z2dxSe8mF65cJGWm37rLmATpXBnzQD/oV52S5mZCIQcWjO9XZ1zZ/v9 QDw/PEXZVWyo6VFLaIZ+vhM0HbnbwjseCBSl1Skehutr0KVjI1s8rpatc9IQO1mv3ehhkmFD6 ZAEBBQSNrpHXNwkKCF0wIa+MNuCJOf415DvZSAwFvx6I4J8jUPNuTLnueq9X+sZaR5IzE8m7a I950Vi5i71p9SPA9XlSuZ3xk8MRJEhbx4eZjrJokozMqj44G1FgukLspb3k84sIcUyAhZaFMT i6qGaQ6ejV8IQIP9tXJ4xQHf1VifUuHcahl2+esjusEizUqsC+X7YGZpbvtfzwxP9FSkVPyuO CThAN/IXAR2qdxyRLImpwLbgiqZAJm/wnwrbuNq4agUX+SGIvqwnGm3r9mu1M3NM/jtKrp9nq AoyT5o3tWuhRk6W02eibekK4zJPyZfAi9QSxMXBgED+YrGYOitWKrUpN/JIDucKDrsp16ePjB HuxpmODsi+tvGXQzTU3pXmWeLJdzJL+SELM Archived-At: Subject: Re: [xml2rfc] #410 (Version 2 cli): misdetected sentence endings X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 17:28:38 -0000 On 03.07.2019 18:49, Carsten Bormann wrote: > On Jul 3, 2019, at 14:06, xml2rfc issue tracker wr= ote: >> >> stop trying > > =E2=80=A6 would mean that we get massive diffs once this is in effect. > Don=E2=80=99t do that. > ... > Gr=C3=BC=C3=9Fe, Carsten > ... Well - the output right now is broken for many inputs (and I believe it's a regression from earlier versions (likely TCL)). It's also something that I assume gets fixed in the RFC Production Center (so it's another reason why published RFCs differ from xml2rfc's output). Once the the RFC Style Guide is published, this likely needs to go away anyway. At least if that happens before the new default publication format is in use. Best regards, Julian From nobody Wed Jul 3 10:43:58 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02BB912040E for ; Wed, 3 Jul 2019 10:43:57 -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 SeVcqnY7waJi for ; Wed, 3 Jul 2019 10:43:55 -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 41BF31203EE for ; Wed, 3 Jul 2019 10:43:55 -0700 (PDT) Received: from client-0078.vpn.uni-bremen.de (client-0078.vpn.uni-bremen.de [134.102.107.78]) (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 45f7kx5sxLzyXs; Wed, 3 Jul 2019 19:43:53 +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: <9e9b2d14-dda8-c8f7-cf66-013a808806df@gmx.de> Date: Wed, 3 Jul 2019 19:43:53 +0200 Cc: xml2rfc issue tracker , xml2rfc@ietf.org X-Mao-Original-Outgoing-Id: 583868631.706076-c0e789d56d243d5fe26974d2fddd5238 Content-Transfer-Encoding: quoted-printable Message-Id: <717EAF1D-9BAB-43BC-B034-78D1FCB8492C@tzi.org> References: <069.99cf962db7a68299f8412ab7314e0f58@tools.ietf.org> <6F9A982C-B474-4C81-A0E2-BF0C3CAD36C9@tzi.org> <9e9b2d14-dda8-c8f7-cf66-013a808806df@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [xml2rfc] #410 (Version 2 cli): misdetected sentence endings X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 17:43:57 -0000 I just wanted to remind people that gratuitous changes in this space = have real costs for people who are trying to get work done. Not more, = but not less either. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Jul 5 01:50:40 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007091202E3 for ; Fri, 5 Jul 2019 01:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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] 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 yPswOolaHlm4 for ; Fri, 5 Jul 2019 01:50:22 -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 39AC2120261 for ; Fri, 5 Jul 2019 01:50:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1562316602; bh=+TPhqQiC3U+a9dR2VKjZT0NU6fq156IiwVHZrngjFzo=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=VAmJ4dbuIwEFnN1VZJjrbVToMpHCeSBF13w8enR/41nmo2LPqMzdI6i4c74xqLBgR tf0XM1b4OW0Hv6gklyxXpv84R+qLiasCcBQl0OKjPV2AXwpPoRCRbiy8PJ+buKq+zR HYct6k/7u0osbHGWWFNpFHTdsU9HOilEtD+Dnwz8= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([84.171.155.69]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MAwbp-1hpfYu3MnB-00BNfJ; Fri, 05 Jul 2019 10:50:01 +0200 To: Carsten Bormann Cc: xml2rfc@ietf.org, xml2rfc issue tracker References: <069.99cf962db7a68299f8412ab7314e0f58@tools.ietf.org> <6F9A982C-B474-4C81-A0E2-BF0C3CAD36C9@tzi.org> <9e9b2d14-dda8-c8f7-cf66-013a808806df@gmx.de> <717EAF1D-9BAB-43BC-B034-78D1FCB8492C@tzi.org> From: Julian Reschke Message-ID: <06f333ad-03ed-4b7a-8c10-8a91cdb8d71f@gmx.de> Date: Fri, 5 Jul 2019 10:49:56 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <717EAF1D-9BAB-43BC-B034-78D1FCB8492C@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:VAloF8KCo6cn2+7rUXteHxq8ga9Ao4Qm149OWNd1K9YFONTm0Zp SU/Q8pW4KhOdOfI+nd8Io9ZDHiR4bP7KLuwsyrT5lOz4+1MXnMAj3NFkNfpAorG9LJDo4Cp zQmYdoVcjQ+H2v53B84piRRJSCVK1lzwlG8/UOkqj3/hMUjRIvJsH+FzyvbcGvxYpmC2Sv1 sz/TUTOde2d5Y+BCpfAaQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:q0jYvsd7jqg=:mtUpDskR9ohw6Fp3KeMVga ZwbgnHDsHHDUXU9VOap6VyQCOhK3JSH8kXjpr0ezzOrX8QeCiVyEQ4aZD6cx4rLW++q/eRFdS VuDWJrGLF21Zy2ATuJjUjoTod4V5glC0qj1fvfAXm9w469kda79xoNbOWeOgMLteQaXrnXWIB Kh/nXjQ1a3kfWNPUsZcvucKwas5LoU8Zpcgxq9TuSCEVnVdCDwYuV55/b7JYyN5dHatAW5UWa MFHn9R//yA9w4Dso9xXWOMWv/azmLUh9W2OkSwvymTvkSLVzFVVwCZCPaQld0jl8SBFjxrEBs oGngz73ULuGCyyqmE8FH2GgYy1xSaXlhxOfQv91HqzgznosV3MvrnkUEWNV98Ee29YXoVf6SQ +lDXIhYTnIiKe0j7BiB3IYOVUXK025tNS6jXRYfgtv47MHPLW5B6jl/rDm/bIakzwQjZD7usx bbWDmFAKDhJGC2WZ0GLSfqTnZgsfDnMypME9ALnDF2IisOMqxccMB561jH4KtwI7kaEIQ+f+D EL5iC3Dh1jzPI5hxpqEvgYF4znoNtr0xRqLhwHQAXofQkoW2ZiG6TiHlQdky+c74zQEGbhTqm c5DJ5eLH1ZzkRL5TdbbKGDzwzct+fFSXL9p1Kgo137djCJrLvxFJw00Kc9J66n1j0UHD8ULiv 93/+5JCOeM55Kv1+79KjAuxDsEUrl+Kq8NRte+5P4dnKTu/1dUjf1Wh3c2qpk/c0aZgaeBTcb EDN7y+6cqhW8vBBhsvhOSjEjasTBmlGap3f4MWaE9MlbGQHuK3KHLw1C9OwunfO6mcFfE9YNx zO159rYxIx73p/7z75vVYXpH53rXzdISgBTbsuyAwaslTzKT9JgFKYPBxgRcyJdVSqz4ysWJi caVmFsldkusITbiy+0QVXv0pEqx5+Hq+hUxNY+tet3irJE3ZnidF277JthvUq7YGVjpWKR7lN Jgsq8MAtg8KWj+0AwoUJ9AolNcMS8po2xisfdV/taaf+IJWZHdkhX4idCpDPpS2D8YivEhxdQ JdAtghzo80Lkc24aGsOFVxMP1nRqkp4c2iIVCZY3JgyLEpefOZc9GPSkPHOZgU+TO/Dw4A/sh e0Cwuth1jep+DOfdEhuGJWcoIhd2ChXu/jW Archived-At: Subject: Re: [xml2rfc] #410 (Version 2 cli): misdetected sentence endings X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 08:50:38 -0000 On 03.07.2019 19:43, Carsten Bormann wrote: > I just wanted to remind people that gratuitous changes in this space hav= e real costs for people who are trying to get work done. Not more, but no= t less either. > > Gr=C3=BC=C3=9Fe, Carsten Yep. This might be an opt-in (by xml2rfc version number, or by processing instruction). Best regards, Julian From nobody Sun Jul 7 06:38:46 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FDC012003E for ; Sun, 7 Jul 2019 06:38:44 -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 M1K2dJbe8A2h for ; Sun, 7 Jul 2019 06:38:42 -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 AB45F12002E for ; Sun, 7 Jul 2019 06:38:42 -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 1hk7NI-0004Tk-F6 for xml2rfc@ietf.org; Sun, 07 Jul 2019 13:38:40 +0000 Date: Sun, 07 Jul 2019 06:38:40 -0700 Message-ID: From: Randy Bush To: XML2RFC Interest Group 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: [xml2rfc] url X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 13:38:44 -0000 xml2rfc 2.23.0 is this still a proper reference? randy, who got a python traceback and is suspicious of this as cause From nobody Sun Jul 7 10:29:20 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FEEA12004F for ; Sun, 7 Jul 2019 10:29: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 QC68MG_6ffhr for ; Sun, 7 Jul 2019 10:29:17 -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 12105120043 for ; Sun, 7 Jul 2019 10:29: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 1hkAyQ-0004nt-Pl for xml2rfc@ietf.org; Sun, 07 Jul 2019 17:29:15 +0000 Date: Sun, 07 Jul 2019 10:29:14 -0700 Message-ID: From: Randy Bush To: XML2RFC Interest Group In-Reply-To: References: 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: [xml2rfc] url X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 17:29:19 -0000 xml2rfc 2.23.0 this diagnostic is a bit obscrure $ xml2rfc draft-ietf-lsvr-l3dl.xml --html --text Parsing file draft-ietf-lsvr-l3dl.xml Traceback (most recent call last): File "/usr/local/bin/xml2rfc", line 10, in sys.exit(main()) File "/Library/Python/2.7/site-packages/xml2rfc/run.py", line 389, in main xmlrfc = parser.parse(remove_pis=options.remove_pis, normalize=True) File "/Library/Python/2.7/site-packages/xml2rfc/parser.py", line 618, in parse include=True, line_no=getattr(element, 'sourceline', 0)) File "/Library/Python/2.7/site-packages/xml2rfc/parser.py", line 240, in getReferenceRequest result = self.cache(path) File "/Library/Python/2.7/site-packages/xml2rfc/parser.py", line 347, in cache hash = '-'+base64.urlsafe_b64encode(hashlib.sha1(query)) if query else '' File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/base64.py", line 101, in urlsafe_b64encode return b64encode(s, '-_') File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/base64.py", line 53, in b64encode encoded = binascii.b2a_base64(s)[:-1] TypeError: must be string or buffer, not _hashlib.HASH make: *** [all] Error 1 source is at https://git.rg.net/randy/draft-l3dl/src/master/draft-ietf-lsvr-l3dl.xml randy From nobody Sun Jul 7 11:57:18 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38444120075 for ; Sun, 7 Jul 2019 11:57:15 -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 bHbj6eoBzd2B for ; Sun, 7 Jul 2019 11:57:12 -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 6F9F8120071 for ; Sun, 7 Jul 2019 11:57:12 -0700 (PDT) Received: from [192.168.217.110] (p548DC676.dip0.t-ipconnect.de [84.141.198.118]) (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 45hd9f2D9xzybV; Sun, 7 Jul 2019 20:57:10 +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: Sun, 7 Jul 2019 20:57:09 +0200 Cc: XML2RFC Interest Group X-Mao-Original-Outgoing-Id: 584218627.934622-13617cb89aba64fe4132312d62366554 Content-Transfer-Encoding: quoted-printable Message-Id: <77F6A44C-4405-42A9-9CF0-E9C86EF10F3C@tzi.org> References: To: Randy Bush X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [xml2rfc] url X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 18:57:16 -0000 On Jul 7, 2019, at 19:29, Randy Bush wrote: >=20 > hash =3D '-'+base64.urlsafe_b64encode(hashlib.sha1(query)) if query = else '' This must be a problem with the recent caching fixes in xml2rfc, it = tries to base64-encode the query, but that isn=E2=80=99t a string=E2=80=A6= I don=E2=80=99t have a problem with xml2rfc 2.22.2. (The JUPITER bibxml generated from the DOI by xml2rfc.tools works.) Gr=C3=BC=C3=9Fe, Carsten PS.: I still get the occasional=20 requests.exceptions.ConnectionError: (=E2=80=98Connection aborted.', = BadStatusLine('No status line received - the server has closed the = connection',)) Then I just retry=E2=80=A6 From nobody Sun Jul 7 12:05:51 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7836D1201CA for ; Sun, 7 Jul 2019 12:05:32 -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 stsHB-Ivm2YP for ; Sun, 7 Jul 2019 12:05:30 -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 9209B120071 for ; Sun, 7 Jul 2019 12:05:30 -0700 (PDT) Received: from [192.168.217.110] (p548DC676.dip0.t-ipconnect.de [84.141.198.118]) (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 45hdMD5BG6z100g; Sun, 7 Jul 2019 21:05:28 +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: <77F6A44C-4405-42A9-9CF0-E9C86EF10F3C@tzi.org> Date: Sun, 7 Jul 2019 21:05:28 +0200 Cc: XML2RFC Interest Group X-Mao-Original-Outgoing-Id: 584219124.463051-5d407e0364fad46cbf0544509fecad38 Content-Transfer-Encoding: quoted-printable Message-Id: References: <77F6A44C-4405-42A9-9CF0-E9C86EF10F3C@tzi.org> To: Henrik Levkowetz X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [xml2rfc] url X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 19:05:50 -0000 On Jul 7, 2019, at 20:57, Carsten Bormann wrote: >=20 >> hash =3D '-'+base64.urlsafe_b64encode(hashlib.sha1(query)) if query = else '' >=20 > This must be a problem with the recent caching fixes in xml2rfc, it = tries to base64-encode the query, but that isn=E2=80=99t a string=E2=80=A6= Bug report: I think this should be something like >> hash =3D = =E2=80=98-=E2=80=98+base64.urlsafe_b64encode(hashlib.sha1(query).digest())= if query else =E2=80=98=E2=80=99 Sorry for not tracking down where the trac is=E2=80=A6 Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Jul 7 12:32:52 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 258AA120041 for ; Sun, 7 Jul 2019 12:32:50 -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, 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 ch8Oy4Sywf-R for ; Sun, 7 Jul 2019 12:32:47 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [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 C0831120033 for ; Sun, 7 Jul 2019 12:32:47 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:58031 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 1hkCtw-0000iH-Kn; Sun, 07 Jul 2019 12:32:46 -0700 To: Randy Bush , XML2RFC Interest Group References: From: Henrik Levkowetz Message-ID: <5a9aae82-6051-6f6e-f217-af06cb0a7ffa@levkowetz.com> Date: Sun, 7 Jul 2019 21:32:33 +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="hJ0elMmrTQxAlPi02vo9js65IBk4CXGWw" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc@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: [xml2rfc] url X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 19:32:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hJ0elMmrTQxAlPi02vo9js65IBk4CXGWw Content-Type: multipart/mixed; boundary="tDP8MoMdjEpCTxc3rdUcUdnqQX7GXFVua"; protected-headers="v1" From: Henrik Levkowetz To: Randy Bush , XML2RFC Interest Group Message-ID: <5a9aae82-6051-6f6e-f217-af06cb0a7ffa@levkowetz.com> Subject: Re: [xml2rfc] url References: In-Reply-To: --tDP8MoMdjEpCTxc3rdUcUdnqQX7GXFVua Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Randy, Thanks for the traceback. Will debug, fix, and let you know about possible workarounds. Henrik On 2019-07-07 19:29, Randy Bush wrote: > xml2rfc 2.23.0 >=20 > this diagnostic is a bit obscrure >=20 > $ xml2rfc draft-ietf-lsvr-l3dl.xml --html --text > Parsing file draft-ietf-lsvr-l3dl.xml > Traceback (most recent call last): > File "/usr/local/bin/xml2rfc", line 10, in > sys.exit(main()) > File "/Library/Python/2.7/site-packages/xml2rfc/run.py", line 389, in= main > xmlrfc =3D parser.parse(remove_pis=3Doptions.remove_pis, normalize=3D= True) > File "/Library/Python/2.7/site-packages/xml2rfc/parser.py", line 618,= in parse > include=3DTrue, line_no=3Dgetattr(element, 'sourceline', 0)) > File "/Library/Python/2.7/site-packages/xml2rfc/parser.py", line 240,= in getReferenceRequest > result =3D self.cache(path) > File "/Library/Python/2.7/site-packages/xml2rfc/parser.py", line 347,= in cache > hash =3D '-'+base64.urlsafe_b64encode(hashlib.sha1(query)) if query= else '' > File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/py= thon2.7/base64.py", line 101, in urlsafe_b64encode > return b64encode(s, '-_') > File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/py= thon2.7/base64.py", line 53, in b64encode > encoded =3D binascii.b2a_base64(s)[:-1] > TypeError: must be string or buffer, not _hashlib.HASH > make: *** [all] Error 1 >=20 >=20 > source is at > https://git.rg.net/randy/draft-l3dl/src/master/draft-ietf-lsvr-l3dl.xml= >=20 > randy >=20 > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc >=20 --tDP8MoMdjEpCTxc3rdUcUdnqQX7GXFVua-- --hJ0elMmrTQxAlPi02vo9js65IBk4CXGWw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl0iSNEACgkQTptXS4+7 FxqJcxAAkrRFuygTU6cDnD0kWTComcITyS1ko+bAi7jJ1SMhJ+uxN2p44FCijVyA MvBXkQZddQoqwu4JULjWlU/EEHswXDkqc3HwLHaxx/AAEmiFI6sFTt4zK0/1uHMI yQXWtAw28MpKAW+xM/uVNV7w9hJXSOJ/Okasw/fZBWyACy5rEu0SZESW22/olmWZ EwZGvV9OqkfzgPNkQW3YOuwguFUtzYDK9Zo2lv+YLWTucLa+11kd49Lyu5Ju0X8f ZOEIeWHfMyrvmoHldAXylCyGf57Ts0AYn2HJEWukMnNA+ApGPLcaCLFpscNKFzcz GmR20FFZ4r0H/niacfp0BWwAU9R1cqR2ZZpmplXUlbBY6wy/DNCwxfiUw9o8zEyE YvQxfOa6q2jeqKhnxkTVleYF8u5k+/+TSEco8n5YNtWVYYUsxY6+helRSlxQiFAe mAg1uVpj+2dYNAvmkp1RRN5xwT48H2AvxYf0yl/qoPeRGzcNFaG8L0FLeyNe1aor UOiAZmfTCg4afb44MxX5RdJDkf//nMBjbC0oOg7/Fe5MztIsB3hO9NnE+A6yK0Hs u8cRgzG95Pt8DO7GNBveyDLU91TlHkqxbE19UhX9w38lMqeSV16CEpBji18TamOL 1LQDDHHOi7Kra/Z7UW/AKdwd3OLYQ1oV7LBKLZp58eapkdzyh9Q= =nvLw -----END PGP SIGNATURE----- --hJ0elMmrTQxAlPi02vo9js65IBk4CXGWw-- From nobody Sun Jul 7 12:33:38 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E987B1201D2 for ; Sun, 7 Jul 2019 12:33:35 -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 GPlhqTo5DVR6 for ; Sun, 7 Jul 2019 12:33:34 -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 DFD87120071 for ; Sun, 7 Jul 2019 12:33:33 -0700 (PDT) Received: from [192.168.217.110] (p548DC676.dip0.t-ipconnect.de [84.141.198.118]) (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 45hdzb6dzwzyWF; Sun, 7 Jul 2019 21:33:31 +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: Sun, 7 Jul 2019 21:33:31 +0200 Cc: XML2RFC Interest Group X-Mao-Original-Outgoing-Id: 584220809.7859451-a8249fc3b25f360368165abd325fa675 Content-Transfer-Encoding: quoted-printable Message-Id: References: <77F6A44C-4405-42A9-9CF0-E9C86EF10F3C@tzi.org> To: Henrik Levkowetz X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [xml2rfc] url X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 19:33:36 -0000 On Jul 7, 2019, at 21:05, Carsten Bormann wrote: >=20 > Bug report: I think this should be something like >=20 >>> hash =3D = =E2=80=98-=E2=80=98+base64.urlsafe_b64encode(hashlib.sha1(query).digest())= if query else =E2=80=98=E2=80=99 With 2.23.0, I actually get hash =3D '-'+base64.urlsafe_b64encode(hashlib.sha1(query)) if query = else '' TypeError: Unicode-objects must be encoded before hashing (Python 3.7.3) So this needs more than the change I was proposing (don=E2=80=99t = laugh): hash =3D '-' + = base64.urlsafe_b64encode(hashlib.sha1(query.encode()).digest()).decode() = if query else '' (Python 2 compatibility left as an exercise to the reader.) Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Jul 7 15:42:57 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9929C120157; Sun, 7 Jul 2019 15:42:43 -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, 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 4ThxmK4af7G3; Sun, 7 Jul 2019 15:42:42 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F28C12013B; Sun, 7 Jul 2019 15:42:42 -0700 (PDT) Received: from henrik by durif.tools.ietf.org with local (Exim 4.80) (envelope-from ) id 1hkFrl-0002gS-S3; Sun, 07 Jul 2019 15:42:41 -0700 To: xml2rfc-dev@ietf.org, xml2rfc@ietf.org Cc: rfc-markdown@ietf.org Message-Id: From: Henrik Levkowetz Date: Sun, 07 Jul 2019 15:42:41 -0700 X-SA-Exim-Connect-IP: X-SA-Exim-Rcpt-To: rfc-markdown@ietf.org, xml2rfc-dev@ietf.org, xml2rfc@ietf.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: [xml2rfc] New xml2rfc release: v2.23.1 X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 22:42:44 -0000 Hi, This is an automatic notification about a new xml2rfc release, v2.23.1, generated when running the mkrelease script. Release notes: xml2rfc (2.23.1) ietf; urgency=medium * Fixed a bug in the handling of sha1 and base64 methods when generating cache names for references with query arguments. * Updated the license file to more strictly follow the BSD 3-Clause license, and changed the license field in the setup.py file to be more precise. -- Henrik Levkowetz 07 Jul 2019 22:39:11 +0000 The preferred way to install xml2rfc is by doing 'pip install xml2rfc', and 'pip install --upgrade xml2rfc' to upgrade. If there are system- installed python modules which pip will not upgrade, you may have to use 'pip install --upgrade --no-deps xml2rfc' and install dependencies manually. The new version is also available through SVN checkout, with 'svn checkout http://svn.tools.ietf.org/svn/tools/xml2rfc/tags/cli/2.23.1' Regards, Henrik (via the mkrelease script) From nobody Sun Jul 7 15:43:24 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5E0612017C for ; Sun, 7 Jul 2019 15:43:21 -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, 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 mowgUadiJBWM for ; Sun, 7 Jul 2019 15:43:20 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [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 0461512011A for ; Sun, 7 Jul 2019 15:43:20 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:59836 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 1hkFsJ-00008j-V5; Sun, 07 Jul 2019 15:43:18 -0700 To: Carsten Bormann References: <77F6A44C-4405-42A9-9CF0-E9C86EF10F3C@tzi.org> Cc: XML2RFC Interest Group From: Henrik Levkowetz Message-ID: <2f947e06-f57e-e0f2-7467-24f6f303cae4@levkowetz.com> Date: Mon, 8 Jul 2019 00:43:06 +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="HPaF04dLEdlln7MD2IiM7ClaFcTW99erL" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc@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: [xml2rfc] url X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 22:43:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HPaF04dLEdlln7MD2IiM7ClaFcTW99erL Content-Type: multipart/mixed; boundary="ALLp1sRUGIk0hC9QNqmwUAdAO3RUOqOI1"; protected-headers="v1" From: Henrik Levkowetz To: Carsten Bormann Cc: XML2RFC Interest Group Message-ID: <2f947e06-f57e-e0f2-7467-24f6f303cae4@levkowetz.com> Subject: Re: [xml2rfc] url References: <77F6A44C-4405-42A9-9CF0-E9C86EF10F3C@tzi.org> In-Reply-To: --ALLp1sRUGIk0hC9QNqmwUAdAO3RUOqOI1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2019-07-07 21:33, Carsten Bormann wrote: > On Jul 7, 2019, at 21:05, Carsten Bormann wrote: >>=20 >> Bug report: I think this should be something like >>=20 >>>> hash =3D =E2=80=98-=E2=80=98+base64.urlsafe_b64encode(hashlib.sha1(= query).digest()) if query else =E2=80=98=E2=80=99 >=20 > With 2.23.0, I actually get >=20 > hash =3D '-'+base64.urlsafe_b64encode(hashlib.sha1(query)) if query= else '' > TypeError: Unicode-objects must be encoded before hashing >=20 > (Python 3.7.3) >=20 > So this needs more than the change I was proposing (don=E2=80=99t laugh= ): >=20 > hash =3D '-' + base64.urlsafe_b64encode(hashlib.sha1(query.encode()).di= gest()).decode() if query else '' That's what I ended up with, too. And it's fine for both 2.7 and 3.x I've released an update that should fix this, 2.23.1. Henrik --ALLp1sRUGIk0hC9QNqmwUAdAO3RUOqOI1-- --HPaF04dLEdlln7MD2IiM7ClaFcTW99erL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl0idXoACgkQTptXS4+7 FxrwPw//VNIvzAwPDfkmTsIjAxSGhogZDZBeFpPYXctYJYGkcuMRiB7Q1LPhVRN0 MO9WwCKOUCCHKjoDiKxKja5Ez2RXZZ8Ea5SAidxMbYCeNzdFm+37nmaZtZwRudRA Jik1TTZf4edw6hOBXA6c1ItdMPOCO3rLBqAl2fIDLwPYzYeF2d7BEi2eF1iBmHiN vnC7yKUIhxr1PlZBMKsxK8Tpd81txE1lcYsb/GnftfiVGGK3mJLUWlZaneAQmOCe O4dfQWUDVgM1tepPi9+Wm4FYD59l4SPWo38xkuc8jQqK+LczLvvFrxsDum/zfxXw rlM3qEEBYykd7igsNhiP5fT5UNlRogSTPCl3b52TyjGJjDw5Vgjk681ApFP4wDht LT5wO/z15O+ROi3sLAapSeYFU1nnfT+8xIKRaghrFtTDv2PmBJyoKMHxuT76+wsP i/EwvXFtpKmpic/+d9lf3/x0J0d4b9ki6qsBLEf3dCo26ITTn7bI0q2TgYHvJ7Nt ckLmAiZcDGW/ec6Q1wKorMfePiQlPf6QipjPOZ+PnPXsfioi5JCuwcQz4ROb46aI wsv2hLKOxZI+5kjOy6pU2gnnXyX4Cc7Dga0nwbKMfVD6E+F/NVhXXP7z1BaFrB6Q M4Tlr7CiiXH5P+mcO6kKHuYqkbX0CNk9aa3m2futpipWF9y4ijE= =FIBL -----END PGP SIGNATURE----- --HPaF04dLEdlln7MD2IiM7ClaFcTW99erL-- From nobody Thu Jul 11 14:52:05 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA3CF1200F8 for ; Thu, 11 Jul 2019 14:52:03 -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, 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 B8RXHbUBurl6 for ; Thu, 11 Jul 2019 14:52:01 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5472912009E for ; Thu, 11 Jul 2019 14:52:01 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1hlgyt-000NSN-PW for xml2rfc@ietf.org; Thu, 11 Jul 2019 17:51:59 -0400 Date: Thu, 11 Jul 2019 17:51:53 -0400 From: John C Klensin To: xml2rfc@ietf.org Message-ID: <60AB35B3B946D11980DA5426@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [xml2rfc] xml2rfc online: references to I-Ds and associated dates X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 21:52:04 -0000 Hi. I happened to look today at the reference produced for an I-D by xml2rfc (at least by the online version at https://xml2rfc.tools.ietf.org/ ) The XML for the relevant cited I-D says (irrelevant material elided and the identity of the I-D changed to avoid distractions): ... The output is "June 2019". Now, independent of what the RFC Editor decides to do with the reference entry when/if the document gets to them [1], while the document in which this is embedded is still an I-D, it can be very important to the reader to know which version of the I-D was cited and, of course, two or more versions of an I-D in the same month is not uncommon. Authors who are happy with month and year can presumably just leave the day out of the XML. But, if an author believes the day is important enough to include in the source file, why is that part of the date being suppressed? Is there any hope of fixing that, which would revert things to earlier behavior? best, john [1] It is a completely separate matter from the above and probably a topic for another list and another time, but the reality, IMO, is that there are two types of I-D references that might appear in an RFC. One is a recent draft that is still, or might reasonably expected to be, under active development. For those, the current "work in progress" form is appropriate. I'd still argue for explicit version numbers and dates, by they are probably of limited utility. The other is a document that is being referenced for historical context, has typically been expired for years, and for which it is clear that no further development will occur, possibly because the referencing document superceded it. If we are going to allow references to such I-Ds at all (IIR, for many years, we didn't) those references need to be complete with accurate dates and version numbers. In addition, claiming that they are works in progress, especially when the text of the document in which the citation is imbedded says that they are obsolete... well, I think the technical term in the bibliographical world would be "plain silly". But, again, that is a different set of issues from the above and not an xml2rfc problem, at least until policies change. From nobody Thu Jul 11 15:09:10 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F510120123 for ; Thu, 11 Jul 2019 15:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.703 X-Spam-Level: X-Spam-Status: No, score=-0.703 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, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 4g4mYhxxTaOQ for ; Thu, 11 Jul 2019 15:09:06 -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 290E41200B6 for ; Thu, 11 Jul 2019 15:09:06 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id g2so3388850pfq.0 for ; Thu, 11 Jul 2019 15:09:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=v7WWyXVzIW3OhKhHzHYv1phoN14Ch2+1w1DOE1C1AAE=; b=C77ntkcS2XNM9HIHv/qEQKZ60QrXA1+R/OmsT260icpe+lpMoaYaYJ+vkA67EdJmgW VsfEu3NcRyZmIPdMNEPc4gkttMrEZOzBxGJGiAtT8lSW7fS1YSXkbxEiWUz5gFs8J59M OzJtcTYsCySfmIUt9IfRkmF83iq+yMSBqVX0rKUzyvb59guDP8wlj1JnGdPA3eRYkksE nAWE4FJlbmKxue0Ta4i7kkVOZXNy4NIMgesxUCPtki7SW9nhGySnP4Iew0KhnnE/TqW8 8Ojxdd9Qa71uOD/aT/FgyzhNQJliYcmb7TVAQGODV424CmAwpJjBATdF19xNzOmZSX6A QjAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=v7WWyXVzIW3OhKhHzHYv1phoN14Ch2+1w1DOE1C1AAE=; b=FxxrSgoJQWLh3A++1vgPgPZubkMOUwK+O7sRXJ7xQJRIuIepPzHu6ggOy1i/LnzL/7 rmnC9xNurRcBqS+TCtFOaRodFuE5dWZqW6/cdaT6dKCS0JVQGYRieDrTq7RSdVPO6S/k QwWEu3JchTesOWXxcXhF/C6/R6BHIDHD+8z58QtXQ7V2bGQZj7BozMzU7PIoyzsiGNGf pzODepadlDBx+pkqe+Gcw8Tpsf0GGtypCWU95SGasYWfs2/JFaJUAQLUL5+exTA7U+MD GA+JlSX49oqazcrqQs8+kExqLVPGnXjFH3CLaOU78YByDpyaw3Z+GLHwgCjtdJF+DNLY sqwQ== X-Gm-Message-State: APjAAAWrwFPmepwnZc0h5MQfU6uts4MkEndYBehG+3pZjppmNTmsxpEo 5YBuIIOoNgrO1bssjFpGS1sL0Es/ X-Google-Smtp-Source: APXvYqycwnNqtgTciakQS5B8e4VhBH7HlmY+Iu4gLLGtgo0X1lThA8c5UlAEpQua0uNYKEODoLlF4A== X-Received: by 2002:a65:5248:: with SMTP id q8mr6739607pgp.259.1562882945265; Thu, 11 Jul 2019 15:09:05 -0700 (PDT) Received: from [192.168.178.30] (32.23.255.123.dynamic.snap.net.nz. [123.255.23.32]) by smtp.gmail.com with ESMTPSA id x128sm13473798pfd.17.2019.07.11.15.09.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jul 2019 15:09:04 -0700 (PDT) To: John C Klensin , xml2rfc@ietf.org References: <60AB35B3B946D11980DA5426@PSB> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5aa01f36-374b-6236-ecc1-58610d50c6e6@gmail.com> Date: Fri, 12 Jul 2019 10:09:01 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <60AB35B3B946D11980DA5426@PSB> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [xml2rfc] xml2rfc online: references to I-Ds and associated dates X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 22:09:08 -0000 On 12-Jul-19 09:51, John C Klensin wrote: > Hi. > > I happened to look today at the reference produced for an I-D by > xml2rfc (at least by the online version at > https://xml2rfc.tools.ietf.org/ ) > > The XML for the relevant cited I-D says (irrelevant material > elided and the identity of the I-D changed to avoid > distractions): > > target="https://datatracker.ietf.org/doc/draft-ietf-foo-bar/"> > ... > > > > > The output is "June 2019". > > Now, independent of what the RFC Editor decides to do with the > reference entry when/if the document gets to them [1], while the > document in which this is embedded is still an I-D, it can be > very important to the reader to know which version of the I-D > was cited and, of course, two or more versions of an I-D in the > same month is not uncommon. Two versions on the same day is not impossible. For an actual case, I once did this: RPL: IPv6 Routing Protocol for Low power and Lossy Networks You can see the eventual result, which was not 100% satisfactory, in https://tools.ietf.org/html/rfc6294 Brian > > Authors who are happy with month and year can presumably just > leave the day out of the XML. But, if an author believes the > day is important enough to include in the source file, why is > that part of the date being suppressed? Is there any hope of > fixing that, which would revert things to earlier behavior? > > best, > john > > [1] It is a completely separate matter from the above and > probably a topic for another list and another time, but the > reality, IMO, is that there are two types of I-D references that > might appear in an RFC. One is a recent draft that is still, or > might reasonably expected to be, under active development. For > those, the current "work in progress" form is appropriate. I'd > still argue for explicit version numbers and dates, by they are > probably of limited utility. The other is a document that is > being referenced for historical context, has typically been > expired for years, and for which it is clear that no further > development will occur, possibly because the referencing > document superceded it. If we are going to allow references to > such I-Ds at all (IIR, for many years, we didn't) those > references need to be complete with accurate dates and version > numbers. In addition, claiming that they are works in progress, > especially when the text of the document in which the citation > is imbedded says that they are obsolete... well, I think the > technical term in the bibliographical world would be "plain > silly". But, again, that is a different set of issues from the > above and not an xml2rfc problem, at least until policies change. > > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc > From nobody Thu Jul 11 15:53:06 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21FC9120041 for ; Thu, 11 Jul 2019 15:53:05 -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, HTML_MESSAGE=0.001, 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 QeY1vxMIcbfD for ; Thu, 11 Jul 2019 15:53:02 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 95D6812016B for ; Thu, 11 Jul 2019 15:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id x6BMqrub015402; Fri, 12 Jul 2019 00:52:58 +0200 (CEST) Received: from [192.168.217.102] (p5089AF0A.dip0.t-ipconnect.de [80.137.175.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 45lBCn4Hkwz1Bp8; Fri, 12 Jul 2019 00:52:53 +0200 (CEST) Content-Type: multipart/alternative; boundary=Apple-Mail-0E177A98-6F79-48D2-8D34-7347ABE6A566 Mime-Version: 1.0 (1.0) From: Carsten Bormann X-Mailer: iPhone Mail (16F203) In-Reply-To: <5aa01f36-374b-6236-ecc1-58610d50c6e6@gmail.com> Date: Fri, 12 Jul 2019 00:52:53 +0200 Cc: John C Klensin , xml2rfc@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <15CF0049-78B6-46E6-8C84-D26FB1DE3F05@tzi.org> References: <60AB35B3B946D11980DA5426@PSB> <5aa01f36-374b-6236-ecc1-58610d50c6e6@gmail.com> To: Brian E Carpenter Archived-At: Subject: Re: [xml2rfc] xml2rfc online: references to I-Ds and associated dates X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 22:53:05 -0000 --Apple-Mail-0E177A98-6F79-48D2-8D34-7347ABE6A566 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Why not reference the specific i-d:=20 {{I-D.draft-ietf-roll-rpl-07}} as opposed to latest in series: {{I-D.ietf-roll-rpl}} Sent from mobile > On 12. Jul 2019, at 00:09, Brian E Carpenter = wrote: >=20 > draft-ietf-roll-rpl-07 --Apple-Mail-0E177A98-6F79-48D2-8D34-7347ABE6A566 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Why not reference the specific i-d: 

{{I-D.draft-ietf-roll-rpl-07}}

as opposed to latest in series:

{{I-D.ietf-roll-rpl}}

Sent from mobile

On 12. Jul 2019, at 00:09, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

draft-ietf-roll-rpl-07
--Apple-Mail-0E177A98-6F79-48D2-8D34-7347ABE6A566-- From nobody Thu Jul 11 16:13:57 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 504C7120041 for ; Thu, 11 Jul 2019 16:13:56 -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, 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 seICfx2Q9NPD for ; Thu, 11 Jul 2019 16:13:54 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA6BC120033 for ; Thu, 11 Jul 2019 16:13:54 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1hliG8-000OMA-U4; Thu, 11 Jul 2019 19:13:52 -0400 Date: Thu, 11 Jul 2019 19:13:47 -0400 From: John C Klensin To: Brian E Carpenter , xml2rfc@ietf.org Message-ID: <118C3616CE78C9B5BAE651CC@PSB> In-Reply-To: <5aa01f36-374b-6236-ecc1-58610d50c6e6@gmail.com> References: <60AB35B3B946D11980DA5426@PSB> <5aa01f36-374b-6236-ecc1-58610d50c6e6@gmail.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [xml2rfc] xml2rfc online: references to I-Ds and associated dates X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 23:13:56 -0000 --On Friday, July 12, 2019 10:09 +1200 Brian E Carpenter wrote: > On 12-Jul-19 09:51, John C Klensin wrote: >> Hi. >> >> I happened to look today at the reference produced for an I-D >> by xml2rfc (at least by the online version at >> https://xml2rfc.tools.ietf.org/ ) >> >> The XML for the relevant cited I-D says (irrelevant material >> elided and the identity of the I-D changed to avoid >> distractions): >> >> > target="https://datatracker.ietf.org/doc/draft-ietf-foo-bar >> /"> ... >> >> >> >> >> The output is "June 2019". >> >> Now, independent of what the RFC Editor decides to do with the >> reference entry when/if the document gets to them [1], while >> the document in which this is embedded is still an I-D, it >> can be very important to the reader to know which version of >> the I-D was cited and, of course, two or more versions of an >> I-D in the same month is not uncommon. > > Two versions on the same day is not impossible. For an actual > case, I once did this: > > > > > > RPL: IPv6 Routing Protocol for Low power and Lossy > Networks fullname="T. Winter"/> fullname="P. Thubert"/> > > value="draft-ietf-roll-rpl-07"/> > > You can see the eventual result, which was not 100% > satisfactory, in https://tools.ietf.org/html/rfc6294 Well, I just looked at the RFC and someone, probably the RFC Editor, discarded your seriesInfo material entirely, leaving just the authors, title, month and year, and the notorious "work in progress". If my guess about the relationship between [RPL] and [RPL-7] is correct, the latter is certainly not a work in progress either. And, if those are the two versions in question, they are in the same month but a year apart. However, that is all about the RFC and other rules, including the insertion of "work in progress" apply. For the I-D case, there is no question that the information can be forced in. One can use your strategy, one can use something a little more like I wrote, with the link in the target attribute of , and then use or one can use an annotation element and describe what is going on. Probably there are other options too. But, as a long-term fan of the principle of generic markup, I wasn't looking for a workaround, I was looking for the information that appears in the markup to be reflected in the output unless there is a substantive reason to not do so. At least some years ago, if a complete date appeared in markup, a complete date also appeared in the output. Either its disappearance is an unintended side-effect of some other change or someone decided to take it out. Either way, I suggest the result is not what we want and that it would make sense to restore the prior behavior. best, john From nobody Thu Jul 11 16:58:22 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F36D12007A for ; Thu, 11 Jul 2019 16:58:21 -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 ktPlvIk0GA4v for ; Thu, 11 Jul 2019 16:58:19 -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 2E50A12006A for ; Thu, 11 Jul 2019 16:58:19 -0700 (PDT) Received: from [192.168.217.110] (p548DCE40.dip0.t-ipconnect.de [84.141.206.64]) (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 45lCgC60TSzyhb; Fri, 12 Jul 2019 01:58: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: <15CF0049-78B6-46E6-8C84-D26FB1DE3F05@tzi.org> Date: Fri, 12 Jul 2019 01:58:15 +0200 Cc: John C Klensin , xml2rfc@ietf.org X-Mao-Original-Outgoing-Id: 584582293.448089-5e12a62434e3f16676a80e267fe9b8ee Content-Transfer-Encoding: quoted-printable Message-Id: <1FBE1F3A-A148-42A8-AAA2-EB7E8F9B2036@tzi.org> References: <60AB35B3B946D11980DA5426@PSB> <5aa01f36-374b-6236-ecc1-58610d50c6e6@gmail.com> <15CF0049-78B6-46E6-8C84-D26FB1DE3F05@tzi.org> To: Brian E Carpenter X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [xml2rfc] xml2rfc online: references to I-Ds and associated dates X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 23:58:21 -0000 On Jul 12, 2019, at 00:52, Carsten Bormann wrote: >=20 > Why not reference the specific i-d:=20 >=20 > {{I-D.draft-ietf-roll-rpl-07}} >=20 > as opposed to latest in series: >=20 > {{I-D.ietf-roll-rpl}} FYI: here are the reference entries I get from these: [I-D.draft-ietf-roll-rpl-07] Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing Protocol for Low power and Lossy Networks", draft-ietf- roll-rpl-07 (work in progress), March 2010. [I-D.ietf-roll-rpl] Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., and J. Vasseur, "RPL: IPv6 Routing Protocol for Low power and Lossy Networks", draft-ietf-roll-rpl-19 (work in progress), March 2011. The date is a red herring. Dates in RFC references are always = Month-Year. As was noted, adding a day doesn=E2=80=99t help with frequently respun = I-Ds. I think that=E2=80=99s why the draft number is in the bibxml. (Well, =E2=80=9CR. Team=E2=80=9D for =E2=80=9CROLL Design Team" *is* a = bit funny :-) Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jul 11 17:10:27 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FCA01200C7 for ; Thu, 11 Jul 2019 17:10:26 -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 At_lf8uozsBG for ; Thu, 11 Jul 2019 17:10:24 -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 38C401200B9 for ; Thu, 11 Jul 2019 17:10:24 -0700 (PDT) Received: from [192.168.217.110] (p548DCE40.dip0.t-ipconnect.de [84.141.206.64]) (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 45lCx82vvDz14p0; Fri, 12 Jul 2019 02:10:20 +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: <1FBE1F3A-A148-42A8-AAA2-EB7E8F9B2036@tzi.org> Date: Fri, 12 Jul 2019 02:10:19 +0200 Cc: John C Klensin , xml2rfc@ietf.org X-Mao-Original-Outgoing-Id: 584583017.760375-0a07f1b27c4a2f65f0f4383ff0556278 Content-Transfer-Encoding: quoted-printable Message-Id: <980393C9-9AB8-4B48-9175-F513884847D5@tzi.org> References: <60AB35B3B946D11980DA5426@PSB> <5aa01f36-374b-6236-ecc1-58610d50c6e6@gmail.com> <15CF0049-78B6-46E6-8C84-D26FB1DE3F05@tzi.org> <1FBE1F3A-A148-42A8-AAA2-EB7E8F9B2036@tzi.org> To: Brian E Carpenter X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [xml2rfc] xml2rfc online: references to I-Ds and associated dates X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 00:10:26 -0000 On Jul 12, 2019, at 01:58, Carsten Bormann wrote: >=20 > I think that=E2=80=99s why the draft number is in the bibxml. Oh, and since this is the xml2rfc list: The series info looks like this: and xml2rfc detects the seriesInfo name =E2=80=9CInternet-Draft=E2=80=9D and = inserts the =E2=80=9Cwork in progress=E2=80=9D boilerplate instead: xml2rfc/writers/raw_txt.py: for seriesInfo in ref.findall('seriesInfo'): if seriesInfo.attrib['name'] =3D=3D "Internet-Draft": refstring.append(', '+seriesInfo.attrib['value'] + ' = (work in progress)') else: refstring.append(', '+seriesInfo.attrib['name'] + = u'\u00A0' + = seriesInfo.attrib[=E2=80=98value'].replace('/', '/' + u'\u200B')) Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jul 11 19:49:04 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 973F81200BA for ; Thu, 11 Jul 2019 19:49:03 -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, 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 h1Y71HWJ52xn for ; Thu, 11 Jul 2019 19:49:02 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01CC912001E for ; Thu, 11 Jul 2019 19:49:02 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1hllcJ-0000gl-L4; Thu, 11 Jul 2019 22:48:59 -0400 Date: Thu, 11 Jul 2019 22:48:54 -0400 From: John C Klensin To: Carsten Bormann , Brian E Carpenter cc: xml2rfc@ietf.org Message-ID: <6A85B6DC8FACFE6EE3632A26@PSB> In-Reply-To: <1FBE1F3A-A148-42A8-AAA2-EB7E8F9B2036@tzi.org> References: <60AB35B3B946D11980DA5426@PSB> <5aa01f36-374b-6236-ecc1-58610d50c6e6@gmail.com> <15CF0049-78B6-46E6-8C84-D26FB1DE3F05@tzi.org> <1FBE1F3A-A148-42A8-AAA2-EB7E8F9B2036@tzi.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [xml2rfc] xml2rfc online: references to I-Ds and associated dates X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 02:49:04 -0000 --On Friday, July 12, 2019 01:58 +0200 Carsten Bormann wrote: > [I-D.ietf-roll-rpl] > Winter, T., Thubert, P., Brandt, A., Clausen, > T., Hui, J., Kelsey, R., Levis, P., Pister, K., > Struik, R., and J. Vasseur, "RPL: IPv6 Routing > Protocol for Low power and Lossy Networks", > draft-ietf-roll-rpl-19 (work in progress), March > 2011. > > The date is a red herring. Dates in RFC references are always > Month-Year. As was noted, adding a day doesn't help with > frequently respun I-Ds. I think that's why the draft number > is in the bibxml. Brian may have a different answer for his document, but ... * Historically, dates in RFC references are not "always" Month-Year. For a long time, the custom was to show April 1 RFCs with the day for reasons that are probably obvious. If that custom has lapsed (and it apparently has) it is a loss in information for the RFC Series. * As I said earlier, my concern is about I-Ds referencing I-Ds. These are not RFC references. And, while I'll stipulate that draft version/sequence numbers are more precise than dates, I can think of any number of reasons why an exact date may convey useful information. * While I use bibxml for RFCs, I find that I can rarely use it for references to I-Ds because either the exact information I need isn't reliably there or because I need different naming or structure for stylistic reasons. Interestingly, the outcome of a recent discussion with the RFC Editor about a style issue will result in my being able to use it for fewer references to RFCs than has been normal in the past. john From nobody Thu Jul 11 20:11:58 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2316120052 for ; Thu, 11 Jul 2019 20:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.704 X-Spam-Level: X-Spam-Status: No, score=-0.704 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, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 cn0jFkOPTIFJ for ; Thu, 11 Jul 2019 20:11:57 -0700 (PDT) Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (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 EFE1C12001E for ; Thu, 11 Jul 2019 20:11:56 -0700 (PDT) Received: by mail-pg1-x536.google.com with SMTP id q4so3856259pgj.8 for ; Thu, 11 Jul 2019 20:11:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Q9npLL1ttZpYL4J8e8+pcAvF9vXYHoZ1Hzw3sBtRDnI=; b=IGNx0KA/J/DPHA/P/9a6DYFY9Kojpd9q/15xV/3qBIHZvKR3U/DCOkyj9dOiPhGhad RPSQmWIVrGadSPTBQhbGm2crf3nRVRi+IV/fbLIk0K3JFH7/EX1tORF78VYFgG+NKsoz f9fFa9zQVfx2UZTI/h/fuqgoQKslVnP6xeYRf6va3+TFOqR/hIqLAqmiFLDTPcnD+kpx Ms2MwsXulAWwePnam79QcfhbcXIvo4/fioWAFIlFLk/v/HsfD5LTMRERgiZ4icwNMBd8 nbvSFV8WRnmEYEoin98sQUuDYd9nYiVBM8UbtOtEdHJ+bV/kWgD2IrJBsPzoBiLjIfZ2 VfQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Q9npLL1ttZpYL4J8e8+pcAvF9vXYHoZ1Hzw3sBtRDnI=; b=mIjCTn6j2yEGETwMVTWOTQYVZ+TM9cLjDUe7nvbhuZ/n8dZRqQlxLojlvT6cEWyJuN /ILwp8bdKkFsYZATg24KLaiZ/DXEmpQA10hwXDNfOB/9xMWWol1ZewFixFu4aPDwSSRT gPr7vhD4WPKIN+ys/Mr4An1eS0/hGB5WoDkJhrlK0zyX+68Ff3bFGQ1ixjk8yUUAPJJa H14ksIMd9o5/6W9k2c0NoQemm2BaG9wkE37y4n9ppRfr+xWXdJ1y3+N2ofyZ7RXHCIcH CWsXl9wKVftbUETEdSlVWkl+9+WUe81wzfLi20lrJ4HPbp6/bCvFGjAz0rAB4HRMb2Ng VBwA== X-Gm-Message-State: APjAAAWHmlQU8ROrH7x0HM/RLTlS/OFjCBcpnhCy+alIeugdhiyl/YtC eCHprp8NrJy5yO8uauIhxjAGtMQz X-Google-Smtp-Source: APXvYqyNXBkF2M4suAgid7BP96C7XT3WYq1M8JHEwoFfqMKle5szPzDP59RFyvFYO9h4780zzDJQQg== X-Received: by 2002:a17:90a:c391:: with SMTP id h17mr8808657pjt.131.1562901116071; Thu, 11 Jul 2019 20:11:56 -0700 (PDT) Received: from [192.168.178.30] (32.23.255.123.dynamic.snap.net.nz. [123.255.23.32]) by smtp.gmail.com with ESMTPSA id j19sm7667157pgn.19.2019.07.11.20.11.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jul 2019 20:11:55 -0700 (PDT) To: Carsten Bormann Cc: John C Klensin , xml2rfc@ietf.org References: <60AB35B3B946D11980DA5426@PSB> <5aa01f36-374b-6236-ecc1-58610d50c6e6@gmail.com> <15CF0049-78B6-46E6-8C84-D26FB1DE3F05@tzi.org> From: Brian E Carpenter Message-ID: <489a4464-a93f-8ae6-7edd-154145591145@gmail.com> Date: Fri, 12 Jul 2019 15:11:52 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <15CF0049-78B6-46E6-8C84-D26FB1DE3F05@tzi.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [xml2rfc] xml2rfc online: references to I-Ds and associated dates X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 03:11:58 -0000 On 12-Jul-19 10:52, Carsten Bormann wrote: > Why not reference the specific i-d:=C2=A0 >=20 > {{I-D.draft-ietf-roll-rpl-07}} >=20 > as opposed to latest in series: >=20 > {{I-D.ietf-roll-rpl}} I believe that didn't work at that time. If it works now, that's good new= s. Brian >=20 > Sent from=C2=A0mobile >=20 > On 12. Jul 2019, at 00:09, Brian E Carpenter > wrote: >=20 >> draft-ietf-roll-rpl-07 From nobody Thu Jul 11 20:15:35 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8895120052 for ; Thu, 11 Jul 2019 20:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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] 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 SESONdRWgGFC for ; Thu, 11 Jul 2019 20:15: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 9494B12001E for ; Thu, 11 Jul 2019 20:15:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1562901323; bh=3yjeNea5IKMc9kQS/fsgEjymftXM28OQRWbQXIIVfqY=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=eujdq1S9pmmd2rLkIKdBuxxy6KITJ6KO5h9YD6fL44aOHL5Hn5VgwkKPuvG0P5NeZ o166RIJxTc/6eTKQ9gsYELScsN0YIUgbPSLGWziJKG3jfH85IfYsufGkva147YSlfs K+XGPh7jWhfKN7DhZrqm1dweIwCMk5SG5nb4zadg= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([84.171.151.199]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Mhdex-1i6rL41FXX-00Mslz; Fri, 12 Jul 2019 05:10:05 +0200 To: John C Klensin , Brian E Carpenter , xml2rfc@ietf.org References: <60AB35B3B946D11980DA5426@PSB> <5aa01f36-374b-6236-ecc1-58610d50c6e6@gmail.com> <118C3616CE78C9B5BAE651CC@PSB> From: Julian Reschke Message-ID: <7a314eb7-a795-cf10-a609-3d82179fc266@gmx.de> Date: Fri, 12 Jul 2019 05:10:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <118C3616CE78C9B5BAE651CC@PSB> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:rSCNP3RRK8nbCZnGdHmcnig63gQN0Dx6ByaBRb0/tHEGoZ/gOxu V1KyRRwu6R8+IC4Rf540y+3MvQwNZC1G2pMHRxlCMEdwPP7CWCfLTCyHzyNTAeuzisXEFMt Y8DYgTBoCWKszZg766279wD3xfPaYgHj2xkS8j77eNlgHUcs9n+osebPLHZ1+nz8MaqMtz+ mFkbLJUUtxMo/XC0C8qPg== X-UI-Out-Filterresults: notjunk:1;V03:K0:lqzclYlOBFM=:BwGxY7BPhii8D3UczJOwUO 61KP/TSGnx7etQl2h6kkif5ZULUkxRYkbr230LsvnyxbSBcFfU1ctryekLIFM39M9mmW4mMF4 AI5jZtlUT9u+soxA/j1ZVoX7kCswyDOiKAlD+xZ7gIWaZC9B3Dm5BIuEzkYJzZ71FQb2RRI48 ecrX5esDwaTPtzVR8OqKJBlWnej14huN0EBgIkX+wJ4iwIUco+hecnqq4Z9S7wnD9Lix1MlQ2 Rq/Yq9D8FUxiBVUZYtB7qUlN30A7aribhIrJSqqPcatUR3qadFa+LS5PQwjsYU0qc4btHObJS G7zjS5czT8tPVwRHH6RkQf6qZhwgQDHKS+e4TNZZAe3iwLRBBnbhr3GiTCoO4qe4sCWCsBiZS TLF2pSOoiOhOpNyjPY8eOQ+/h124qVC2TMhd1FuCMKt1gpXAubfyEGUqnxEROH2j0B6Y/Ag+G GfHcjZSyQRH+AiALl6ZU/6PrS4EqJ/dxzXXQ6xBgxA35WnChqHM9rt3NYPykwf8m4xDtHMyHv xFLqzFDCF0bCA+G3MkrXACQURJKNj2MINmpfisL9i5xXLDR5I80b9zLJNx8LYmXIqEVWC3mlA ZKsXbrLQRXxXHwqJ9p8bmwdesNYbwLrAkWfEO2MoQZo8p16nbBm8LNplgRPsBaMa6L4iwsT5i tFomKoCKxn5/j3wYZsL0om4ZyuYAtTwCHEYftBkaz6PbqwW/1o1cR0Hwa87TH3w0YJ8bTnD1T zalMdYnLqVSLD88eXOtgQleMabJGdnfbkUPOR86kmoT4LzvZRnweZfGCcuX+ysV+uWm8pprxn QSiZl/8r9WKJ5Tyt+fIU3TaCOWawcArL5Gybhm1MROWb0jEazawZd9+1yWC86dHFIAEcVLlUv eOEhCQ+qn0HE2GSAnft6rGaKw5tGlqoVx88PZNNwbg40K2NOrDIvwhkjWs2OG3fMd3PcmoRF1 whHQNhmUTn7AG8xkjKCjWqrcCDhP5zJ5R97DCLIO1i3sv2hbJ4ichWHdZjdMQHhKO5pQCzl3r XAehEQf9J4Sx2mK8m1qCxn8UMs8N6zBkrHscQzTa5e//53Ar3XfqdF2GNXHl8h9ahvEnEqy3D bYa8beisyhiI6Ndo31vg0gn6QG9NE1Fugan Archived-At: Subject: Re: [xml2rfc] xml2rfc online: references to I-Ds and associated dates X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 03:15:34 -0000 On 12.07.2019 01:13, John C Klensin wrote: > ... > At least some years ago, if a complete date appeared in markup, > a complete date also appeared in the output. Either its > disappearance is an unintended side-effect of some other change > or someone decided to take it out. Either way, I suggest the > result is not what we want and that it would make sense to > restore the prior behavior. > ... I don't think anything has changed with regards to this. The day of month never has been shown in references. Best regards, Julian From nobody Fri Jul 12 06:16:40 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E589120045 for ; Fri, 12 Jul 2019 06:16:39 -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, 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 kX-Ks539R-vL for ; Fri, 12 Jul 2019 06:16:37 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [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 CD04912003F for ; Fri, 12 Jul 2019 06:16:37 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:61221 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 1hlvPd-0002Qt-TA; Fri, 12 Jul 2019 06:16:35 -0700 To: John C Klensin , xml2rfc@ietf.org References: <60AB35B3B946D11980DA5426@PSB> From: Henrik Levkowetz Message-ID: <7138e8a5-1c7a-cb5d-2d00-35389a7fada0@levkowetz.com> Date: Fri, 12 Jul 2019 15:16: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: <60AB35B3B946D11980DA5426@PSB> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="AIjRKjjo70oPVD8gAKaLbW7bWuMcjJfMf" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, john-ietf@jck.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: [xml2rfc] xml2rfc online: references to I-Ds and associated dates X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 13:16:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --AIjRKjjo70oPVD8gAKaLbW7bWuMcjJfMf Content-Type: multipart/mixed; boundary="UQq2N3qGJiKwBLFoNBPpu26HLWS3BFlkp"; protected-headers="v1" From: Henrik Levkowetz To: John C Klensin , xml2rfc@ietf.org Message-ID: <7138e8a5-1c7a-cb5d-2d00-35389a7fada0@levkowetz.com> Subject: Re: [xml2rfc] xml2rfc online: references to I-Ds and associated dates References: <60AB35B3B946D11980DA5426@PSB> In-Reply-To: <60AB35B3B946D11980DA5426@PSB> --UQq2N3qGJiKwBLFoNBPpu26HLWS3BFlkp Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi John, On 2019-07-11 23:51, John C Klensin wrote: > Hi. >=20 > I happened to look today at the reference produced for an I-D by > xml2rfc (at least by the online version at > https://xml2rfc.tools.ietf.org/ ) >=20 > The XML for the relevant cited I-D says (irrelevant material > elided and the identity of the I-D changed to avoid > distractions): >=20 > target=3D"https://datatracker.ietf.org/doc/draft-ietf-foo-bar/"> > ... > > > >=20 > The output is "June 2019". After looking through various output formats, my conclusion here is that this is the output from the v2 text formatter, not the v3 text formatter. The v3 text formatter renders the date with day, month, and year if all 3 are given. So going forward, it seems that this has already been addressed (assuming we leave the v2 formatter untouched at this late stage in its life cycle). Best regards, Henrik >=20 > Now, independent of what the RFC Editor decides to do with the > reference entry when/if the document gets to them [1], while the > document in which this is embedded is still an I-D, it can be > very important to the reader to know which version of the I-D > was cited and, of course, two or more versions of an I-D in the > same month is not uncommon. =20 >=20 > Authors who are happy with month and year can presumably just > leave the day out of the XML. But, if an author believes the > day is important enough to include in the source file, why is > that part of the date being suppressed? Is there any hope of > fixing that, which would revert things to earlier behavior? >=20 > best, > john >=20 > [1] It is a completely separate matter from the above and > probably a topic for another list and another time, but the > reality, IMO, is that there are two types of I-D references that > might appear in an RFC. One is a recent draft that is still, or > might reasonably expected to be, under active development. For > those, the current "work in progress" form is appropriate. I'd > still argue for explicit version numbers and dates, by they are > probably of limited utility. The other is a document that is > being referenced for historical context, has typically been > expired for years, and for which it is clear that no further > development will occur, possibly because the referencing > document superceded it. If we are going to allow references to > such I-Ds at all (IIR, for many years, we didn't) those > references need to be complete with accurate dates and version > numbers. In addition, claiming that they are works in progress, > especially when the text of the document in which the citation > is imbedded says that they are obsolete... well, I think the > technical term in the bibliographical world would be "plain > silly". But, again, that is a different set of issues from the > above and not an xml2rfc problem, at least until policies change. >=20 > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc >=20 --UQq2N3qGJiKwBLFoNBPpu26HLWS3BFlkp-- --AIjRKjjo70oPVD8gAKaLbW7bWuMcjJfMf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl0oiCkACgkQTptXS4+7 FxqKGw//SHTnOzuibi2hSfUqTiVjzqbqlI7HkQN+eiKFzdKqFuKIYA9p0A0ECDZ4 AHdlNEdZBY74JfdHersf90UIvnPkXx3aHU7aIbhhNIVNnrk4s6oJUkTlGr3PQCyn x0BWJpZYWKm9Ob0xTTXqMfKLpg+qCjn6ety/bmZda64hJBXR7oUDZTh7swQHYWKC oMOZYvezOdnZ/en+RaucfrjuTCwmg2HZzmZyyhhLSVfo3esfRr8BbOu+N47l0Wn4 mkMICEjE1ysJ9Y8Jrx2tsWNSD4exG93p9i7hG3CVEw0pc0sgjJrSXtbyl/11NWUC OB2xpVx2Wbp1v35f9CbVRMrZ0zmd2ZAG/+FkMc6O0bFOLIZDTxoME8/R3CPp7NP4 8uD7pV5myv+VXnzLSNKUiG8jkCpto1iFtGdOvD+Fb7llXEjI2C7+yDOArA2/DiDS m52TYTMrBiXyI8libR2B42y5+lVita0mRwnB3zQr0POxvCGhZXTvqtAPihWc/2Zd vetb8XMssOLzz7jLYLTbGt8xkdgoqwdZDOWUPa05R3X4sdrKtOgKbrVVFYgKmAMS CW0xgVAHk1VbRdJLNX0BNgfu/9ci0mg58AWCO8+3UPXAkQvKLX1PZhE07W2DY2mM EhBQWPH/mxZ7NtOHPXljowoDenKzBXMz7N+QUQ5eI46B0mmNaDM= =4mLw -----END PGP SIGNATURE----- --AIjRKjjo70oPVD8gAKaLbW7bWuMcjJfMf-- From nobody Fri Jul 12 06:40:38 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E31E91200D6 for ; Fri, 12 Jul 2019 06:40:36 -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, 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 (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 aBhffyFnWq75 for ; Fri, 12 Jul 2019 06:40:35 -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 60A151200CD for ; Fri, 12 Jul 2019 06:40:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1562938802; bh=rM6zGVr0woQrdiQv4vtUoLk8aTLAqoIzTj8Ov1Q0an0=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=k5yqMPnQLTeS3hKdTUTdZ4K1UN+UMx/DrYN6fclhAK8GclWzNIL3Zfztm8Zymqu/L 3ZU8OVLWkgidqYxEh3SS18EKoYm3mmbCVKk2TAHJ/21tJPTk8crEUnrdE09uC8NX+W 5x3znxrr1tHDGlOdyvZFuhyOEtT34XMlb70oo4i8= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LskfZ-1iRxVb2k5B-012Kr2; Fri, 12 Jul 2019 15:40:02 +0200 To: Henrik Levkowetz , John C Klensin , xml2rfc@ietf.org References: <60AB35B3B946D11980DA5426@PSB> <7138e8a5-1c7a-cb5d-2d00-35389a7fada0@levkowetz.com> From: Julian Reschke Message-ID: Date: Fri, 12 Jul 2019 15:40:00 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <7138e8a5-1c7a-cb5d-2d00-35389a7fada0@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:1dp8xoYwJ8d8q/FhKC8SozAUelVE4SAmYxMIOuVP74Dsggza08W wdWjJzyb95UyIFUTepdg7QEKHipNS71xlG3qXk8YKjO8rdGLD7Gqywu7G2Wj4SMudu8aF3j wzTLIShGhrhn+JcQEtPjPY18BihT36IQdWDbUSlbXg7fuKOcKhVytTzIWBvftveihbjj5c4 +uNtjls38uPZCR7KNAv0A== X-UI-Out-Filterresults: notjunk:1;V03:K0:qNC05mJctXI=:CfwUDbrHMuyTAXFP6KFlma bX14PorQhs0k8IhxScSTjCDAn5+Gm2tPUUTYLbK+qkV/PjmdPf5atacc7NtTRfA4NMnVlFrdT Vtdl0MPqHZ32URoduhNBgeIX2tHQYf30geoFCvtxpc9OutK2+hT6rFfrn/IRNEaJjyAdVMFvm K9uX0puvgsJHov8jo2RA/bvzvEDwAxpT8OdMl0hiLqZ23bJcvYhG+zvlrLQohIPkjbJdOo7W9 Jh9DhGUnT2J9Dgcko5u2/Ry3kDlMVM6TCzZc0Di78Frs5TqiFSknP6M4qiiMSEhv90lt6AmdL rYtVC9vy2Vjjq2oopUF7vg+WHeTjIjDl4KJ2vLrxBegCZHlbE/WJ4sjVzyd+0KjA/ZTiNhJZw kO/FWqcadfD7s+sWnclXy0668V0kuTVgz9YmioZNQkTPvsRAr03Pg9k+uUV4AJfyiJImT3Gb9 JnrA6+ZZl6dzyxYp72VzCC3SXadLV4vyyi8xoNkwASMR4z+/+YK+saxJxYlki2c5wQei45igy 8mqA54hgFdfBYknNYmPMKEXJB6R1FIRB0gdUL5noHQ7rB/vSZ2CYN0QTgF1NUxttczyfxspm7 WNuAnthAiAOeUQxITUP/QSZdGxytleuxijUeb00bJH96hH4OJhIEFUMgKb8FYqJbM7ekXKcjY DHi5nAIG65SxZEIREjEt0ILKKeEDqeDIKMepL/9HrrRXojd0ZwUpMvtS5NKNjxhq4G2N6vRVV 4l03mz6ninDvHCJbRxmLa3bp91HB7YWytDfWvpfAruJFoGc2poFA186e+olxGBnrg9e3/jZhC 5DHxjf/tTItAQIW/LRucD5n5XHzZ4asueH/Kn5xlpTN0cADYW6QuriYxK/IHwRZvVhQi3cC8D BRpVqcq6z7FgBm+CENMMX/airZ2tfSx9W+cyEwG/Q1milPP8weLvAC0P23kQt8bNRd81nwNtn a9s6f1vMAgSmlTQgXWxwGkazoj9bH7TPfAe9e8pEi4Gfp8kauodSykEI2PwGpvnv1KIEysKFJ GatN8Ma14TFr8D8ROPT6qukzuBhUUELJAtHoHr9uGbyA5IzF+rGLNfTKF0/LBlJToQs4Y6QpR uknFCcweJU7LlvnbQ59AiXc+xbu2IPTyxN/ Archived-At: Subject: Re: [xml2rfc] xml2rfc online: references to I-Ds and associated dates X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 13:40:37 -0000 On 12.07.2019 15:16, Henrik Levkowetz wrote: > Hi John, > > On 2019-07-11 23:51, John C Klensin wrote: >> Hi. >> >> I happened to look today at the reference produced for an I-D by >> xml2rfc (at least by the online version at >> https://xml2rfc.tools.ietf.org/ ) >> >> The XML for the relevant cited I-D says (irrelevant material >> elided and the identity of the I-D changed to avoid >> distractions): >> >> > target=3D"https://datatracker.ietf.org/doc/draft-ietf-foo-bar/"> >> ... >> >> >> >> >> The output is "June 2019". > > After looking through various output formats, my conclusion here > is that this is the output from the v2 text formatter, not the > v3 text formatter. The v3 text formatter renders the date with > day, month, and year if all 3 are given. So going forward, it > seems that this has already been addressed (assuming we leave the > v2 formatter untouched at this late stage in its life cycle). > ... Hmmm. That seems to be a rather big change to be introduced without notice. I think the first thing that needs to happen is the RFC Style Guide would need to say how to handle the format. Right now it says "year month", and this is what tools have been generating for ages. Heather? Best regards, Julian From nobody Fri Jul 12 06:43:24 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3A2120108 for ; Fri, 12 Jul 2019 06:43: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, 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 FjRSQUNh-UT5 for ; Fri, 12 Jul 2019 06:43:21 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [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 357C71200F5 for ; Fri, 12 Jul 2019 06:43:21 -0700 (PDT) Received: from localhost ([::1]:47032 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1hlvpX-0008OC-Gq; Fri, 12 Jul 2019 06:43:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Cc: xml2rfc@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: julian.reschke@gmx.de X-Trac-Project: xml2rfc Date: Fri, 12 Jul 2019 13:43:19 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/411 Message-ID: <069.4a8db82a7bf050743b133a1486325bdf@tools.ietf.org> X-Trac-Ticket-ID: 411 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: julian.reschke@gmx.de, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: [xml2rfc] #411 (Version_3_cli_txt): title for appears to be required X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 13:43:23 -0000 #411: title for appears to be required ...but is optional according to RFC 7991. {{{ references-test.xml(16): Error: No name entry found for section, can't continue }}} (xml2rfc --v3 references-test.xml) -- -----------------------------------+-------------------- Reporter: julian.reschke@gmx.de | Owner: Type: defect | Status: new Priority: medium | Milestone: Component: Version_3_cli_txt | Version: 2.23.* Keywords: | -----------------------------------+-------------------- Ticket URL: xml2rfc From nobody Fri Jul 12 06:44:33 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74725120124 for ; Fri, 12 Jul 2019 06:44:26 -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 9jLrXBZb8xxU for ; Fri, 12 Jul 2019 06:44:23 -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 8087B120223 for ; Fri, 12 Jul 2019 06:44:23 -0700 (PDT) Received: from [192.168.217.110] (p548DCE40.dip0.t-ipconnect.de [84.141.206.64]) (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 45lZ0N6VbHzyyL; Fri, 12 Jul 2019 15:44:20 +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: Fri, 12 Jul 2019 15:44:20 +0200 Cc: Henrik Levkowetz , John C Klensin , xml2rfc@ietf.org X-Mao-Original-Outgoing-Id: 584631858.40337-7911b9b7aabf3748fa8a8180a7befd3f Content-Transfer-Encoding: quoted-printable Message-Id: References: <60AB35B3B946D11980DA5426@PSB> <7138e8a5-1c7a-cb5d-2d00-35389a7fada0@levkowetz.com> To: Julian Reschke X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [xml2rfc] xml2rfc online: references to I-Ds and associated dates X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 13:44:33 -0000 On Jul 12, 2019, at 15:40, Julian Reschke wrote: >=20 > That seems to be a rather big change to be introduced without notice. >=20 > I think the first thing that needs to happen is the RFC Style Guide > would need to say how to handle the format. Right now it says "year > month=E2=80=9D, and this is what tools have been generating for ages. Well, keeping with the style guide could now be the onus of the author = (i.e., author has to delete the day to fulfill the style guide). I wouldn=E2=80=99t like that too much, as it makes automatically = generated references (e.g., from a DOI) harder to use. Still, I have no idea what the semantics of the style guide are here = when the interchange format is XML =E2=80=94 the full date might be = there, but the formatting tools don=E2=80=99t show it. What is governed = by the style guide? Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Jul 12 07:00:40 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 788641200E7 for ; Fri, 12 Jul 2019 07:00:35 -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, 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 (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 uR4xvnqwzVRz for ; Fri, 12 Jul 2019 07:00:32 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 A1A5A1200FB for ; Fri, 12 Jul 2019 07:00:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1562939998; bh=fIzj++RJsVJwr8rnMIT6M+QKFh38FmitiDRu//QnyRQ=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=ZONc7Kz7E6dxKDLy8wZV/snSW50BIEfejFcOA7GRv/H3PZlMiFdk3hSpzF+H9HuHT WRlJKU8FxHzGCnqIfq5THyfcL6RLSwd2kUKrZPq9OlRIhzfvIMvfLmI1utTH+K55n1 So/L4lzclp6tgnzfOHCyvmoCKjakd+DRb5WlrQYU= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MUoma-1hy8Lx3QD6-00Y6fc; Fri, 12 Jul 2019 15:59:57 +0200 To: Carsten Bormann Cc: Henrik Levkowetz , John C Klensin , xml2rfc@ietf.org References: <60AB35B3B946D11980DA5426@PSB> <7138e8a5-1c7a-cb5d-2d00-35389a7fada0@levkowetz.com> From: Julian Reschke Message-ID: <859ac46e-4c6f-4796-e352-f0a018cd8742@gmx.de> Date: Fri, 12 Jul 2019 15:59:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 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:wxWpllvGp+OQJ/PKG3rDkdKop2mYUe2S4ah3mQ/HaAAiC/vDrXw oZ6y/qoIKohpzI3HT7iW+/T5ilO1xcji6oVrS6/I71tId49X7iwV79Yl4I/rfOUKa8Ny/hX 5jX3tzYdN7paTrXd/dVxQtAlQEYmyalJB73a5Cagb9OgAbXvXLE8BLZQ19XaC9eq0Tlbftp yE3dGPO4AsXpWCecGGfAA== X-UI-Out-Filterresults: notjunk:1;V03:K0:Q0jttLEf8+k=:JEhvb/voPiPlsfzgH4G7pN DcuLnY82plrVzFPFGpZN/+DTPTTe29hcCHArqPugBYjvh5m368SR5LtmHdY9GDwV0lKPqnss/ jv1QireNkYm75+E6+WJx+9JMra0O7RLMy9X+VF0XI0i84uAJ1XWpxLHiY9yFArCMDiq7dNFLH +frRJNIgYf801EIp+IT5qzNyrnvsqQ1UngmZzM2PKFeU3TSX7TdlPh0p9WGuvxBKxJ+MehxGD e0er+6Ey/D5DmKOcRCl6/nTa/fotAyziJru7GSAnCJkEse/IjBoQR+XjeYhrnn4O+o1jx4hER +Q/TJAGv1uEr6v7G2I//IqwuvHhnvkQD8QiGkRhMzyuESsxGUCOcepsextexudkp4dqP7jz17 4WgkRViJOrvbPZ1Aymhj+rUNDmR9Y9P4Bi4OhYK6DZoPPs1NEyRbU8/4XnNHI7cxy5QYDSuku VfAEYAkfelAl5bN8zmQ3DqHsjq2KQLFSbEfLY+gUQF2qcBBn0yFtpL0eSE8dtkapZaHVlQsef pFysB5LNhl+Fuo96yiCG33AcrDEcILF5ZsZbDLwpiyg6OrZprZf8UU4KOiTVbpQG2Zm5lw57E 3SeYAAk2qZTRxvr5d1YNAXk0kqwDbTCx0eio09FiVa5Q/PyNJvI2W+kS4R5q5CFGQJSMt5oeM B3OXoIcKMmJa1wf/LLMxZL/5nNkcYHiVyWuK9985w4W9sQZnB1b22p/D2yDol0twz1IQcnAJw uuBh2omM2Xi9afCuBNg0D+mCg5VYSnQo2pFYDXmSOvuOKwjTFDuKFN2QO3i6NdWw3BqPdIxgt NVfumvFqSw9DTX60lERzCJaS2swOdLv1fRl5xVI8Kn7b77MQzrzAvaRnvqvK0dEkfJYxl2YSU ip0b94bQhtVa89f+CnneCIZaxSS0gRXN3Gks6UDlpsTzYx7/z5/99XR1Pt8k6212wlbgX7Avx 2bLE2yhH2NJLnNJqY9AftSYtjsyhfAtlPbkmcTp5tWiEVNQg+Y/h3Bw7NbJ/7vR3aRrcGHUzk iivdej2vBUsBgVHkjKXvuBrqn+bTLLuMgAhGqpEfk2apUrM+kl6BGrm6Mnt+e07rl8EXasRCt bkXS1IrU4EHUD+7TJ7Y6QohscNyWutin1wl Archived-At: Subject: Re: [xml2rfc] xml2rfc online: references to I-Ds and associated dates X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 14:00:36 -0000 On 12.07.2019 15:44, Carsten Bormann wrote: > On Jul 12, 2019, at 15:40, Julian Reschke wrote: >> >> That seems to be a rather big change to be introduced without notice. >> >> I think the first thing that needs to happen is the RFC Style Guide >> would need to say how to handle the format. Right now it says "year >> month=E2=80=9D, and this is what tools have been generating for ages. > > Well, keeping with the style guide could now be the onus of the author (= i.e., author has to delete the day to fulfill the style guide). > I wouldn=E2=80=99t like that too much, as it makes automatically generat= ed references (e.g., from a DOI) harder to use. > > Still, I have no idea what the semantics of the style guide are here whe= n the interchange format is XML =E2=80=94 the full date might be there, bu= t the formatting tools don=E2=80=99t show it. What is governed by the sty= le guide? > ... The style guide says that RFCs and Internet Drafts are to be shown without date: And...: FWIW, it is silent about April 1st RFCs, but see: (April 2018) It is *also* silent about other kinds of references. In a perfect world, the formatter would not need any knowledge specific to what is being references. But that currently collides with the reference database and the style guide. Best regards, Julian From nobody Fri Jul 12 07:44:13 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E6612034A for ; Fri, 12 Jul 2019 07:44:12 -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, 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 iZefKq4cxKZP for ; Fri, 12 Jul 2019 07:44:10 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E0C2120350 for ; Fri, 12 Jul 2019 07:44:03 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1hlwmF-0003at-RS; Fri, 12 Jul 2019 10:43:59 -0400 Date: Fri, 12 Jul 2019 10:43:54 -0400 From: John C Klensin To: Henrik Levkowetz , xml2rfc@ietf.org Message-ID: <6BAEB8CB8436D7938BB5D807@PSB> In-Reply-To: <7138e8a5-1c7a-cb5d-2d00-35389a7fada0@levkowetz.com> References: <60AB35B3B946D11980DA5426@PSB> <7138e8a5-1c7a-cb5d-2d00-35389a7fada0@levkowetz.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [xml2rfc] xml2rfc online: references to I-Ds and associated dates X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 14:44:13 -0000 Henrik, This was definitely from the v2 formatter. If it is fixed in v3, that seems like a satisfactory answer and I'll work around it in the interim. thanks, john --On Friday, July 12, 2019 15:16 +0200 Henrik Levkowetz wrote: > Hi John, > > On 2019-07-11 23:51, John C Klensin wrote: >> Hi. >> >> I happened to look today at the reference produced for an I-D >> by xml2rfc (at least by the online version at >> https://xml2rfc.tools.ietf.org/ ) >> >> The XML for the relevant cited I-D says (irrelevant material >> elided and the identity of the I-D changed to avoid >> distractions): >> >> > target="https://datatracker.ietf.org/doc/draft-ietf-foo-bar >> /"> ... >> >> >> >> >> The output is "June 2019". > > After looking through various output formats, my conclusion > here is that this is the output from the v2 text formatter, > not the v3 text formatter. The v3 text formatter renders the > date with day, month, and year if all 3 are given. So going > forward, it seems that this has already been addressed > (assuming we leave the v2 formatter untouched at this late > stage in its life cycle). > > > Best regards, > > Henrik > >> >> Now, independent of what the RFC Editor decides to do with the >> reference entry when/if the document gets to them [1], while >> the document in which this is embedded is still an I-D, it >> can be very important to the reader to know which version of >> the I-D was cited and, of course, two or more versions of an >> I-D in the same month is not uncommon. >> >> Authors who are happy with month and year can presumably just >> leave the day out of the XML. But, if an author believes the >> day is important enough to include in the source file, why is >> that part of the date being suppressed? Is there any hope of >> fixing that, which would revert things to earlier behavior? >> >> best, >> john >> >> [1] It is a completely separate matter from the above and >> probably a topic for another list and another time, but the >> reality, IMO, is that there are two types of I-D references >> that might appear in an RFC. One is a recent draft that is >> still, or might reasonably expected to be, under active >> development. For those, the current "work in progress" form >> is appropriate. I'd still argue for explicit version numbers >> and dates, by they are probably of limited utility. The >> other is a document that is being referenced for historical >> context, has typically been expired for years, and for which >> it is clear that no further development will occur, possibly >> because the referencing document superceded it. If we are >> going to allow references to such I-Ds at all (IIR, for many >> years, we didn't) those references need to be complete with >> accurate dates and version numbers. In addition, claiming >> that they are works in progress, especially when the text of >> the document in which the citation is imbedded says that they >> are obsolete... well, I think the technical term in the >> bibliographical world would be "plain silly". But, again, >> that is a different set of issues from the above and not an >> xml2rfc problem, at least until policies change. >> >> _______________________________________________ >> xml2rfc mailing list >> xml2rfc@ietf.org >> https://www.ietf.org/mailman/listinfo/xml2rfc >> > From nobody Fri Jul 12 09:51:59 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB95120191 for ; Fri, 12 Jul 2019 09:51: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 elPmNQ1hkx1e for ; Fri, 12 Jul 2019 09:51:55 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3301512004E for ; Fri, 12 Jul 2019 09:51:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id BEDFD1C135C for ; Fri, 12 Jul 2019 09:51:45 -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 p4NBbnUdIanl for ; Fri, 12 Jul 2019 09:51:45 -0700 (PDT) Received: from [172.16.4.218] (unknown [65.213.217.186]) by c8a.amsl.com (Postfix) with ESMTPSA id 679691C135B for ; Fri, 12 Jul 2019 09:51:45 -0700 (PDT) Date: Fri, 12 Jul 2019 09:51:46 -0700 From: Heather Flanagan To: xml2rfc@ietf.org Message-ID: <4b13e6ed-346c-4a18-9017-b1a104967bf7@Spark> In-Reply-To: References: <60AB35B3B946D11980DA5426@PSB> <7138e8a5-1c7a-cb5d-2d00-35389a7fada0@levkowetz.com> X-Readdle-Message-ID: 4b13e6ed-346c-4a18-9017-b1a104967bf7@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5d28baa9_61c30361_13f3e" Archived-At: Subject: Re: [xml2rfc] xml2rfc online: references to I-Ds and associated dates X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 16:51:58 -0000 --5d28baa9_61c30361_13f3e Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Jul 12, 2019, 6:40 AM -0700, Julian Reschke ,= wrote: > On 12.07.2019 15:16, Henrik Levkowetz wrote: > > Hi John, > > > > On 2019-07-11 23:51, John C Klensin wrote: > > > Hi. > > > > > > I happened to look today at the reference produced for an I-D by > > > xml2rfc (at least by the online version at > > > https://xml2rfc.tools.ietf.org/ ) > > > > > > The XML for the relevant cited I-D says (irrelevant material > > > elided and the identity of the I-D changed to avoid > > > distractions): > > > > > > > > target=3D=22https://datatracker.ietf.org/doc/draft-ietf-foo-bar/=22= > > > > ... > > > > > > > > > > > > > > > The output is =22June 2019=22. > > > > After looking through various output formats, my conclusion here > > is that this is the output from the v2 text formatter, not the > > v3 text formatter. The v3 text formatter renders the date with > > day, month, and year if all 3 are given. So going forward, it > > seems that this has already been addressed (assuming we leave the > > v2 formatter untouched at this late stage in its life cycle). > > ... > > Hmmm. > > That seems to be a rather big change to be introduced without notice. > > I think the first thing that needs to happen is the R=46C Style Guide > would need to say how to handle the format. Right now it says =22year > month=22, and this is what tools have been generating for ages. > > Heather=3F > HI, April 1st R=46Cs should be the only ones with the day listed in the date.= Everything else should be month/year. I don=E2=80=99t think this should = necessarily be up to the author. That makes it something else the author = has to consider, OR something the R=46C Editor has to follow up on. It al= so becomes a semantically important implication to a far greater (and the= refore more confusing) extent than the April 1st situation. So, while I think we need the option for a date, it should be hidden for = the majority of R=46Cs. Internet Drafts have the version number, and the = Work in Progress label, and changes to that are a different topic we can = discuss later. -Heather --5d28baa9_61c30361_13f3e Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
On Jul 12, 2019, 6:40 AM -0700, Jul= ian Reschke <julian.reschke=40gmx.de>, wrote:
On= 12.07.2019 15:16, Henrik Levkowetz wrote:
Hi= John,

On 2019-07-11 23:51, John C Klensin wrote:
Hi= .

I happened to look today at the reference produced for an I-D by
xml2rfc (at least by the online version at
https://xml2rfc.tools.ietf.org/ )

The XML for the relevant cited I-D says (irrelevant material
elided and the identity of the I-D changed to avoid
distractions):

<reference <reference anchor=3D=22ID.draft-ietf-foo-bar=22
target=3D=22https://datatracker.ietf.org/doc/draft-ietf-foo-bar/=22> ...
<date month=3D=22June=22 day=3D=2212=22 year=3D=222019=22 />
</front>
</reference>

The output is =22June 2019=22.

After looking through various output formats, my conclusion here
is that this is the output from the v2 text formatter, not the
v3 text formatter. The v3 text formatter renders the date with
day, month, and year if all 3 are given. So going forward, it
seems that this has already been addressed (assuming we leave the
v2 formatter untouched at this late stage in its life cycle).
...

Hmmm.

That seems to be a rather big change to be introduced without notice.

I think the first thing that needs to happen is the R=46C Style Guide
would need to say how to handle the format. Right now it says =22year
month=22, and this is what tools have been generating for ages.

Heather=3F


HI,

April 1st R=46Cs should be the only ones with the d= ay listed in the date. Everything else should be month/year. I don=E2=80=99= t think this should necessarily be up to the author. That makes it someth= ing else the author has to consider, OR something the R=46C Editor has to= follow up on. It also becomes a semantically important implication to a = far greater (and therefore more confusing) extent than the April 1st situ= ation.&=23160;

So, while I think we need the option for a date, it= should be hidden for the majority of R=46Cs. Internet Drafts have the ve= rsion number, and the Work in Progress label, and changes to that are a d= ifferent topic we can discuss later.

-Heather
--5d28baa9_61c30361_13f3e-- From nobody Fri Jul 12 10:11:05 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A18F120370 for ; Fri, 12 Jul 2019 10:11:02 -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, 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 rGn-TLaEuu5g for ; Fri, 12 Jul 2019 10:11:00 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1277D1202F0 for ; Fri, 12 Jul 2019 10:10:59 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1hlz4Q-0003uZ-2i; Fri, 12 Jul 2019 13:10:54 -0400 Date: Fri, 12 Jul 2019 13:10:48 -0400 From: John C Klensin To: Julian Reschke , Henrik Levkowetz , xml2rfc@ietf.org Message-ID: In-Reply-To: References: <60AB35B3B946D11980DA5426@PSB> <7138e8a5-1c7a-cb5d-2d00-35389a7fada0@levkowetz.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [xml2rfc] xml2rfc online: references to I-Ds and associated dates X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 17:11:03 -0000 --On Friday, July 12, 2019 15:40 +0200 Julian Reschke wrote: > On 12.07.2019 15:16, Henrik Levkowetz wrote: >> Hi John, >> >> On 2019-07-11 23:51, John C Klensin wrote: >>> Hi. >>> >>> I happened to look today at the reference produced for an >>> I-D by xml2rfc (at least by the online version at >>> https://xml2rfc.tools.ietf.org/ ) >>> >>> The XML for the relevant cited I-D says (irrelevant material >>> elided and the identity of the I-D changed to avoid >>> distractions): >>> >>> >> target="https://datatracker.ietf.org/doc/draft-ietf-foo-ba >>> r/"> ... >>> >>> >>> >>> >>> The output is "June 2019". >> >> After looking through various output formats, my conclusion >> here is that this is the output from the v2 text formatter, >> not the v3 text formatter. The v3 text formatter renders the >> date with day, month, and year if all 3 are given. So going >> forward, it seems that this has already been addressed >> (assuming we leave the v2 formatter untouched at this late >> stage in its life cycle). ... > > Hmmm. > > That seems to be a rather big change to be introduced without > notice. > > I think the first thing that needs to happen is the RFC Style > Guide > would need to say how to handle the format. Right now it says > "year > month", and this is what tools have been generating for ages. > > Heather? Julian (and others), Please go back and look at the note that started this thread, where I explicitly said I was concerned about I-Ds and not final format RFCs. The details of RFC formats have _always_ been different than I-D requirements, with the most obvious example being different boilerplate. We do not obscure information in I-Ds by claiming all other I-Ds are works in progress. For I-Ds, whatever the nits checker may find (or thinks it finds) notwithstanding, we do not try to enforce references to most recent version in I-Ds (because the earlier version might be intentional. In the document header, I-Ds show full dates, show "(if approved)" on the update line, show the status as "Intended", and don't show an ISSN. And I-Ds show a full (with day number) date and an expiration date (also a full date) while RFCs (at least April 1 documents aside) show only month and year. One of the strong advantages of generic markup over the old methods of preparing I-Ds in ASCII text editors or in nroff is that most of those differences can be accomplished by using different style sheets or otherwise in processing for the two output styles. For the text of a reference, the easiest workaround for me (see the exchange with Brian) when I think the date is important is to simply generate the text file for posting and then spend two minutes with a text editor patching the dates back in. Unless the intent of being able to use I-Ds to get a preliminary concept document out there has been lost and the IETF has developed a serious attack of form over content, those RFC style requirements or recommendations don't constrain I-Ds. In particular, at your behest, I went back and looked at https://tools.ietf.org/html/draft-flanagan-7322bis-03#section-4.8.6.2. It (and its predecessors) say exactly what I expected them to say: they talk about RFCs and not about I-Ds. The only thing that most current draft says about I-Ds appears in the last paragraph of Section 1: "All RFCs begin as Internet-Drafts (also referred to as I-Ds), and a well-written and properly constructed Internet-Draft [ID-GUIDE] provides a strong basis for a good RFC." There is also the statement in Section 4.8.6 about normative references to I-Ds, but that has nothing to do with this discussion. Curiously 4.8.6.4 _requires_ that the full draft name, including the number, appear when (informative) references to I-Ds appear in RFCs, but not only is this something else that is not being enforced for I-Ds by xml2rfc or the submission tool, but the example at the end of that section doesn't bear "work in progress" and hence does not conform to the _current_ style guide for RFCs but anticipates a change that it makes. That proposed change is, by the way, interesting in another way, which is that it removes a requirement that is rather clearly specified in RFC 2026 Section 2.2. Although I believe that requirement is badly in need of adjustment to avoid silly states with historical references rather than references to I-Ds that are even possibly still under development, there is no "updates 2026" in that I-D and we don't make changes that modify BCPs (especially, IMO, that BCP) in an Informational RFC, especially one that will not be processed in the IETF Stream. So, this request is about one thing and one thing only. If the author or editor of an I-D decides that it is important to communicate some information to the reader because that information will be --in his or her judgment or the judgment of a relevant WG-- useful to readers in understanding what is going on, then, as long as the markup is correct enough to get through the processor, xml2rfc should not discard that information. If the IESG wants to constrain those choices, then the ID-guide should be opened and modified if there is community consensus for doing so. But this has nothing to do with the RFC Style Guide. I'd hope the different style sheets/ processors would smooth out any details there, but, if the RFC Editor says "you must remove all day attributes from dates in references before the document is handed off to the RFC Editor", I'll deal with that issue when the time comes. Heather has already said, several times, things equivalent to "if you want documents to go through the production process quickly, don't say 'the RFC Editor will fix that'". I've got that and figured out long ago (while Jon Postel was still the RFC Editor) that the more I can get a document --editorially and structurally-- into RFC Editor form before it is handed off, the faster things will go and the less aggravated I and the RFC Editor staff will get during Last Call. So, great advice, but it doesn't have anything to do with this request either. best, john From nobody Fri Jul 12 10:20:24 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19AD61203A3 for ; Fri, 12 Jul 2019 10:20:23 -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, 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 r4Mvo7wb9gxC for ; Fri, 12 Jul 2019 10:20:20 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [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 A5BCE1202F0 for ; Fri, 12 Jul 2019 10:20:20 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:61963 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 1hlzDV-0000Pr-7s; Fri, 12 Jul 2019 10:20:18 -0700 To: Heather Flanagan , xml2rfc@ietf.org References: <60AB35B3B946D11980DA5426@PSB> <7138e8a5-1c7a-cb5d-2d00-35389a7fada0@levkowetz.com> <4b13e6ed-346c-4a18-9017-b1a104967bf7@Spark> From: Henrik Levkowetz Message-ID: Date: Fri, 12 Jul 2019 19:20:07 +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: <4b13e6ed-346c-4a18-9017-b1a104967bf7@Spark> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sJLkdc75w94UTHc7ueUqPSJUmp8q5GbP2" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, rse@rfc-editor.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: [xml2rfc] xml2rfc online: references to I-Ds and associated dates X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 17:20:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sJLkdc75w94UTHc7ueUqPSJUmp8q5GbP2 Content-Type: multipart/mixed; boundary="drbISrtGkaNeXRgA15c2LLbDx7E0cAwMa"; protected-headers="v1" From: Henrik Levkowetz To: Heather Flanagan , xml2rfc@ietf.org Message-ID: Subject: Re: [xml2rfc] xml2rfc online: references to I-Ds and associated dates References: <60AB35B3B946D11980DA5426@PSB> <7138e8a5-1c7a-cb5d-2d00-35389a7fada0@levkowetz.com> <4b13e6ed-346c-4a18-9017-b1a104967bf7@Spark> In-Reply-To: <4b13e6ed-346c-4a18-9017-b1a104967bf7@Spark> --drbISrtGkaNeXRgA15c2LLbDx7E0cAwMa Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Heather, Below: On 2019-07-12 18:51, Heather Flanagan wrote: > On Jul 12, 2019, 6:40 AM -0700, Julian Reschke ,= wrote: >> On 12.07.2019 15:16, Henrik Levkowetz wrote: >> > Hi John, >> > >> > On 2019-07-11 23:51, John C Klensin wrote: >> > > Hi. >> > > >> > > I happened to look today at the reference produced for an I-D by >> > > xml2rfc (at least by the online version at >> > > https://xml2rfc.tools.ietf.org/ ) >> > > >> > > The XML for the relevant cited I-D says (irrelevant material >> > > elided and the identity of the I-D changed to avoid >> > > distractions): >> > > >> > > > > > target=3D"https://datatracker.ietf.org/doc/draft-ietf-foo-bar/"> >> > > ... >> > > >> > > >> > > >> > > >> > > The output is "June 2019". >> > >> > After looking through various output formats, my conclusion here >> > is that this is the output from the v2 text formatter, not the >> > v3 text formatter. The v3 text formatter renders the date with >> > day, month, and year if all 3 are given. So going forward, it >> > seems that this has already been addressed (assuming we leave the >> > v2 formatter untouched at this late stage in its life cycle). >> > ... >> >> Hmmm. >> >> That seems to be a rather big change to be introduced without notice. >> >> I think the first thing that needs to happen is the RFC Style Guide >> would need to say how to handle the format. Right now it says "year >> month", and this is what tools have been generating for ages. >> >> Heather? >> >=20 > HI, >=20 > April 1st RFCs should be the only ones with the day listed in the > date. Everything else should be month/year. I don=E2=80=99t think this = should > necessarily be up to the author. That makes it something else the > author has to consider, OR something the RFC Editor has to follow up > on. It also becomes a semantically important implication to a far > greater (and therefore more confusing) extent than the April 1st > situation. >=20 > So, while I think we need the option for a date, it should be hidden > for the majority of RFCs. Internet Drafts have the version number, > and the Work in Progress label, and changes to that are a different > topic we can discuss later. The current v3 tools will use day, month, and year if provided in the references file, but as the RFC references only provide month and year, except for April 1st RFCs, they will be rendered with only month and year as references. Drafts, as they normally have day, month, and year in the references file, will be rendered with day, month, and year as references. The only adjustment I think might be necessary in the v3 renderers would be if you would like draft references to be rendered without day when rendering an RFC. Best regards, Henrik --drbISrtGkaNeXRgA15c2LLbDx7E0cAwMa-- --sJLkdc75w94UTHc7ueUqPSJUmp8q5GbP2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl0owUgACgkQTptXS4+7 FxplExAAo/FX789k83TucNdA8tFACeGglUk0ZJrzIe17Fmv00EjW4VsYsp65Xenn Ezv9Kpg7VtrMs8RDoWfvxDr0mLavwimzNadoUpCLlrCir/ZTA2sL7+eF8cJK83Gj zvEIhpOkgXkGtSOYNLCOKAxwxrq531CHqO0gG1L04Fiqze8MALsMoBw2R4N514g1 oIZXznF/wVChN6iD0Ju+H+OWO1XiD6bnEZIkqyVDvrUyPvmFBOJBNZiMFWaJJpyU sIkEpXznHdaB03DHLWzpvO6I99xMaQXnlZ6CfkAWW8GtAezyMNCU4JLkmlKAiNCt sxIiO5Eyr8BjQmJpgb4RhNym7QcujswQjGUszSND0ud7teYAdvuVVWLThq+/b04F A/il/L31zWiigLOq85jLAqKbb6BW4wDAVm4yZo6j9g3D33ThQmgV/vvVIwRftRhz aCm/K+baIwYmS8HEi83JeTaJCgieq00BqgisHWOPwftdwgX/i4mkGGWdogtn4/Jm ixOC5gwuoZH6KOAzjfecTdcEmYUkjvkko2d5qjKmbRags+eerV3h5lF98XA1rc6Z IZpzW4uKWTlIePOObRUAac2+rFWX+XUMD1M8eEkUIzyBCx0p2I54ttmGEDlcjPcF kzZibrIv6zckWwEpPqS5lHRwUyYTRJIPa/UQSQb/yMdNZxfMhVs= =ve10 -----END PGP SIGNATURE----- --sJLkdc75w94UTHc7ueUqPSJUmp8q5GbP2-- From nobody Fri Jul 12 10:25:02 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B28F120311 for ; Fri, 12 Jul 2019 10:25:01 -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, 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 rMxSsMotCPVA for ; Fri, 12 Jul 2019 10:24:59 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [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 A897F1203A3 for ; Fri, 12 Jul 2019 10:24:59 -0700 (PDT) Received: from localhost ([::1]:55528 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1hlzI1-00025m-Mx; Fri, 12 Jul 2019 10:24:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Cc: xml2rfc@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: henrik@levkowetz.com X-Trac-Project: xml2rfc Date: Fri, 12 Jul 2019 17:24:57 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/411#comment:1 Message-ID: <084.01df63f6d4782bae59c6ac4e913bff2f@tools.ietf.org> References: <069.4a8db82a7bf050743b133a1486325bdf@tools.ietf.org> X-Trac-Ticket-ID: 411 In-Reply-To: <069.4a8db82a7bf050743b133a1486325bdf@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc] #411 (Version_3_cli_txt): title for appears to be required X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 17:25:01 -0000 #411: title for appears to be required Changes (by henrik@levkowetz.com): * status: new => closed * resolution: => wontfix Comment: Since there can be one or two level of , and both normative and informative references, and since RFC 7991 doesn't specify what should be rendered as Section Title if there is no entry, this cannot be implemented. -- ------------------------------------+-------------------- Reporter: julian.reschke@gmx.de | Owner: Type: defect | Status: closed Priority: medium | Milestone: Component: Version_3_cli_txt | Version: 2.23.* Resolution: wontfix | Keywords: ------------------------------------+-------------------- Ticket URL: xml2rfc From nobody Fri Jul 12 10:37:28 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80ADF1203B8 for ; Fri, 12 Jul 2019 10:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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] 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 1dR3jLEyBQbx for ; Fri, 12 Jul 2019 10:37:25 -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 46D991203C2 for ; Fri, 12 Jul 2019 10:37:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1562953018; bh=HIo/BHZ2gm57MRy8ODiLZVzsWMO3ZUfDWKqKnsoammM=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=RklTV8/peHY9RfM9u+JOb/Krk+L92mZ8VrYPV1+uolQGkBZEApCoaK6FKspxOpslS wNKxETH02HZ4jlJlfG+kdhvAF/PAQq63X2XDr2eF1cDp+wxpB3l2xZDOwdxH3TdR3X r8oaPaipMycBcNW60/dYyhYejaJ5aGNcih/1g/To= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([84.171.151.199]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M2wGi-1hktXx3d6K-003MQB; Fri, 12 Jul 2019 19:36:57 +0200 To: John C Klensin , Henrik Levkowetz , xml2rfc@ietf.org References: <60AB35B3B946D11980DA5426@PSB> <7138e8a5-1c7a-cb5d-2d00-35389a7fada0@levkowetz.com> From: Julian Reschke Message-ID: Date: Fri, 12 Jul 2019 19:36:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 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:qWeVb6C/JHgPZlk+dXxvt8fKzWzKIZHm7bccN9n66z/zVNUyXri ViUBhqNOeH0rsKJL7JT15oeven/4W+UYGM3SIo9xStw0cK3kOmIS7NybRdpqHH240KBfGbT yrvmNiKuzVmkX6qbogyfIZyWZMCTcgssrKHbNbBSNiiSmMxIveVxvJhiz8K7ybBibyOy2aO KQrxix2ji0oVhKw/hVq7A== X-UI-Out-Filterresults: notjunk:1;V03:K0:8mcUR1UWIw8=:LQWkNu0kJ85bljxtsHi+9h o79a/MmK0cOecBPKsRA/PZaTl0ZzsyYvqGnE/5S6DG5V1ibLOJgGghlJuEJXT0So2pPcvfqhC O6WCXPsy05C4svX9/g3UJgmbq+FhZRCKphNswfStrCoTHiJiO0u8VPEOmJIyRruYgb2Ud2mr+ yxTPNqfEEo8SKWznO1UqlTHRudPp6I3PHH0adErNdZQ8w8K0KkpbxwIjrX2tcGXFCZ6EVRvOn XrqBEng7ptK7XVgvzzJ5+7myYn1FzpJ7B4ib4CqOumv28nRkf9g9g4Jb3VCydxEyRlBdE/w7A CwddYwvxl4ciqygQx8sdhOyFypdQXKhTh47GDDSaHP0obgzzZnyW1wPs+vDSY5YvfN4H8iXma D8jud8ujrMtTfYSLHa0thEUtE0tDHmWnB8bPc367zr9u5kwDccdZdiA7Zx7Llml3xzVOPLzOq pMkp1wLIN2Sc3GMaBGZPSGbnLv4xYYwCb1NWj2tJx2qaTVMOIyTS5js9xzg1vBNUyN1LlT/10 ZuVQ7ulUahQ8KUANUzgCzcdx5OjoaGogJAFn4TkWvpsF7Ro40PIKiWfVIPBLmoXj8AgjveiOD NnnwxNc1LeLO6nsjfr71GyINWYZU5Z9p3Zl0C86bs2LwbH42DdksbzfQgaYGKYEtloINy84yx i7if1tf75v3cnslOl6jrB7ezgWYmFaJQLq0HZNw1yN1BuBkmGlwLx7KFrZuHQutTu/ZiBYMJL PrKjHnFBMsac0Ha/DvU8dqQyf+1tLFk1+kmwDJgztIbU/gvewzzC0Dn4/AzbzzKPU6XDabSNH Cd2gR1mWc07G+S5Ohgz5S8/Hb/rT6IJ26wBd1OcEnAKu5jXeh3EEjPkImdRWf6pxUa3vqyHvP VtsZIgxa8Xbd0RG414j2H3oqoydOiCDISALLQUcW4mYaHvRfKPUvcM+CAqFSkdMe/z1xPtbHj ZarDRw5F/9v1/9yfunqxTQWiIcatIRRGz0hvmr60YKeZQzKVcjXRHhjx3YR9J9iVZJ4X1RDvO Ir6E9PKTdrEceHPyxvF+4/LdfGgPAbu5nAoXwvAMTZr34JzTdGRT8ITx6pkTpwGjk8vdIyKCF /V6pO6C9xUkg0zC1MOYnwTkbpyRtzmYMFaz Archived-At: Subject: Re: [xml2rfc] xml2rfc online: references to I-Ds and associated dates X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 17:37:28 -0000 On 12.07.2019 19:10, John C Klensin wrote: > ... > Julian (and others), > > Please go back and look at the note that started this thread, > where I explicitly said I was concerned about I-Ds and not final > format RFC. Well, allow me to concerned about all types, being the author on an xml2rfc processor :-) > ... > So, this request is about one thing and one thing only. If the > author or editor of an I-D decides that it is important to > communicate some information to the reader because that > information will be --in his or her judgment or the judgment of > a relevant WG-- useful to readers in understanding what is going > on, then, as long as the markup is correct enough to get through > the processor, xml2rfc should not discard that information. If > the IESG wants to constrain those choices, then the ID-guide > should be opened and modified if there is community consensus > for doing so. > ... You're losing me. Why is the day of month of any relevance when the draft has a version number? Best regards, Julian From nobody Fri Jul 12 10:40:01 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49CC3120134 for ; Fri, 12 Jul 2019 10:40:00 -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, 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 c2-dwW1cfPu7 for ; Fri, 12 Jul 2019 10:39:58 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [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 3DFE31203FB for ; Fri, 12 Jul 2019 10:39:58 -0700 (PDT) Received: from localhost ([::1]:56198 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1hlzWW-00082B-NO; Fri, 12 Jul 2019 10:39:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Cc: xml2rfc@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: henrik@levkowetz.com, julian.reschke@gmx.de X-Trac-Project: xml2rfc Date: Fri, 12 Jul 2019 17:39:56 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/411#comment:2 Message-ID: <084.c4aadaf40d4d3b696074c9b79092fabd@tools.ietf.org> References: <069.4a8db82a7bf050743b133a1486325bdf@tools.ietf.org> X-Trac-Ticket-ID: 411 In-Reply-To: <069.4a8db82a7bf050743b133a1486325bdf@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, julian.reschke@gmx.de, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc] #411 (Version_3_cli_txt): title for appears to be required X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 17:40:00 -0000 #411: title for appears to be required Comment (by julian.reschke@gmx.de): RFC 7991 doesn't specify rendering. Historically, when there was no name, the title was "References". This has worked for ages, so I don't understand why it needs to be dropped. Apparently nobody has written that down, and we should have done that somewhere. Failing on the input is a bug, until you add that costraint to the documentation of the language. -- ------------------------------------+-------------------- Reporter: julian.reschke@gmx.de | Owner: Type: defect | Status: closed Priority: medium | Milestone: Component: Version_3_cli_txt | Version: 2.23.* Resolution: wontfix | Keywords: ------------------------------------+-------------------- Ticket URL: xml2rfc From nobody Fri Jul 12 10:44:26 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC895120450 for ; Fri, 12 Jul 2019 10:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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] 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 b7ddONC-sb9w for ; Fri, 12 Jul 2019 10:44:23 -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 C8F90120134 for ; Fri, 12 Jul 2019 10:44:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1562953452; bh=G642oaV9/Bjrxp5y/sQwZzMMxWGyaoEmcqoJLOqU9X4=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=A2grQN4by8fD5aI7QOLImGpEwHhbk80NEED3xP8hwgxnRfZ0s33hyKSN8CBzZRhwp /cMOXVmgjWKAMfkFeJJcgfcQDGKnPp+LZcS8XT05XF/pzgk282A4uwtR7WTNwZ+Xpg Qdp70iSZ+ibVOfcFJTw7kE/ETQ4nIyjrlsnU+G94= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([84.171.151.199]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lubnw-1iTohY3CW8-00zjvY; Fri, 12 Jul 2019 19:44:12 +0200 To: Heather Flanagan , xml2rfc@ietf.org References: <60AB35B3B946D11980DA5426@PSB> <7138e8a5-1c7a-cb5d-2d00-35389a7fada0@levkowetz.com> <4b13e6ed-346c-4a18-9017-b1a104967bf7@Spark> From: Julian Reschke Message-ID: Date: Fri, 12 Jul 2019 19:44:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <4b13e6ed-346c-4a18-9017-b1a104967bf7@Spark> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:dU3FD0tZIMXzMmexB3hiQXB6zThsSB92Zc2sAtTvh25m7V6p6d/ xdJuR8GA3S9TjKL+z/cRFKeclPRAj5AB+FzkWkst9S3gXr115Lv5UkuEraoPQYVGuSDIoxp IHxkFjr1D/TtKJsYFiPSYJ84Lzf3cxzZp/3RayTw+ogkWHf0XYqpOgER7V63IiC3fWZjvgA +zx6eXbQXboyYhpYpqxeA== X-UI-Out-Filterresults: notjunk:1;V03:K0:ruW3fxT6lcQ=:pBFteldrgxsNOgBb3/t8yt 2RkUFIuZAunpQz2Yom61Y8cQ8aMB9AeO2bHwYLNnNlzrvLcu7ymWWfqk23Du2bcSKtJl6kgdr J5mkTpfVpRIh12ZPUnpHOXnDRiSqlPJWgbNynh2oMpV9DlbxWmf9/WrlIFcy3g4TwEmnZaQDX p+ywF9im1LcqQ5swsAGtUyxip3mS+v7PQV96vNPWBqj4zRziP7xU4Df21omSjNk/ul4xC5Vji o0NRiBFXGx/lva/sT+U8atiNYAvWI0nM2FqQKtJ51ScNo184vkFcm0ar6vO5/CIstqAnNwykU u5ZCmQ5L7rU62oy00kjMdUkoBJHlDTa2cHNybbwgGwUweaAEsDNNfwKMD0eu+V/9RkYeVFWsk h91gNzxOCCyT7L3LtjgIJnoqVsB9URllLmyzaA8dUa+w3HKyKDopx/rjUccwiczAIXbSsapLa V2+yn1GhB3HLkCALv+8tVwlxiLMmJ9RRNcVtTbXTAobzGlqz2LaK59CH3HAo/sMCX7a2pmeo7 7Ng00+0MAJ11zDIOf1enkM9X9MzQZPvaTNUOKPOn1nc7GJ29XgseDFkXhF3UtCdXuqEUWtGEY fHXt08SBTnVmuPozjQizfGlb/NWP2lwcrrUeu0AqTUt3IRzkXNhK3yObmLFYDhOKKzi0b3Vdk j/sE+uQmm6IIdAjorzGse/YAHnbCjmxCEH6DWgwiqTFO8GXHl3nPZkLkITjZfogvw0OTOWMez dmLfc4TdruRa4Ogy5p3kHROfxCRHVo4GFhO2DpTiMLf2lZxB6ObiDGgu6ANwG3HlTLr+6BO/u P4J6Ejh9DqL7TI0HyrNifK82G3eYv5xWJFN4VJU6eJfphepAlELLCBG9pNv1KoOJ3wyCHLxPO zqm9nu5WIgt2DjL94XHgeU1A6oWbElREgVykeARKZT63Z1wHca4lvifeiKP4NGykUQmK755l5 5NUwu9p+EYap40ffCa8r9pLjeM5G6M+uR77kYWgYVbxt+41KQV16VXz9H/1pQy4TGds3SUssM IbPbjjSY20TItyRaqTtOwtj+igLC7EndeWHEZ4xlaIBSAcUqNnY0ovyNkmeE3CqdUFFpb6Pmd ttgZyvct7bgwdM1GPjYXRBzMnjkB3EpgER2 Archived-At: Subject: Re: [xml2rfc] xml2rfc online: references to I-Ds and associated dates X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 17:44:25 -0000 On 12.07.2019 18:51, Heather Flanagan wrote: > HI, > > April 1st RFCs should be the only ones with the day listed in the date. > Everything else should be month/year. I don=92t think this should > necessarily be up to the author. That makes it something else the author > has to consider, OR something the RFC Editor has to follow up on. It > also becomes a semantically important implication to a far greater (and > therefore more confusing) extent than the April 1st situation. > > So, while I think we need the option for a date, it should be hidden for > the majority of RFCs. Internet Drafts have the version number, and the > Work in Progress label, and changes to that are a different topic we can > discuss later. > ... So then who is in charge to decide whether the day of month is inserted? 1) The author? (in that case, the citation libs would need to drop the date for internet drafts) 2) The processor? (in which case it'll need an extra signal for April 1st RFCs) This may have been not so important in the past. But in the v3 world (AFAIU), there will be no manual post-processing step anymore, so whatever the formatter emits will be what people see... Best regards, Julian From nobody Sat Jul 13 04:45:26 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D24C0120222 for ; Sat, 13 Jul 2019 04:45:23 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 wfJREBd5_yk8 for ; Sat, 13 Jul 2019 04:45:21 -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 0843C120113 for ; Sat, 13 Jul 2019 04:45:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1563018315; bh=I0SAIKIkN+suiXvjoxoZ39KivG7PAUYEeGgeL5SqTH4=; h=X-UI-Sender-Class:Subject:From:To:References:Date:In-Reply-To; b=h5TsW3AeqzibWBIr3V5EjwyXoYEGdxOJ9prLg7hPX3zlFddyTRZ+9E0/emPqKw5Hw 6rgIjeBE9lq3/fVzx3N2gd7DxGc/8XeGEuDGLS7NAZQhu/Tt8+Wbe7bFDfHf1ZZ0gb YVoOxbZAZSaZCgpRHQJ1J7YIypfQmVk4hHGrSW0c= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([91.61.55.206]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MSKuA-1hsq1q3jS4-00ScXO; Sat, 13 Jul 2019 13:45:14 +0200 From: Julian Reschke To: Heather Flanagan , xml2rfc@ietf.org References: <60AB35B3B946D11980DA5426@PSB> <7138e8a5-1c7a-cb5d-2d00-35389a7fada0@levkowetz.com> <4b13e6ed-346c-4a18-9017-b1a104967bf7@Spark> Message-ID: <66a49288-c015-645a-aed2-1c12170eb79d@gmx.de> Date: Sat, 13 Jul 2019 13:45:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 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:2ntimLvpgRmnJ1qA90yQlOZGgSfwdQwqVRKyHYByi9BA+emoqF0 aDGUBxvFSEY4WWKimVdqtLQaKqva5QVwU+gvB7BDXBcFH2nC24r5WwD0DIhnM+Tcb0Jz1DW MSm078szWeAo/YE3PGUtQvgCq1LUrKoaGQzQhQeT8uAum1Ky2jEHSEV+3eAg5qDdpn1ygC8 9qW46U8veF1qmA5YXT3IQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:aRUiyitfuqY=:m2fPjsde394q/ATwzcjxTo 8+CDwQiGtkn9aE480ZpompHpk5TCYfh5V8voiqmDMHcgwLH/0c8M4GHJWiU7G2C5Xny7hcBEW pK//kYWCyQriUSONKI+Eto1lDe6bNd92r5BDy9mdBvs4/c34Rrh6O7ntHAdUmEbnUN9DOMmjn 5cuDPg0fLVgQWvMstqqIlvHMaplCdBl1XUueR0cPJpszeFfQ6rkPRFd9Ak7Ml8Sny7hxwflVm zw5xqrgHQGbXPiq0D5y0/inC9Nf2bE298dOu80GV8UQdnSOKxPEv0LLSP0YuVfBhjRytUczjc xB6UZEZdmv7z7fgg+DgnyjjSb20zGTAj+p7E44rVOvDIo5Q/kSGBl+YTLyKakD0HOSMNORw71 mJe/CWSnInaPLvuFMmiLkGpNIYhZUgUtZ/82QbRj5b4LQKXOUL92WsGr7W0QB8SA6DSovO8Km MC7lPYavjVx1lWBew/m/cBAhddls0ANsFGdkUn0SvsRIlF59Fseh7WId4q8bHpyFsvHxXU96m WelqY8WMBdi6pY80mQY+j5Lhd0Zu+REjcU61XSjzGlHPZ4CCQIW/293H8kb5BsM8A3Een50gW tfwDVx+9KRCnerRiXgYmHwInMNrAkL7aq446NBRV35GFEf/KvcEg4BkKO1i9y2TtbBWLoLcpi fIFiI43hI3bClcwi1StIfBFNTRHyEnqzsXvI1SKhMbCbdHJJBPtEQOkxyWnMGc21lb7lbie5p ufCZTU1Ouwe6aHT68f4bVV5Z0cgOxohRbB6Euiy5YNooDCcBgu9dV90rv01fe/Ab0L8RFjeeU zlIJ5a0LNjZysLDdrEJ/LnBKQJngAaGcdMu+1+rnJcWl0vG0OY0Be03sonGF1ujwyNvhn89vb vPOryRAyl9LYIrjRgn7I+A91zMMGQq1p0AcoHdzm1EcdXiIcIVZjg11q8OfWk9zjsJVZUKBw0 I1obG2PeGbhoLyTaRQiCR4n+r1SDaZvkw32tmQGtlBi83SuOJmTvBblSkRogpItI+40fW9YW4 YiFKl84zUckxzozNxqHCMRky4Kg2LI8OtktzxPheOycp00c5FgywXSzlCtKpMzTJ+ZGy+PDDh KOE+nNIMwTiWFfwDLWFHTN7wr18N5XBxnZr Archived-At: Subject: Re: [xml2rfc] xml2rfc online: references to I-Ds and associated dates X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2019 11:45:24 -0000 On 12.07.2019 19:44, Julian Reschke wrote: > ... > So then who is in charge to decide whether the day of month is inserted? > > 1) The author? (in that case, the citation libs would need to drop the > date for internet drafts) > > 2) The processor? (in which case it'll need an extra signal for April > 1st RFCs) > > This may have been not so important in the past. But in the v3 world > (AFAIU), there will be no manual post-processing step anymore, so > whatever the formatter emits will be what people see... > ... Proposed extension: Example: Best regards, Julian From nobody Sat Jul 13 15:17:58 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D351C12015A for ; Sat, 13 Jul 2019 15:17:56 -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, 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 VnfYHWLQ5fev for ; Sat, 13 Jul 2019 15:17:55 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D757120141 for ; Sat, 13 Jul 2019 15:17:55 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1hmQL0-0007UH-CE; Sat, 13 Jul 2019 18:17:50 -0400 Date: Sat, 13 Jul 2019 18:17:44 -0400 From: John C Klensin To: Julian Reschke , Henrik Levkowetz , xml2rfc@ietf.org Message-ID: In-Reply-To: References: <60AB35B3B946D11980DA5426@PSB> <7138e8a5-1c7a-cb5d-2d00-35389a7fada0@levkowetz.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [xml2rfc] xml2rfc online: references to I-Ds and associated dates X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2019 22:17:57 -0000 --On Friday, July 12, 2019 19:36 +0200 Julian Reschke wrote: > On 12.07.2019 19:10, John C Klensin wrote: >> ... >> Julian (and others), >> >> Please go back and look at the note that started this thread, >> where I explicitly said I was concerned about I-Ds and not >> final format RFC. > > Well, allow me to concerned about all types, being the author > on an > xml2rfc processor :-) > >> ... > So, this request is about one thing and one thing only. >> If the author or editor of an I-D decides that it is >> important to communicate some information to the reader >> because that information will be --in his or her judgment or >> the judgment of a relevant WG-- useful to readers in >> understanding what is going on, then, as long as the markup >> is correct enough to get through the processor, xml2rfc >> should not discard that information. If the IESG wants to >> constrain those choices, then the ID-guide should be opened >> and modified if there is community consensus for doing so. >> ... > > You're losing me. Why is the day of month of any relevance > when the draft has a version number? I fear we are not communicating. Let me give you two reasons. The second one is the important one; I wonder whether the first one is enough of a distraction that I should omit it. (1) Suppose that there was some external event or announcement that interacted with the subject matter of an I-D (a product being shipped or the announcement of a really nasty vunerability come to mind as possible examples). It would then be helpful for the reader to be able to tell, quickly, whether there is any chance that the I-D might have addressed those issues. Certainly that date information could be determined by going to the tracker with the version number and looking up the date there, but I don't think our goal should be to see how many hoops (or page clicks) we can get the reader to jump through. I hope you agree. (2) As long as the purpose of posting documents as I-Ds includes allowing authors or groups to expose ideas to the community for discussion, editorial decisions about what belongs in those documents should be in the hands of those authors. Neither the community, nor the authors of a production tool that is recommended by the community for use with I-Ds, should make stylistic decisions that affect what information is presented without a compelling reason. So the question isn't why I might want to display the day of the month, it is why you (or some other tool author or specifier) should tell me I can't have it displayed. I note that we do have some requirements about content. For legal and related reasons, I-Ds are not allowed to be posted unless they contain one of more of a selection of specific statements. If some authors doesn't agree, they just don't get to post. The same comment applies to some extremely basic format/layout requirements that make the collection more manageable. For similar management reasons, there is even supposed to be a rule about file naming but people ignore it with impunity. The community has decided that documents MUST have Security Considerations sections but, even for that, we allow versions of I-Ds to say "to be supplied" or equivalent up to the point that the community, via a relevant Stream, is asked to process them. All of those requirements exist for substantive reasons and there is rough consensus in the community that they are important. One thing they have in common is that they specify information that is required to be present, not information that is required to be omitted. We do have a few rules about what must be omitted or that is not allowed to appear, but they are tied to IPR, e.g., I'm breaking assorted rules if I use an I-D to disclose someone else's trade secrets. However, that is a little different from a day number. Actually, IMO, it is a lot different. As a specific case of more general principles, I imagine that there is informal community consensus that foul, obscene, or inherently denigrating language does not belong in I-Ds. However, even then, I don't believe it is in the community's interest to have the xml2rfc processor silently remove the words. If you did so, I'd assume some authors would claim the processor and its authors were behaving inappropriately, possibly by censoring their freedom of expression or possibly by causing them to look like illiterates by destroying their sentence structure. If you wanted to make a case that the processor, upon discovering such a word, should put up an error messages about a prohibition on obscenity and then stop, I'd think that would be a better choice, but I don't think it would be reasonable for the Tools Team to decide to do that without at least some evidence of community discussion and consensus. In any event, the exclusion of a digit or two does not fall into a foul or obscene language category. The processor is simply removing information that I, as author, believe is important enough to include in the XML and removing it because you someone decided I didn't need it. I assume from this thread that you think it is my obligation to convince you otherwise (that I do need to have it displayed), perhaps even on a case by case basis. I hope we have not reached the stage that the IETF works that way. best, john From nobody Sat Jul 13 22:31:40 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 578DE1201D6 for ; Sat, 13 Jul 2019 22:31:38 -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, 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 (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 3Iv1LHuSH083 for ; Sat, 13 Jul 2019 22:31:36 -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 7D9911201D2 for ; Sat, 13 Jul 2019 22:31:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1563082290; bh=MBZJajORWYtL2iwiTLK2zzl3zdP8zpZdmxEHLcYGVRo=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=E7SOxJOd3X6TVgF4ddDa/DWwKoqobeNb0LXxrIkk0+klB+hBeVFBPCufU8F3dRitw QHL8b6IiHGKRF1viEQaAw9kW6rgKNGqd5mjer4xjkPQxl3Rrt3nSG1q7n3/LNjsp/r aWK2e4POngjJflf2ybpoPCMNgSAe7C4qZ3cnskpY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([91.61.59.178]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MMjgF-1hpWtr1bZP-008WYx; Sun, 14 Jul 2019 07:25:52 +0200 To: John C Klensin , Henrik Levkowetz , xml2rfc@ietf.org References: <60AB35B3B946D11980DA5426@PSB> <7138e8a5-1c7a-cb5d-2d00-35389a7fada0@levkowetz.com> From: Julian Reschke Message-ID: Date: Sun, 14 Jul 2019 07:25:48 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.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:2tREKuP6ogtHJ+nzieAhgYVP3qEdIWVyQd+Q/YJt0g7yXSkZP/3 uz6a1v2UcDFGq0czxPauI4G7TUBw2e+hqNPz36P09sP62Ro70hxpWdIWJrqVwor7Exqzl0W MVixgeEvLlWqw5WkY6XLvr1AK1/Hm5YPCy2ypcAxMuUrBSqMsTFjfPcYAHndIFvYgFQIXgh Bf3ZK01D/wLWo5vPpFqXw== X-UI-Out-Filterresults: notjunk:1;V03:K0:3uqpretYaEI=:tkGCYnBvw05UdYpmmHoS2j LKmPAtqMmbMOpFCgV66glLewzvX14IO5gVQPTjMkZall+oCaH5j7OMasbMGyGLTCthUlFBNJP sKKJaSVnWgOcTfZWJRULtkK7AYmXqcicJr6p32AhKg0Ty81AokUx8QxBHd931cXu9DWxe+Ze7 T2ntc3h6ypjWGK6CCTbAx18/Xm0hOrj0WYmDpqkl2WAvikFdRWceywJoR/sIpWtqC9/AVoD11 eefilbTHFSfkYwbgE2hGhIk+KJOtRMm8l8+/RHTflh1TD+wRkdfzerHBRW4WGQoRGtwp5XkCw HYXyjKMI7J56fmYNCBDlzHaoyWy5Z3f3zT7iOpT3wPRfS3g1graksNZ3vYr8KeJ9SWHlPV5lB A0KdHyHwVbXt/ZSg5bycd8Met/kNxy+QTzdeV03RBAC9E0R1VaU/h+ILL9sPWwjv1AQIAZ3zx IORWwj1TFyRrXLgTBH1Vx5z3dk6vuJ7UCmpTkUvcum8n5zG/qXbd9pFFS/j9+qb7ZsT7miqfn c2Gf02ilLOfD6mpgsp9C4ORnEt2TdLdQKg0iaVkC0b32WBf5PmOl2mOt7aAT/ZoXNbwaolf8D pVtgGfEu/g0BVXIDnN40DJkJpF+BAxFB5a7PG16TC62DWGuwL8TIkUxd6uNkMR+V46d7UHsTG BdyBZlQxpJGSigdlM+a9Fbsk+YlbtnMyKoTVoxFDq1ObkgDr3Q+SijcNy6IxkxS/izbBCqg53 2eYXqTfuNNKlk3jfepLFF0QMvVRyQNxb2CRKMHp4jw2ZfWEJm/gO+j+I1jsOD4nxeNhwPgC62 HeVyohm6nH5oIcsleNlyqef8ETNSNI8BXcZJvM41YeYxrqrlCGucR/ZWCATEFbU5GcJxrzsY9 ZmWEl4M9YXA0avUs+9YAipVk66RHqn3kfwhs6BIGTfXSstN0L4upHRmRyMuLajDVrlA97Vrl4 SDDjkZM2rW7YcXN3xn6v8H61Dnml2BPdZapPOCabqEaUvtR/sya7kTb7aj8c7Oc5nfjjsCn11 UikI1LO8dnI4Opl+L2PikvhI8NTF6n+r9NSOWS+zxpLil2+s6VCVjNsynl0zfGUsaDGu23gzJ y2xko4V6XVbJu19SJAGlXpnIM78x+OpQNKw Archived-At: Subject: Re: [xml2rfc] xml2rfc online: references to I-Ds and associated dates X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2019 05:31:38 -0000 On 14.07.2019 00:17, John C Klensin wrote: > ... > I fear we are not communicating. > ... Are we not? > Let me give you two reasons. The second one is the important > one; I wonder whether the first one is enough of a distraction > that I should omit it. Examples are good. > (1) Suppose that there was some external event or announcement > that interacted with the subject matter of an I-D (a product > being shipped or the announcement of a really nasty vunerability > come to mind as possible examples). It would then be helpful > for the reader to be able to tell, quickly, whether there is any > chance that the I-D might have addressed those issues. > Certainly that date information could be determined by going to > the tracker with the version number and looking up the date > there, but I don't think our goal should be to see how many > hoops (or page clicks) we can get the reader to jump through. I > hope you agree. I agree with the goal, but not with the conclusion. First of all, with a sane format, you need exactly one click to get to the referenced Internet Draft, and that will have the date on the front page. (This is true today for the HTML version on tools.ietf.org, and will also hopefully be the case for xml2rfc's v3 HTML output). That said, it is already possible to annotate a reference with any prose you like. So if you want to say something like "this draft addresses the security issue raised by xxx on yyy", you can already do that. (, ). > (2) As long as the purpose of posting documents as I-Ds includes > allowing authors or groups to expose ideas to the community for > discussion, editorial decisions about what belongs in those > documents should be in the hands of those authors. Neither the > community, nor the authors of a production tool that is > recommended by the community for use with I-Ds, should make > stylistic decisions that affect what information is presented > without a compelling reason. So the question isn't why I might > want to display the day of the month, it is why you (or some > other tool author or specifier) should tell me I can't have it > displayed. > ... xml2rfc tries to formalize/automate things that historically happened at RFC production time. One of these things is consistent style of bibliographic references. The goal is to produce the format that the RFC Style Guide asks for. Now that is for RFCs. Using xml2rfc to produce *Internet-Drafts* is a slightly different use case. My understanding is that people use xml2rfc for this because it will reduce the amount of formatting changes when going to RFC. So here the question would be: do we need more freedom in references styles in Internet Drafts, as opposed to RFCs? That's definitively an interesting discussion, and maybe the outcome is that we need to make changes on the RFC Style Guide side. And yes, I understand that what you say applies to all of the text, not only reference styles. That's a broad topic, but then, I'd prefer to discuss concrete use cases, not the whole philosophy. Best regards, Julian From nobody Sun Jul 14 14:34:01 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD6E120296 for ; Sun, 14 Jul 2019 14:33:59 -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, 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 bXdYE3bZGyLr for ; Sun, 14 Jul 2019 14:33:56 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA13F120297 for ; Sun, 14 Jul 2019 14:33:56 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1hmm7z-000B87-QR; Sun, 14 Jul 2019 17:33:51 -0400 Date: Sun, 14 Jul 2019 17:33:45 -0400 From: John C Klensin To: Julian Reschke , Henrik Levkowetz , xml2rfc@ietf.org Message-ID: In-Reply-To: References: <60AB35B3B946D11980DA5426@PSB> <7138e8a5-1c7a-cb5d-2d00-35389a7fada0@levkowetz.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [xml2rfc] xml2rfc online: references to I-Ds and associated dates X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2019 21:34:00 -0000 --On Sunday, July 14, 2019 07:25 +0200 Julian Reschke wrote: >... >> (1) Suppose that there was some external event or announcement >> that interacted with the subject matter of an I-D (a product >> being shipped or the announcement of a really nasty >> vunerability come to mind as possible examples). It would >> then be helpful for the reader to be able to tell, quickly, >> whether there is any chance that the I-D might have addressed >> those issues. Certainly that date information could be >> determined by going to the tracker with the version number >> and looking up the date there, but I don't think our goal >> should be to see how many hoops (or page clicks) we can get >> the reader to jump through. I hope you agree. > > I agree with the goal, but not with the conclusion. > > First of all, with a sane format, you need exactly one click > to get to > the referenced Internet Draft, and that will have the date on > the front > page. (This is true today for the HTML version on > tools.ietf.org, and > will also hopefully be the case for xml2rfc's v3 HTML output). Ah. And this may be another example of why our perspectives differ enough to lead to this disagreement. Suppose that, instead of reading the referenced Internet Draft in the HTML version and when I'm online, I'm reading the text version on paper, some version after it was downloaded to a disconnected tablet, or I am not reading it at all but using a screen reader to "speak" it to me. Under some circumstances, I might even extract some of it and read that part on paper. My reason for those choices might be personal preference of might fall into some "disability" category, but I think that someone's making assumptions that there is no good reason might reasonably be treated as discriminatory. With any of those scenarios, if I want to obtain the information you believe is easily obtained by clicking on a link that appears in the document, I need to get myself to the computer (or some handheld I'm willing to use for the purpose), bring up a browser, bring up either the document (and find the link) or the datatracker (and enter the name of the relevant I-D), then then do whatever I need to do to get to the information. To avoid saying something rule, please don't assume that everyone does, or even should, work the way you prefer and to which, I assume, you have regular and convenient access. > That said, it is already possible to annotate a reference with > any prose > you like. So if you want to say something like "this draft > addresses the > security issue raised by xxx on yyy", you can already do that. > ( ation>, > qvh6dLB_4r0w>). I've been using annotation elements for years. Now that I know that higher-precision date information is being discarded, maybe I will remember to put the information back in that way. But nothing in RFC 2629 or 7749 (particularly Section 2.13 or the text of 2.13.1 for the latter) for v2 or RFC 7991 (particularly Section 2.17) for v3 says, along with the "day" parameter "you can supply this if you like but, except for the date of the document itself for an I-D, we will probably just throw it away in the processor". Nor does the processor generate error messages about that discarded information. If I am aware that the information is being discarded, I have at least three choices, any of which may be reasonable under different circumstances. One is to just accept that. Another is to put annotations into the XML. A third is to open the txt output file and put the information back in, which might not be easier but is certainly more attractive given my particular editorial preferences. On the other hand, if the information is provided in the XML but silently discarded. But there is no hint to me that it will be discarded unless I carefully inspect the output. I suggest that is a disservice to the community. >> (2) As long as the purpose of posting documents as I-Ds >> includes allowing authors or groups to expose ideas to the >> community for discussion, editorial decisions about what >> belongs in those documents should be in the hands of those >> authors. Neither the community, nor the authors of a >> production tool that is recommended by the community for use >> with I-Ds, should make stylistic decisions that affect what >> information is presented without a compelling reason. So >> the question isn't why I might want to display the day of the >> month, it is why you (or some other tool author or specifier) >> should tell me I can't have it displayed. >> ... > > xml2rfc tries to formalize/automate things that historically > happened at > RFC production time. One of these things is consistent style of > bibliographic references. The goal is to produce the format > that the RFC Style Guide asks for. > Now that is for RFCs. Using xml2rfc to produce > *Internet-Drafts* is a > slightly different use case. My understanding is that people > use xml2rfc > for this because it will reduce the amount of formatting > changes when > going to RFC. So here the question would be: do we need more > freedom in > references styles in Internet Drafts, as opposed to RFCs? > That's > definitively an interesting discussion, and maybe the outcome > is that we > need to make changes on the RFC Style Guide side. There may well be some people who use xml2rfc for that purpose. At least some of the rest of us use it because we have gotten what has seemed to be a clear message from the IESG, from assorted WG Chairs (and in WG Chair meetings), and with reinforcement from the posting tool, that the best way (or at least one of the best ways) to get the boilerplate right and get a draft put together for posting. Our newcomer's tutorials mention only NROFFEDIT and xml2rfc as preferred ways to produce I-Ds although they now also talk about markdown as producing "the XML format accepted by the RFC Editor". See, e.g., https://www.ietf.org/about/participate/tutorials/process/creating-internet-drafts-and-rfcs/. None of those things suggests other alternatives so I would suggest that at least some people use xml2rfc to create I-Ds between that is what they were told to use or it appears to be one of very few plausible alternatives. However, in suggesting that this should suggest changes to the RFC Style Guide, I think you are missing the point I've been trying to make. That point is simply that, until and unless the IESG changes the rules and gets community consensus (or at least acceptance) for doing so, the xml2rfc processor should not be discarding information that is supplied in well-documented elements and their attributes, at least unless the documentation is clear that the information will be treated as noise. If the IESG does make such a change, the documentation should be adjusted accordingly. And... > And yes, I understand that what you say applies to all of the > text, not > only reference styles. That's a broad topic, but then, I'd > prefer to > discuss concrete use cases, not the whole philosophy. Ok. The concrete use case is that information I supply in markup, using elements and attributes that clearly permit its use, should not be discarded without warning or discussion. As an author, I note that if some information is included in I-Ds and then discarded by the RFC Editor, that change shows up in diffs and is subject to AUTH48 review. At that point, it is possible to argue about the appropriateness of the change and sometimes even win if there is a good reason. But the RFC Editor gets to supply guidance about what information should be in an RFC and how it should be organized (in both the general and in specific cases) -- that is their job. Tool implementers should not do that for I-Ds, especially without consultation with the community (or at least the IESG). As far as concrete use cases are concerned, that is where I started, with the discarded "day" information. If there are other places where information is being discarded from I-Ds because of an interpretation of what the RFC Style Guide says, those should be fixed too. I hope we don't have to play whack-a-mole if there are other cases of this. best, john From nobody Sun Jul 14 21:37:20 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90984120046 for ; Sun, 14 Jul 2019 21:37:18 -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, 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 l0zpXd0KpF9U for ; Sun, 14 Jul 2019 21:37:16 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54ED9120020 for ; Sun, 14 Jul 2019 21:37:16 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1hmsji-000BmQ-3y; Mon, 15 Jul 2019 00:37:14 -0400 Date: Mon, 15 Jul 2019 00:37:07 -0400 From: John C Klensin To: xml2rfc@ietf.org Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [xml2rfc] xml2rfc Digest, Vol 101, Issue 9 X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 04:37:19 -0000 On 12.07.2019 19:44, Julian Reschke wrote: >> ... >> So then who is in charge to decide whether the day of month >> is inserted? >> >> 1) The author? (in that case, the citation libs would need to >> drop the date for internet drafts) >> >> 2) The processor? (in which case it'll need an extra signal >> for April 1st RFCs) >> >> This may have been not so important in the past. But in the >> v3 world (AFAIU), there will be no manual post-processing >> step anymore, so whatever the formatter emits will be what >> people see... ... > > Proposed extension: > 9.date> > > Example: > I think this (including the proposed extension) is being made unnecessarily complicated and that x:include-day" ("true", "false") as proposed does not do the right thing. The system clearly knows whether it is generating I-Ds or RFCs. It clearly has to in order to generate different boilerplate. So, for RFCs: (i) The front page is always without a day-of-month unless some attribute or other flag is present (for the April 1 case). (ii) References use whatever content and format the Style Guide says what they use. If it is "Month Year" then maybe an attribute should permit an exception to that, but I doubt it will be used very often if ever. (iii) The Style Guide should be reviewed to make sure that a reference to a document published in a language other than English and whose preferred date is not in English (and perhaps not even in Gregorian calendar) comes out the way the RFC Editor wants it. I am largely agnostic as to what that is, but it should probably be sorted out and specified now because it may affect the markup. I would strongly encourage people to think about this using an example that is not drawn from Latin script or even a European script. For I-Ds (and any other non-RFCs of interest): (i) The front page is "month day, year". I note that the submission tool will reject an I-D submission if the day number is not present. If the xml2rfc developers want to provide extra generality by including an attribute to suppress the day, go for it, but I believe the only thing that could make that necessary is automatic date (including day number) generation when is used without all of "year", "month", and "day" attributes. (ii) References simply use whatever authors supply. If a day number is specified, it appears. If it isn't, it doesn't. Note that this principle is important for another reason and that is at least one reason why we don't make up date values when the element is specified without attributes: some journals publish only once a year and traditional books generally do not specify even month information. So what the author specifies, whether it be a year, a year and month, or a year, month, and day goes into the output. (iii) Finally, I think that using different date formats in different places (I'm talking about the format here, not whether or not a day number appears) is probably an invitation to trouble long-term. Perhaps, with the likely exception of the RFC header (and maybe footer), it is time to recognize that, along with other changes for the new format, RFCs are becoming "international" enough that it would be appropriate to go with ISO 8601 dates and be done with it, both in whatever in generated by markup and in Style Guide recommendations about any dates that might appear in running text. Or not. best, john From nobody Mon Jul 15 00:57:40 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FEFC1200B8 for ; Mon, 15 Jul 2019 00:57:39 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 ScyQ42nqZQRr for ; Mon, 15 Jul 2019 00:57:36 -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 26712120074 for ; Mon, 15 Jul 2019 00:57:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1563177431; bh=eFNvu0RKbmtPrGBU3OCx7Wyi0PWPnzRrefo3J0yGbV8=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=M87CLR78L/WzSwywiZJU2FtsdLfLOaxX7v+uM/vImuPomBaDjWRJoocsPvBTicMfz Auw7Z29ScgtPN88cUsLY/a7cd+waNh1JZgYKFaa+QHVQ64TR3E86gApineqUNdQctj lAgDxMa7l9CF2LQ418RoLpZp5ZIqcHAMRDbIYGTo= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([84.171.147.104]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M2f5Z-1hkTHc1jtH-004AAt; Mon, 15 Jul 2019 09:57:11 +0200 To: John C Klensin , Henrik Levkowetz , xml2rfc@ietf.org References: <60AB35B3B946D11980DA5426@PSB> <7138e8a5-1c7a-cb5d-2d00-35389a7fada0@levkowetz.com> From: Julian Reschke Message-ID: <9dda172b-4361-909b-f7ce-618671054306@gmx.de> Date: Mon, 15 Jul 2019 09:57:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.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:fqxNqOVG8BiXdQMTQzohynH0C8edgyUTExRgAVGEdoURcHev4/R 0BwGN3JFU1B86qF5tu69xW10ack1l4xL+y3lBbnVJOCdJV+hEHXUdS7D0ChvaFqciZx/k8j sG8Cp2fpJmS24aYk71ipAJuzHst0QJdlFSWmNGRRYpqpKZieV2eOLdYjWckTSdewh0Q5sbr c4irMnJCMx7I05k1YMfgg== X-UI-Out-Filterresults: notjunk:1;V03:K0:YO4HPTfhnG4=:8rR/yEZY+2DjyM/so9pV78 aU6JsGa0nyIdaef9M0JhHaNjMfCTU+yGJI+C8fmBo8GZyXnSyREjWI89/t50Ykzs4ECZqaEBn kFim+GWMMRQlOB23f1pHB1FgFqFm5xJ2wWv++WlGzP7wF/xu5jkg1zA6gGmYIBWWEYuFhuddw nplLPS96o33nWHpjlWNceW0ILUIUTJEroWNPP0Lle8XrSax9zF9W8GkezL5MaKkFdse9CdDNH WexYmQHerlPGpF+KeyGDWbT/NNsyQWiadnNndiwmpHZH4xhPzNzJiHJzyYclqdJV/AWOIbepL AiqnSVYrRZe610wNDbyZbdtmZW/M2XD+fWLQwycqXI+1dtQn4HYGy+65W6/ZYmqQnhH0tzQrr xjBDVCZyS6+uSMHN5LM++nyzUC4ea4z/LEWCiFn48o/vhH7z8gJbEp0KKvGZh4MyzWDRbwaWB iGNq0DVi1CdbFvZ6ZJdVHVMHPTsAW326P7qM2xRGabb/zdq05sqKZABkQ4ku9UJPJVEDBLT+o AlavTMt7AEJaPaTvHbcTAWv4erfh0mYaN+yrRhK9c6TFry0XGNYSPVqmaRb9KBu/ysaQH7kf/ rI9ow+Ltgv/uWuK9YGVlCXzEA2e5XR3yqKYViuBxSO6BTnROKsmejVbCOc9wDPCE07RvW2k4t DAjHSj1WAUhlSO+OulukZyZZ/m1iLrQXZg1WjgJCk8paa4O0lYtS0tSk/UCjQpbDF0JW2KnNA Ik9EDVVDEc+5173iKTu2x1Pi4VOzEUL/VE2WtjdQMHnqJdMc3TvaQY8Z6lvJ5wz32Wh8yj2Qb a/0nwMWyHCYmTqJk82JjMxfVbSaJCZOU5tohuyGoxJl9dDfwuVGZs4fd2nth1EcmoEP4wIyTj rIXVG+/yuhWZAp4/fzysMUJkufkvyCTigdgB3ZvliNMR7ppKR1FvJL+vihMyIxRomzb83y+TI ZfYGQu8XRffzdwlcMcBL4+tE8OPGjbmVMb9wERIbv4FFwWkAgr1vEQQ61RYsSrJkyqseYs27f uzHCs6YlCYfnQA+ESaTRKUd7yMwIiPT9DLW2HJ2ivc9oSv2SWkf7mtgZm7ZmRPR1+NzTPzg/E KPo/tKE7QQDanGXJ1UOp4+r8rYchYmtLcpG Archived-At: Subject: Re: [xml2rfc] xml2rfc online: references to I-Ds and associated dates X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 07:57:39 -0000 On 14.07.2019 23:33, John C Klensin wrote: > ... > Ah. And this may be another example of why our perspectives > differ enough to lead to this disagreement. Suppose that, > instead of reading the referenced Internet Draft in the HTML > version and when I'm online, I'm reading the text version on > paper, some version after it was downloaded to a disconnected > tablet, or I am not reading it at all but using a screen reader > to "speak" it to me. Under some circumstances, I might even > extract some of it and read that part on paper. My reason for > those choices might be personal preference of might fall into > some "disability" category, but I think that someone's making > assumptions that there is no good reason might reasonably be > treated as discriminatory. > ... I agree that there may be cases where following the link is not possible. I disagree however that because it may be possible to be offline, we necessarily need to inline all available information. > With any of those scenarios, if I want to obtain the information > you believe is easily obtained by clicking on a link that > appears in the document, I need to get myself to the computer > (or some handheld I'm willing to use for the purpose), bring up > a browser, bring up either the document (and find the link) or > the datatracker (and enter the name of the relevant I-D), then > then do whatever I need to do to get to the information. To > avoid saying something rule, please don't assume that everyone > does, or even should, work the way you prefer and to which, I > assume, you have regular and convenient access. Hm. Are you saying that we need to optimize Internet Drafts for recipients who do not have a computing device or connectivity? > ... > I've been using annotation elements for years. Now that I know > that higher-precision date information is being discarded, maybe > I will remember to put the information back in that way. But > nothing in RFC 2629 or 7749 (particularly Section 2.13 or the > text of 2.13.1 for the latter) for v2 or RFC 7991 (particularly Yes. The intent of RFC 7749 was to describe the vocabulary, not necessarily what formatting tools do with it. > Section 2.17) for v3 says, along with the "day" parameter "you > can supply this if you like but, except for the date of the > document itself for an I-D, we will probably just throw it away > in the processor". Nor does the processor generate error > messages about that discarded information. Note that that text is about the "prep tool", not the actual formatting tool. The problem with generating error or warning messages is noise. The reference files for Internet Drafts contain the day information, so you'd get one error per Internet Draft being referenced. Is that really helpful? > If I am aware that the information is being discarded, I have at > least three choices, any of which may be reasonable under > different circumstances. One is to just accept that. Another > is to put annotations into the XML. A third is to open the txt > output file and put the information back in, which might not be > easier but is certainly more attractive given my particular > editorial preferences. On the other hand, if the information is > provided in the XML but silently discarded. But there is no > hint to me that it will be discarded unless I carefully inspect > the output. I suggest that is a disservice to the community. Well, it has been like that for over 15 years, and as far as I can tell, it just has come up for the very first time. I understand that you see an important principle being violated, but please consider the history how we got where we are as well. > ... > However, in suggesting that this should suggest changes to the > RFC Style Guide, I think you are missing the point I've been > trying to make. That point is simply that, until and unless the > IESG changes the rules and gets community consensus (or at least > acceptance) for doing so, the xml2rfc processor should not be > discarding information that is supplied in well-documented > elements and their attributes, at least unless the documentation > is clear that the information will be treated as noise. If the > IESG does make such a change, the documentation should be > adjusted accordingly. And... > ... I'm all for documenting things. I actually spent a significant of time writing RFC 7749. It may not be perfect, but at least it describes the vocabulary at the time v3 was started (the vocabulary, not what formatting tools do with it). Also note that this is not the only piece of information that is "thrown away". re-uses , and that can contain lots of information that is not rendered in the references section either (workgroup, area, abstract...). Is that a problem as well for you? > ... > Ok. The concrete use case is that information I supply in > markup, using elements and attributes that clearly permit its > use, should not be discarded without warning or discussion. As That's not my understanding of a "use case". I understand this is a good principle, but then there are other principles which are good as well, and which this one conflicts with; namely the re-use of XML element definitions in different contexts. There's also the principle not to annoy users with warnings that they can't do anything about. > an author, I note that if some information is included in I-Ds > and then discarded by the RFC Editor, that change shows up in > diffs and is subject to AUTH48 review. At that point, it is > possible to argue about the appropriateness of the change and > sometimes even win if there is a good reason. But the RFC > Editor gets to supply guidance about what information should be > in an RFC and how it should be organized (in both the general > and in specific cases) -- that is their job. Tool implementers > should not do that for I-Ds, especially without consultation > with the community (or at least the IESG). I believe it would be a negative outcome if we started to have additional different rules for IDs and RFCs. That would mean that going from ID to RFC becomes harder. For the differences that are there, yes, it would be good to have them written down, and then potentially be reflected in the formatting tool. > As far as concrete use cases are concerned, that is where I > started, with the discarded "day" information. If there are > other places where information is being discarded from I-Ds > because of an interpretation of what the RFC Style Guide says, > those should be fixed too. I hope we don't have to play > whack-a-mole if there are other cases of this. > ... Have a look at the content model for , and you'll see that more data is already discarded. For instance, metadata is not necessarily used at all when formatting documents. Does this mean that there should be an error message? No. Because formatters are not the only tools processing the source files. Best regards, Julian From nobody Mon Jul 15 01:20:08 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82CE5120074 for ; Mon, 15 Jul 2019 01:20:06 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 a9gwDcV8Qh1H for ; Mon, 15 Jul 2019 01:20:04 -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 7FEBB12001E for ; Mon, 15 Jul 2019 01:20:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1563178794; bh=uvK4WIRlbx++PO8gSYcxkPnfPrDhmmboGy5T5YYiNjs=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=ks90Z3R3B1WRPlGeEQDUpYpztNpFYZBjaEOw0LXFG/sMfmGcvyzpTGF/3U53yr/ce kl14NIdab4d8FKjWfX42gHc1hfdt8UfHvapCIV2GGHth+yPlPEjpbfTCvXE+nn7hBB +HPm7RxrbDcw7ONZpT8gqPCExM6K3XDfe3FB7LF4= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([84.171.147.104]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LcT2M-1iCspQ2Ih4-00jsxS; Mon, 15 Jul 2019 10:19:54 +0200 To: John C Klensin , xml2rfc@ietf.org References: From: Julian Reschke Message-ID: Date: Mon, 15 Jul 2019 10:19:50 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.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:QNtE9ux5StQWHZP8KTpQFZaFSWPqv42Pc0biIYvbQV6D/nFgoQJ EYAOVo+Qj2SvdinLwXPQH8bklR2a+zsYls51lGWegLcyXwg7k1JA9oYQfBgR0bdSDhJT/nJ 1FO9gCeXn4Pw8dwmAaS/eDBV0LLJWii3urrCekCNYaHYE/PMI/BVny9LxgQX8NQR6tosGeW NAeWH+Hy+xILsfhSo7RKA== X-UI-Out-Filterresults: notjunk:1;V03:K0:Gd4naQo2YkA=:SFJ3s2z/fX/fbhkWdpWnvY fQ9OcooFZFNzHCN6/Ue7HZA6KerjpvAA5iN/Xa4gz+Fuf2S9Rdp2SA1afrf/y1mUKuUHKW7Xn jCp0OWxQwy/y+bLkQ1vBb5hb58Ps+VlAN9ecmlH+7uIqOBLVNAFAIjBsQTVCZn6FPQ2nxVeZf u10lscjs/lbTxzHBS0YYMeTnDQgdkXfUMFS3iLFOxot295LVvlX9BC62N6K6slgsDmn5g4/K3 77pr3k7frLj21sD4pUV4nuyknbg7/ZTqXidzw+KTPPImzRHrRKPkGsZMNrTQhMuH0EH3UFGkR Zxcsqpogu8e+LuC1zPYEuL2fMG6+T9UzObOTgsnC+907NY6NSbd2xgRTHw6k+u2Cf/G5w1dFD dFXbaZjbZKEiQqqZu4YSVNhPqZBm8tVrvIjtVEWv4wP0CIfa2w7IFaboo2661t+oUpi4Avd+M fdQFFlb0ougEDw0VkdBUjTxk9nv6VrXAQKbk7HLzu2pnrJE8jWsbRqXWyfTWm0x7htKfnjdNB /aY2QFjZPpgcyPMkMfAMXvX8jBr2YClz6ojv3Fd+zrBlbvX/4K8RRx2o+HxT32nu2ID6XSvXn B60y7CY66EnnoY118sZW1jVOaI8vD+PBVYrTPwEKIH6CbarMGdtkbm3W0jVgpGKtRlXd9lyrf EIJ1V34bz2VhDYhKYUZf0rkmC6j0j6tK43lDIGFCAHFSTd3cPEo1iuW8FAKAstgNxJ2Jr4bl2 Pr7pTOh+JOQmpERZtRhpFLoeVlRQyUKLwDYQoDm8lkqCFrME6wczlvrVHvK6LEawCIrBDW+1d ytH51JEE8KpPIPSm6PbZu8hTQ6GWDlCfNz/+tiMmYKPMU7ugAOmPv6X06HwUOvTMhT3hRkdrm ZAp18YBq1j72covRcSvTmnnKyteVOeisDw/UCw+0G9dUiqrCAU+wLQYMe9jGDFBfZ8H88vWa/ tvO1r74GOn804vzrboHX/uNzDL7GtWuSuMfkiDOJQDxnY95w98f+GzhW9Re4cGD8xvNJFu0s6 h/R0Fm6giGsvvY8nkImUd3XOWuOH9a85T+x7mlqje3q9EAUIx3yYdp5xG9Nb0hXKonva8OBS5 0eQfibHOoLyPfb90Xh9mjutVHwp0DmElrAb Archived-At: Subject: [xml2rfc] day handling in references, was: xml2rfc Digest, Vol 101, Issue 9 X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 08:20:07 -0000 On 15.07.2019 06:37, John C Klensin wrote: > > On 12.07.2019 19:44, Julian Reschke wrote: >>> ... >>> So then who is in charge to decide whether the day of month >>> is inserted? >>> >>> 1) The author? (in that case, the citation libs would need to >>> drop the date for internet drafts) >>> >>> 2) The processor? (in which case it'll need an extra signal >>> for April 1st RFCs) >>> >>> This may have been not so important in the past. But in the >>> v3 world (AFAIU), there will be no manual post-processing >>> step anymore, so whatever the formatter emits will be what >>> people see... ... >> >> Proposed extension: >> > 9.date> >> >> Example: >> > > I think this (including the proposed extension) is being made > unnecessarily complicated and that > > x:include-day" ("true", "false") > > as proposed does not do the right thing. It does allow me to produce the desired output while staying compatible with what formatting have been doing for many years. > The system clearly knows whether it is generating I-Ds or RFCs. > It clearly has to in order to generate different boilerplate. Yes. > So, > > for RFCs: > (i) The front page is always without a day-of-month unless some > attribute or other flag is present (for the April 1 case). That's exactly what the proposed flag does for the boilerplate. > (ii) References use whatever content and format the Style Guide > says what they use. If it is "Month Year" then maybe an > attribute should permit an exception to that, but I doubt it > will be used very often if ever. It would be needed when citing April-1st RFCs (*), and that's exactly the proposal does. (*) While looking at examples, I found that sometimes April 1st RFCs are cited without the day information. Would be good to understand whether there is a rule for that or not. > (iii) The Style Guide should be reviewed to make sure that a > reference to a document published in a language other than > English and whose preferred date is not in English (and perhaps > not even in Gregorian calendar) comes out the way the RFC Editor > wants it. I am largely agnostic as to what that is, but it > should probably be sorted out and specified now because it may > affect the markup. I would strongly encourage people to think > about this using an example that is not drawn from Latin script > or even a European script. For bibliographical references, the date information essentially can be prose already; AFAIU, there are no restrictions about what you can put into the attributes (I even found a case where somebody used month=3D"1 April" to force the day into the output). > For I-Ds (and any other non-RFCs of interest): > > (i) The front page is "month day, year". I note that the > submission tool will reject an I-D submission if the day number > is not present. If the xml2rfc developers want to provide I don't think that is the case, at least if you also leave out year and month. > extra generality by including an attribute to suppress the day, > go for it, but I believe the only thing that could make that > necessary is automatic date (including day number) generation > when is used without all of "year", "month", and "day" > attributes. > > (ii) References simply use whatever authors supply. If a day Well, that's a breaking change. > number is specified, it appears. If it isn't, it doesn't. Note > that this principle is important for another reason and that is > at least one reason why we don't make up date values when the > element is specified without attributes: some journals > publish only once a year and traditional books generally do not > specify even month information. So what the author specifies, > whether it be a year, a year and month, or a year, month, and > day goes into the output. And this is already the case for month and year, so I'm not sure what this has to do with the question of including the day or not. > (iii) Finally, I think that using different date formats in > different places (I'm talking about the format here, not whether > or not a day number appears) is probably an invitation to > trouble long-term. Perhaps, with the likely exception of the Not only long-term. > RFC header (and maybe footer), it is time to recognize that, > along with other changes for the new format, RFCs are becoming > "international" enough that it would be appropriate to go with > ISO 8601 dates and be done with it, both in whatever in > generated by markup and in Style Guide recommendations about any > dates that might appear in running text. Or not. Yes. See for what the current spec ways about the HTML format (although it omits the case where no day is given). Best regards, Julian From nobody Mon Jul 15 05:26:09 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD9A120112 for ; Mon, 15 Jul 2019 05:26:08 -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, 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 99MOkZYjCIDt for ; Mon, 15 Jul 2019 05:26:05 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [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 A711A12010D for ; Mon, 15 Jul 2019 05:26:05 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:56122 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 1hn03P-0005Jp-UV; Mon, 15 Jul 2019 05:26:04 -0700 To: John C Klensin , xml2rfc@ietf.org References: From: Henrik Levkowetz Message-ID: <09da600a-6754-f5d4-b116-95ace5ccee13@levkowetz.com> Date: Mon, 15 Jul 2019 14:25:56 +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="8kpsMBL98bjFPUQcLBv0jXbDoNMqAmqMM" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, john-ietf@jck.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: [xml2rfc] xml2rfc Digest, Vol 101, Issue 9 X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 12:26:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8kpsMBL98bjFPUQcLBv0jXbDoNMqAmqMM Content-Type: multipart/mixed; boundary="2TuROP0tBwqpVLllTVP3Ci4PccV1f5TtR"; protected-headers="v1" From: Henrik Levkowetz To: John C Klensin , xml2rfc@ietf.org Message-ID: <09da600a-6754-f5d4-b116-95ace5ccee13@levkowetz.com> Subject: Re: [xml2rfc] xml2rfc Digest, Vol 101, Issue 9 References: In-Reply-To: --2TuROP0tBwqpVLllTVP3Ci4PccV1f5TtR Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi John, Some comments on what the current v3 implementation does for each of the points below: On 2019-07-15 06:37, John C Klensin wrote: >=20 > On 12.07.2019 19:44, Julian Reschke wrote: >>> ... >>> So then who is in charge to decide whether the day of month >>> is inserted? >>>=20 >>> 1) The author? (in that case, the citation libs would need to >>> drop the date for internet drafts) >>>=20 >>> 2) The processor? (in which case it'll need an extra signal >>> for April 1st RFCs) >>>=20 >>> This may have been not so important in the past. But in the >>> v3 world (AFAIU), there will be no manual post-processing >>> step anymore, so whatever the formatter emits will be what >>> people see... ... >>=20 >> Proposed extension: >> > 9.date> >>=20 >> Example: >> >=20 > I think this (including the proposed extension) is being made > unnecessarily complicated and that=20 >=20 > x:include-day" ("true", "false")=20 >=20 > as proposed does not do the right thing. >=20 > The system clearly knows whether it is generating I-Ds or RFCs. > It clearly has to in order to generate different boilerplate. > So,=20 >=20 > for RFCs: > (i) The front page is always without a day-of-month unless some > attribute or other flag is present (for the April 1 case). With current v3, this is controlled by the RPC by leaving out or filling in the day in the document entry. The renderers render the date with/without day accordingly. (This diverges from RFC 7998, which in Section 5.2.3 (https://tools.ietf.org/html/rfc7998#section-5.2.3)=20 removes the RFC Editor's choice and sets out to enforce that all date components always be specified. Note that when the XML format becomes the published archival format, it becomes more important than earlier to retain the RFC Editor's freedom to specify a publication date with or without date, or possibly even month, in the XML date element. See also:=20 https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-not= es-09#section-4.4.1 ) > (ii) References use whatever content and format the Style Guide > says what they use. If it is "Month Year" then maybe an > attribute should permit an exception to that, but I doubt it > will be used very often if ever. Current v3 simply uses the elements provided in the reference entry (which follows the front page dates for RFCs). > (iii) The Style Guide should be reviewed to make sure that a > reference to a document published in a language other than > English and whose preferred date is not in English (and perhaps > not even in Gregorian calendar) comes out the way the RFC Editor > wants it. I am largely agnostic as to what that is, but it > should probably be sorted out and specified now because it may > affect the markup. I would strongly encourage people to think > about this using an example that is not drawn from Latin script > or even a European script. Current v3 has no support for alternative non-Gregorian dates or non-latin date renderings. (Adding this seems like a good idea, to me.) > For I-Ds (and any other non-RFCs of interest): >=20 > (i) The front page is "month day, year". I note that the > submission tool will reject an I-D submission if the day number > is not present. If the xml2rfc developers want to provide > extra generality by including an attribute to suppress the day, > go for it, but I believe the only thing that could make that > necessary is automatic date (including day number) generation > when is used without all of "year", "month", and "day" > attributes. The current code to handle various combinations of missing components is complex, but if it was possible to get a draft through submission with year and month, but without a day component, then the current v3 will honour that lack of day, and render only year and month. What you say about a possible attribute to suppress the day seems correct to me. > (ii) References simply use whatever authors supply. If a day > number is specified, it appears. If it isn't, it doesn't. Note > that this principle is important for another reason and that is > at least one reason why we don't make up date values when the > element is specified without attributes: some journals > publish only once a year and traditional books generally do not > specify even month information. So what the author specifies, > whether it be a year, a year and month, or a year, month, and > day goes into the output. This matches what the current v3 does, except that the current specification is unworkable for some dates that are approximate. For more on this see: https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-not= es-09#section-4.1.3.2 >=20 > (iii) Finally, I think that using different date formats in > different places (I'm talking about the format here, not whether > or not a day number appears) is probably an invitation to > trouble long-term. Perhaps, with the likely exception of the > RFC header (and maybe footer), it is time to recognize that, > along with other changes for the new format, RFCs are becoming > "international" enough that it would be appropriate to go with > ISO 8601 dates and be done with it, both in whatever in > generated by markup and in Style Guide recommendations about any > dates that might appear in running text. Or not. The current v3 formatter does not do this. (Personally, I have mixed feelings on this; as long as the local numeric date format in use across the countries of the world vary as much as it does (https://en.wikipedia.org/wiki/Date_format_by_country), it seems to me that Georgian date rendering probably should use month names in order to be easily assimilated by human readers.) Best regards, Henrik --2TuROP0tBwqpVLllTVP3Ci4PccV1f5TtR-- --8kpsMBL98bjFPUQcLBv0jXbDoNMqAmqMM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl0scNQACgkQTptXS4+7 Fxrtpw//a6MmQrUspNciTmkQMvONzTRmgKIT2EvoMATOkFwBkHTCjFiEno8Vnoh8 2Trt83IGoFTZZiTTCiTZAzB3x0vaCPkOu4vBdi2VXjQ7CKGGrtrIccHPBBU75Obc Ktz7bhrF73vNTrWL1sP5rH35f7EVwV3q6Z1gqkUQKqKfOkW092EKde3aBuFpQmXO 9OZcuA97K9kw8YKkd7uH6YOLNrsAPPKlvKr8kCJI4+6MleQLKPW0m8/T3p8CXrF0 qZjRLgWJ3/QbLzBioUnmcN+STEr+G2nuIhY7jjNVaWleNMUGpicUvQ2lYogEjp/e m12ulxMUAFnS4sWAmiaqrrCREjV0paEMpu7nSpUQtOYMrzFlEbdbIv5pSpDnXKZN +pDTZP0SLhi9LZNKwD0vN5zVbrEsFyOQXDq1XVRKOCBdvcTrfHLdMVs8kKObHEP7 7o+xfO0ARsYT6C7Cksf4jjalFY1koZhXjwYnThoQGeDrnDKg3TObadp/yTcE+Xmh sl1oyUqp3uVpYN96Aq6Sf4Ak+VmYuf0XRdBA0yImZ2idfpI2GLi3YkadPEohFr2B AZH6sWAoOLNNJjaefMIWqP+C9IHUhLvmWBMWUyRvh+1FtXEmhWx1mxpypW7dqWV/ 5/gpDaKj4gsYCz1/WIHUFwswoMrmIqco3ELpF+FNKXU2KW/GH3g= =WH8O -----END PGP SIGNATURE----- --8kpsMBL98bjFPUQcLBv0jXbDoNMqAmqMM-- From nobody Mon Jul 15 05:44:58 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50A281200F4 for ; Mon, 15 Jul 2019 05:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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] 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 GlyvhUU60XRW for ; Mon, 15 Jul 2019 05:44:54 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 E834012008B for ; Mon, 15 Jul 2019 05:44:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1563194688; bh=PPDguNJb6ZrQMpuydHXLI8Szz1Bk2HBpKoJ2xAxPe1g=; h=X-UI-Sender-Class:To:From:Subject:Date; b=kw0QTG11B2OU4GzYbgSH9/5mfzc0j1uDZa+4q1T8O7U7yFY3ee7UVsrmhybxHAyD/ 8gSxFqYtmRyC0Tmht0tR68e6hkueNC+zZfa5a0wM1QzMWzOOOCUO/fhAjKlI0dfZQY CpdMnQpy2bMfzhnVDOKb5i4uY/azUHDfjO32fG+0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MoO24-1iFhLE3RpA-00okFK for ; Mon, 15 Jul 2019 14:44:48 +0200 To: "xml2rfc@ietf.org" From: Julian Reschke Message-ID: <7128a1b7-4237-5649-772a-fd0d0bd1cc41@gmx.de> Date: Mon, 15 Jul 2019 14:44:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:G9yJa7PieIdsRfFXvE5WqIaB9MbdfN3PfaAZ0NUoEUypwnGc4yC zOuD1OZRubYjkVGdJOrCGTS4gT4x8eUuP7hCExxk8WneBxQG6gZnCsiMGJrXzI7gJqh0LDB N+FZAzcGZex4jzujWN6Z0sNAAK5H/uYNF3Ve9or2WKFPZuIRUbyhfZZGsuXo4X3NmWBmzqL 33wiZKW0n6QX0OajZeigA== X-UI-Out-Filterresults: notjunk:1;V03:K0:ClCOlmvJh74=:4ZYc6wqdaeh+UTlwCE7U/T MujHhSb/CHfHdcddKKYOnlke1UL+3Ucq36RF1uS926EjUKyWmNjgh1bH7DfDTAJcB2HbcjhMm 96GeGTK/kztf00732fd0GkX9hpIiDsCtSkRiYTaNcRQpmL7StJZ0+ELlf0WY86GJwnErhPMFx EXckO3fzhoLxVG7Q/kzI53f8DA3A/6EkTWKi7c0bZrCelnulxyq7qNkNLSZuqJV7r42kfMRCT A5VViWl8bpV28OWTLP9bTug+W+9daR8N3Bjw4KA6VexQzV7n959Q5OTbnu0EF2paIDpi+LOOO mWWtkeZ6mdiKNdzHYpUg69hYZzDpGxI8MlZxsZ/Wp9mxlO9PF0lglxaNav3egkIqgAiBvc8wA 68yefkSlzoNC6UiYxiyNL0APbqs7tOeoWztUI2dIPXemGS6aQOTPvbz6oWEMqCb4xut89qmZk FoouZBzjWC0D/lYl/DXo7Zv/quVi0yCNY1JcAgW5wO/F7femDWNOTP/Xu6yKPRSgUCByK74dV iE6iF0LlnY4YUWFbEEdfI7TRIqYA9kcBpZC00oPIKl/t/U9j9wqG1PtVeWhysklYf7OSheIiS qtsFTLcZPt9CyGNyXJABUu0ewWBEjCzeumUuxVEJSXzvdVS83WrI3GlrzTOXwiMRi4lHZbfXq PsSjp8Qm9sxinFEdSIt3a/YCJvWJqEZQcFFX+pyDa0MJjY3mBQiya9u6eWrMwKOXNErSi1+FN nnuXVkjT7J8T3Yj7grp/ukze/S3KCLTQYQsQCJ4nupJ+sswlS/mv2XJYms7mSvkspx2CxhyI6 AArTIRqctIMeUVvWDiUuFfTkFhFN96AxJfq1W1x2oBcMNRWkuP/aAQZdWbXIiS5JM8dsORqNH iDmk/Apr53l5/s48oVhBsl3AvS+z5mPJqXZ6Q0gU3nyzHlQSVUlagjJFp3cOi52fJnbYnv8k4 TfoOw7bVH9jiXIM+I3APdyWQbFlbbIcnhNaQZFUNNqisHdN/kQWuJ6MVuBbR+cIZvTxX6WSgB qmlxnZxJqf4HZjNQHwsbXd5Y4x3/NpyU7bm1dJku6YlV7YI9rWG8HDUpy8Ff6n2f4nUpUanz2 nDsHsYGdjDzYa/kNHM7jrY4UUeclLQ6bLZJ Archived-At: Subject: [xml2rfc] showOnFrontPage X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 12:44:56 -0000 : > 3.1.12.2. Attribute "showOnFrontPage" > > Guidance from the IAB regarding IAB stream documents > (https://www.rfc-editor.org/materials/iab-format.txt) indicate that > "'Each author's name SHOULD be listed without an organization.". See > also xml2rfc ticket #311 > (https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/311). > > In [RFC7991] there is no way to turn on or off the display of > on the front page, which would be needed for cases > when it is not wanted IAB documents to show such on the front page. > (Cases where display of is wanted is trivially > supported by the current code). > > In order to make it possible to expressly control this for a > vocabulary version 3 XML document, version 2.21.0 of xml2rfc > introduces an attribute "showOnFrontPage", with default value "true". > > This issue is tracked as github issue #36 (https://github.com/rfc- > format/draft-iab-xml2rfc-v3-bis/issues/36) It's . Best regards, Julian From nobody Mon Jul 15 06:04:49 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0DF712008B for ; Mon, 15 Jul 2019 06:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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] 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 jVIZfPOi9rO6 for ; Mon, 15 Jul 2019 06:04:45 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 376CF12004C for ; Mon, 15 Jul 2019 06:04:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1563195877; bh=PxL7AAS3j/c4ajW2Ioh3dPpPI9mbKYq8C/stY+2sXbE=; h=X-UI-Sender-Class:To:From:Subject:Date; b=GJ6/dBQPL8iIk3fKidZJgT3ASd22cXuTWCtxEYN4NPGKT6VMnTpmMY4Hy8M5m3i6s uX1DP9DFO92a0GXzkGgHNvVQkIqhGXUI+bsvlh5crYFB8tpW8kskH+UsRJkHaCMhud zvFKQbeL1OXkfQc3/mu1EJwn5NtJpifoAZ72cs1s= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1Mk0JM-1iBImT2q3k-00kMWg for ; Mon, 15 Jul 2019 15:04:37 +0200 To: "xml2rfc@ietf.org" From: Julian Reschke Message-ID: <10385dd4-4eff-0db7-df4e-377d535c7b87@gmx.de> Date: Mon, 15 Jul 2019 15:04:36 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:iWWT4fVJ03JbmgkFu300fOL62UYdHVC6tPuetNE3PffMwDZtuSU ZZSC9p2v832eixK0OpGOE8wija5zM+90P1GZsXXE8CsAfDPEUVs/h1VuOcdq7SvLq4Y7ZvJ Y+Xkdg1OgvODlm19iBYBdZFLPyWmi86eJlcsFwwOPv6wYD9WAnSnmdL3sVTLlZQU/EZ3Dv2 N7weCaBZ8tjmRAYgpuN6A== X-UI-Out-Filterresults: notjunk:1;V03:K0:V+PQw5y6C5w=:It+nMm/PppYrSp4GyS9t6J Q3dKcM9nwk8yrsYoMzZ8biS9bx+Z8ZwJ8hb2BHX5QPnQs+xLE/Ay7amKPsISx27H8J/ucUQCJ 7K0IDaIe2UZ7WaPteOnTmfqBHb0PrAQM/p1BQqhExn7z7lUm7aTQ33lgsppGFmEc57JFWoc56 LM8RaG17Pj9BrveULDTW82MtkFFosJ+kQlhylhheZsmUINcRa7jGeovvh/Ou6NCXRga6olT3H TzWs61n/wLoMD8k12W5QtH4utkrjd2eyiOrk6zynMyq53tCqSCmBVhDDQ0czlANgzPV8q0isg /7C6PPNwkViI9Jy5ppM3y5J3oz1CXxcCoRiKKfgodokpqyDd/9SqRkzfzk5xQQwZn2dG7qAq5 STft6nD33zHasNaRJlszdzs0jn2BASYiZwWzMEJrwSfVWQJexiXc7S60+fp9zBcLyXaLthgKN kTbTQaf9RmG/242H/Esf310cFY5YKftWvw+farmPY3n3YWCtqSKmj+elwLvBgrqBi5//iXkNp hG4APdlmHRhY49pbAKDKxda79exFyYkAX9GsbxsdI/pqxgaC6t9kWQOV7gG8lD1iRwPAXG8Ci ZRodJ959pDdcvM5S1bsyhMjt+lO6An5twQXHi9DOloWoyHDF/83qMBJnVUV0gR+jSVZzXVEEE G8tNg+i3GMZssvJHjd6buNM+iVByoU/miUkALUp020jB9jI1fxKyH/XZG6ozGgLXMIx3+3cyP TVNR047AXiasR9oVHj1YEeg+DsfCdI4f5dPpl9+BRS8wO+BywPECWLT7X6k8GHLHbfCrxOz0s Q8HufokiF3RvOC7yqMPDgnQSUJ42Hlk55O2QfuEnRkfFIVznRlNaWrTa2kJECm0fgjy9nStfS TivRy+7uSRtm+D6lDWxdBAaAWJyZVKTBSaADQPDXLla9DvBR62uABRG/Qv9qBdxAkVNUW2KXd C1isgKi7w9MLX6D3MuLRXmgh8weZ//z6u1gxkq7SDJKeZobME7F9bJ3tRzIbYZszXbTGJoJP+ 9L6u1cnPuISuJs60Sjp82jupwgDKJUuDTVJOXpvKOHUd7uydV7W97FK9RWkNKxQyfcbw/TwvQ euhYYnRSbp3igsprtd9Kx6VPoznPDfpNrp2 Archived-At: Subject: [xml2rfc] Split expansion of elements X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 13:04:48 -0000 : > There are cases which cannot be handled with either the simplified or > full format specifications. One is exemplified in Table 1 of the > CSS sample document at https://rfc-format.github.io/draft-iab-rfc- > css-bis/sample2-v2.html#s-3. Rendering this with elements > requires that the non-ascii content be rendered in one place (a table > cell in one column) while the expansion is rendered in another cell > in a different column. Provision for this has been made by modifying > the expansion of when it is referenced by an . This table, > with elements referenced by instances: I agree that there's a problem here to be solved, but I'm a bit unhappy with the proposed solution. Quoting: > > 5 > > < > =CE=A3 > > > > > is converted to > +---+-------------+-----------------------------------------+ > | 5 | <=CE=A3> | GREEK CAPITAL LETTER SIGMA (U+03A3) = | > +---+-------------+-----------------------------------------+ I think this violates the principle of least surprise, because the fact that the element is target of an changes the rendering of the element. The following seems more natural to me: > > 5 > > < > =CE=A3 > > > > > I would also argue that re-using complicates something that is already complex enough. Maybe adding that functionality to itself would be better: > > 5 > > < > =CE=A3 > > > > > (it also puts the format attribute in the place it belongs to) In any case, please by all means consider the feedback about the rendering of now being dependant on whether it is a link target or not= . Best regards, Julian From nobody Fri Jul 26 09:41:03 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E361912038A for ; Fri, 26 Jul 2019 09:40:56 -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, 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 64bUgKTnoOD6 for ; Fri, 26 Jul 2019 09:40:55 -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 30DD012036B for ; Fri, 26 Jul 2019 09:40:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id D340F60945 for ; Fri, 26 Jul 2019 12:40:44 -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 rxKfq+4UxfiH for ; Fri, 26 Jul 2019 12:40:41 -0400 (EDT) Received: from lx140e.htt-consult.com (dhcp-914c.meeting.ietf.org [31.133.145.76]) (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 588B16080C for ; Fri, 26 Jul 2019 12:40:41 -0400 (EDT) To: "xml2rfc@ietf.org" From: Robert Moskowitz Message-ID: <84eafb24-f652-0c87-8063-2f7e381709e3@htt-consult.com> Date: Fri, 26 Jul 2019 12:40:39 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [xml2rfc] Problems running xml2rfc on Fedora 30 X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 16:41:02 -0000 This is the first time running xml2rfc on my new, Fedora 30 build. I had done the 'pip install xml2rfc' when I built this system a couple months ago.  Today I went to run it and got errors.  SO I grabbed the xml from a draft I worked with back on Fedora 28 and got the following for my efforts: $ xml2rfc draft-moskowitz-hierarchical-hip-06.xml Parsing file draft-moskowitz-hierarchical-hip-06.xml Traceback (most recent call last):   File "/usr/bin/xml2rfc", line 11, in     load_entry_point('xml2rfc==2.22.3', 'console_scripts', 'xml2rfc')()   File "/usr/lib/python2.7/site-packages/xml2rfc/run.py", line 386, in main     xmlrfc = parser.parse(remove_pis=options.remove_pis, normalize=True)   File "/usr/lib/python2.7/site-packages/xml2rfc/parser.py", line 599, in parse     include=True, line_no=getattr(element, 'sourceline', 0))   File "/usr/lib/python2.7/site-packages/xml2rfc/parser.py", line 302, in getReferenceRequest     result = self.cache(url)   File "/usr/lib/python2.7/site-packages/xml2rfc/parser.py", line 368, in cache     r = session.get(url)   File "/usr/lib/python2.7/site-packages/requests/sessions.py", line 546, in get     return self.request('GET', url, **kwargs)   File "/usr/lib/python2.7/site-packages/requests/sessions.py", line 533, in request     resp = self.send(prep, **send_kwargs)   File "/usr/lib/python2.7/site-packages/requests/sessions.py", line 646, in send     r = adapter.send(request, **kwargs)   File "/usr/lib/python2.7/site-packages/requests/adapters.py", line 498, in send     raise ConnectionError(err, request=request) requests.exceptions.ConnectionError: ('Connection aborted.', BadStatusLine('No status line received - the server has closed the connection',)) Please advise me on how to fix this.  I can provide the xml if needed. From nobody Fri Jul 26 10:26:22 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 307C012036F for ; Fri, 26 Jul 2019 10:26:21 -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, 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 (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 eiJFHpBMagcR for ; Fri, 26 Jul 2019 10:26:19 -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 BF405120359 for ; Fri, 26 Jul 2019 10:26:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1564161967; bh=aGJR9PZIvVWY0BlPQFirUCm5d3uVK+e23yMzjFt/06k=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=RToxYopg/u63NSIx5Gng8nGeX8IVD5Igt4/8reUm8+wwmg+ogix+TivUVCEbcgm++ Ylb3vW7OOb1M7ECdbHyRp+QlshIUfSq52AMo6KmAlrvWzk6F3CJT6B6ppjMV88s4Gj NKjB0YaJXI6J+y8WNmfBqrJWvEa+qkMayeMiiCSc= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([84.171.146.73]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N3bSj-1iYP5Y137j-010dC8; Fri, 26 Jul 2019 19:26:07 +0200 To: Robert Moskowitz , "xml2rfc@ietf.org" References: <84eafb24-f652-0c87-8063-2f7e381709e3@htt-consult.com> From: Julian Reschke Message-ID: <8e2f08b5-0b33-572d-dd8b-b90ddde888d9@gmx.de> Date: Fri, 26 Jul 2019 19:26:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <84eafb24-f652-0c87-8063-2f7e381709e3@htt-consult.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:QBLuwTKJUteW2nCKzc29DzpqM12OdgLozWWhftRIDckxkopJICT GSEQkM/k3c4brZFg0eWEnQIk5IUHiV79p8PIQ4Fb2HnS3gPiq2ulXx8Bwqtxygho/HuaKPP yIK0tWIL0SjSi8Z8Qo/FCx5g1Bp8ckMYbcYGPpaabD4i0XkE25JSerdJ+Eiyhzt/2/GBdl5 OQsMTOwcu6JaP1Ft4FKeQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:Im8TFZSn1JM=:yz7EUpB53CzuFNwk2WieD1 xohgQjP5ErzTumH5OAKH4fCrdZS5CSqYEksd0kDmZwk//N1BT2Em8L39u9hbLLU4IVmayr/3F izln9hVSLxyPXwnms9bn8ytOFG3Pf19Keu8WcQ/JLXO4LkH1ExxBys6Jwxu6D5eqIw3RDsTBG rcGDyUHF2r3krdPSExXJa9Nw/lfOCEC/KXcUFOhjdUwzbIv6K3yhn/os/fHd8ve28+vpEL4oe mXxPGCTcNZB8C1Wodq13RSxWB8OiLiV1hZB1LX6t+6kDHR5SPnnLVPbNER/bXRCq/tqQ+6AaM q4szxNyMLMR9k0PUDuEqJulrvl8TVW09f22Z2zpvr9qW/0AbZ++6rRyEVfu5fs7TZhZXdZKaa hPIY+S3yIEej/wbJsfTWKt6kdjH5/BM8ew37vLqLEipX6KtZDRtKDoN+OrXP+jdBaHO44eIIw 7V8GoruVUPMqBoU6Jf+yc3h6SEAHghlJEudWExJcBW81xpFULNomBk2fXyJGig4n/SfOix2GO dAqOqOr7bO1x1LCtmluD9l/S7rAZFGRfEHPcIiJr7GzESqk196Um0WDBLAqYASz+ZBWWrcDlr TUqIsS4RpikUaeYLsPjbxK20rYBafx/6cC6cZdc5qaXxbviPaRrAl+jl91t+LGblpYxo+Efqe TQj7wpH24MrNPLzzKF4VJ78HEiJiJX2aR6B89lvWcBxcVoZu5GANQ1dIaRlfCkYwTm7AHHLQg q7SkuwStYgS0EEGB3JmiBODS3em4xoUZkOc9j98rg0fimzSNWdMHyB7l+r6LbUM2XhfdAQmBW 9cKfDE/AUvcSXo3BCxpYY4ePG3sOBQOXJ6x2INLmFXNAM8z2T9KVJU2PwMTbJgUL90UxDf1kZ vB3lipXvW03pxiWLX7h2PNa9A7D4WEr7tYwGCUzL0NL91ypsh9o/zSPyDo4tlt+PRtRyXpvWa ckSgqsSO+OoUHgt9qn355zsfwsQN4ItPHogDHiTSMrlWF8Rks70Iel2S/P6eFcGH8z5fV2ozy ZWiN0K57tAhqF8uUAlZrohDkI+IYzR0BoZi4jf8N5Ydj0r2fDrfZeK5rW9FvA4xjPxpIC04LY RRfZyh6j/HuZuhyuJpGjM6Xn9UoSRPOdBQe Archived-At: Subject: Re: [xml2rfc] Problems running xml2rfc on Fedora 30 X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 17:26:21 -0000 On 26.07.2019 18:40, Robert Moskowitz wrote: > This is the first time running xml2rfc on my new, Fedora 30 build. > > I had done the 'pip install xml2rfc' when I built this system a couple > months ago.=C2=A0 Today I went to run it and got errors.=C2=A0 SO I grab= bed the > xml from a draft I worked with back on Fedora 28 and got the following > for my efforts: > > $ xml2rfc draft-moskowitz-hierarchical-hip-06.xml > Parsing file draft-moskowitz-hierarchical-hip-06.xml > Traceback (most recent call last): > =C2=A0 File "/usr/bin/xml2rfc", line 11, in > =C2=A0=C2=A0=C2=A0 load_entry_point('xml2rfc=3D=3D2.22.3', 'console_scr= ipts', 'xml2rfc')() > =C2=A0 File "/usr/lib/python2.7/site-packages/xml2rfc/run.py", line 386= , in > main > =C2=A0=C2=A0=C2=A0 xmlrfc =3D parser.parse(remove_pis=3Doptions.remove_= pis, normalize=3DTrue) > =C2=A0 File "/usr/lib/python2.7/site-packages/xml2rfc/parser.py", line = 599, > in parse > =C2=A0=C2=A0=C2=A0 include=3DTrue, line_no=3Dgetattr(element, 'sourceli= ne', 0)) > =C2=A0 File "/usr/lib/python2.7/site-packages/xml2rfc/parser.py", line = 302, > in getReferenceRequest > =C2=A0=C2=A0=C2=A0 result =3D self.cache(url) > =C2=A0 File "/usr/lib/python2.7/site-packages/xml2rfc/parser.py", line = 368, > in cache > =C2=A0=C2=A0=C2=A0 r =3D session.get(url) > =C2=A0 File "/usr/lib/python2.7/site-packages/requests/sessions.py", li= ne > 546, in get > =C2=A0=C2=A0=C2=A0 return self.request('GET', url, **kwargs) > =C2=A0 File "/usr/lib/python2.7/site-packages/requests/sessions.py", li= ne > 533, in request > =C2=A0=C2=A0=C2=A0 resp =3D self.send(prep, **send_kwargs) > =C2=A0 File "/usr/lib/python2.7/site-packages/requests/sessions.py", li= ne > 646, in send > =C2=A0=C2=A0=C2=A0 r =3D adapter.send(request, **kwargs) > =C2=A0 File "/usr/lib/python2.7/site-packages/requests/adapters.py", li= ne > 498, in send > =C2=A0=C2=A0=C2=A0 raise ConnectionError(err, request=3Drequest) > requests.exceptions.ConnectionError: ('Connection aborted.', > BadStatusLine('No status line received - the server has closed the > connection',)) > > > Please advise me on how to fix this.=C2=A0 I can provide the xml if need= ed. I suspect something is wrong with your reference includes (or actually with the server you're trying to reach). Please send XML :-) Best regards, Julian PS: and we should open a ticket to get more usable error messages... From nobody Fri Jul 26 10:31:39 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7594120071 for ; Fri, 26 Jul 2019 10:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PP_MIME_FAKE_ASCII_TEXT=0.999, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 ESloQVQv3NI3 for ; Fri, 26 Jul 2019 10:31:29 -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 EC3191202D9 for ; Fri, 26 Jul 2019 10:31:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 10C0260945; Fri, 26 Jul 2019 13:31:04 -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 2FjU9lUHMojr; Fri, 26 Jul 2019 13:30:46 -0400 (EDT) Received: from lx140e.htt-consult.com (dhcp-914c.meeting.ietf.org [31.133.145.76]) (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 585296080C; Fri, 26 Jul 2019 13:30:46 -0400 (EDT) To: Julian Reschke , "xml2rfc@ietf.org" References: <84eafb24-f652-0c87-8063-2f7e381709e3@htt-consult.com> <8e2f08b5-0b33-572d-dd8b-b90ddde888d9@gmx.de> From: Robert Moskowitz Message-ID: Date: Fri, 26 Jul 2019 13:30:45 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <8e2f08b5-0b33-572d-dd8b-b90ddde888d9@gmx.de> Content-Type: multipart/mixed; boundary="------------93842D034738C073F2F78A99" Content-Language: en-US Archived-At: Subject: Re: [xml2rfc] Problems running xml2rfc on Fedora 30 X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 17:31:38 -0000 This is a multi-part message in MIME format. --------------93842D034738C073F2F78A99 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Here is the xml.  I believe it is unchanged for what I used on my old Fedora 28 system (back at home) and submitted long ago... And where does one open a ticket? On 7/26/19 1:26 PM, Julian Reschke wrote: > On 26.07.2019 18:40, Robert Moskowitz wrote: >> This is the first time running xml2rfc on my new, Fedora 30 build. >> >> I had done the 'pip install xml2rfc' when I built this system a couple >> months ago.  Today I went to run it and got errors.  SO I grabbed the >> xml from a draft I worked with back on Fedora 28 and got the following >> for my efforts: >> >> $ xml2rfc draft-moskowitz-hierarchical-hip-06.xml >> Parsing file draft-moskowitz-hierarchical-hip-06.xml >> Traceback (most recent call last): >>    File "/usr/bin/xml2rfc", line 11, in >>      load_entry_point('xml2rfc==2.22.3', 'console_scripts', 'xml2rfc')() >>    File "/usr/lib/python2.7/site-packages/xml2rfc/run.py", line 386, in >> main >>      xmlrfc = parser.parse(remove_pis=options.remove_pis, >> normalize=True) >>    File "/usr/lib/python2.7/site-packages/xml2rfc/parser.py", line 599, >> in parse >>      include=True, line_no=getattr(element, 'sourceline', 0)) >>    File "/usr/lib/python2.7/site-packages/xml2rfc/parser.py", line 302, >> in getReferenceRequest >>      result = self.cache(url) >>    File "/usr/lib/python2.7/site-packages/xml2rfc/parser.py", line 368, >> in cache >>      r = session.get(url) >>    File "/usr/lib/python2.7/site-packages/requests/sessions.py", line >> 546, in get >>      return self.request('GET', url, **kwargs) >>    File "/usr/lib/python2.7/site-packages/requests/sessions.py", line >> 533, in request >>      resp = self.send(prep, **send_kwargs) >>    File "/usr/lib/python2.7/site-packages/requests/sessions.py", line >> 646, in send >>      r = adapter.send(request, **kwargs) >>    File "/usr/lib/python2.7/site-packages/requests/adapters.py", line >> 498, in send >>      raise ConnectionError(err, request=request) >> requests.exceptions.ConnectionError: ('Connection aborted.', >> BadStatusLine('No status line received - the server has closed the >> connection',)) >> >> >> Please advise me on how to fix this.  I can provide the xml if needed. > > I suspect something is wrong with your reference includes (or actually > with the server you're trying to reach). > > Please send XML :-) > > Best regards, Julian > > PS: and we should open a ticket to get more usable error messages... > > > --------------93842D034738C073F2F78A99 Content-Type: text/xml; name="draft-moskowitz-hierarchical-hip-06.xml" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="draft-moskowitz-hierarchical-hip-06.xml"  Hierarchical HITs for HIPv2 Huawei
Oak Park MI 48237 USA rgm@labs.htt-consult.com
Huawei
Huawei Bld, No.156 Beiqing Rd. Beijing Hai-Dian District 100095 China xuxiaohu@huawei.com
Huawei
Huawei Bld, No.156 Beiqing Rd. Beijing Hai-Dian District 100095 China liubingyang@huawei.com
Internet HIP RFC Request for Comments I-D Internet-Draft HIP This document describes using a hierarchical HIT to facilitate large deployments in mobile networks.
This document expands on HIPv2 to describe the structure of a hierarchical HIT, the Registry services to support this hierarchy, and given a hierarchical HIT, how a device is found in the network. Separate documents will further expand on the registry service and how a device can advertise its availability and services provided.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
The 14 bit field identifying the HIT Domain Authority under a RAA. The 32 bit field providing the HIT Hierarchy ID. The 18 bit field identifying the Hierarchical HIT Assigning Authority.
The evolution of mobile networking to greater bandwidth and faster mobility will favor IP mobility technologies that optimize shortest routing paths for both mobile-to-stationary and mobile-to-mobile applications. For this, devices will need to use the IP address which provide the shortest path for where they are physically in the mobile network. The mobile device will need services that will discover the IP addresses for their peer mobile devices and keep them connected to those peers even when both devices move in the network at the same time (the double-jump problem). In order to support these services, there needs to be billable services to support the infrastructure. In some area close tracking of mobile devices will be mandatory. In other device obfuscation to protect privacy and/or safety will be the only life-enabling approach. These conflicting requirements can be met with the Host Identity Protocol (HIP), provided its Rendezvous Server service is scaleable and manageable. Providers of RVS will need both a viable and scaleable business model.
A device Identity has some degree of permanency. A device creates its identity and registers it to some 3rd-party that will assert a level of trust for that identity. A device may have multiple identities to use in different contexts, and it may deprecate an identity for any number of reasons. The asserting 3rd-party may withdraw its assertion of an identity for any number of reasons. An identity system needs to facilitate all of this.
For HIP to be successfully used in large mobile networks, it must support an Identity per device, or at least 10 billion Identities. Perhaps a Distributed Hash Table can scale this large. There is still the operational challenges in establishing such a world-wide DHT implementation and how RVS works with such a large population. There is also the challenge of how to turn this into a viable business for the Mobile Network Providers. Even though the probability of collisions with 7B HITs (one HIT per person) in a 96 bit flat address space is 3.9E-10, it is still real. How are collisions managed? It is also possible that weak key uniqueness, as has been shown in deployed TLS certificates, results in a much greater probability of collisions. Thus resolution of collisions needs to be a feature in a globally mobile network.
How can a host protect against a fraudulent HIT? That is, a second pre-image attack on the HI hash that produces the HIT. A strong defense would require every HIT/HI registered and openly verifiable. This would best be done as part of the R1 and I2 validation.
An RVS provider may only be willing to provide discovery (RVS) services to HIP devices it knows and trusts. A flat HIT space does not provide any intrinsic functionality to support this. A hierarchical HIT space can be mapped to the RVS provider. DNS can effectively be used to provide the HIT to IP mapping without DHT. A hierarchical HIT space also creates a type of a business labeling for the RVS provider. "These are my customers."
The Hierarchical HIT is a small but important enhancement over the flat HIT space. It represents the HI in only a 64 bit hash and uses the other 32 bits to create a hierarchical administration organization for HIT domains. Hierarchical HITs are ORCHIDs. The change in construction rules are in . A Hierarchical HIT is built from the following fields: 28 bit IANA prefix 4 bit HIT Suite ID 32 bit Hierarchy ID (HID) 64 bit ORCHID hash
The Hierarchy ID (HID) provides the structure to organize HITs into administrative domains. HIDs are further divided into 2 fields: 14 bit Registered Assigning Authority (RAA) 18 bit Hierarchical HIT Domain Authority (HDA)
An RAA is a business that manages a registry of HDAs. The RAA is a 14 bit field (16,384 RAAs) assigned sequentially by a numbers management organization, perhaps ICANN's IANA service. An RAA must provide a set of services to allocate HDAs to organizations. It must have a public policy on what is necessary to obtain an HDA. The RAA need not maintain any HIP related services. It must maintain a DNS zone for discovering HID RVS servers. This DNS zone may be a reverse PTR for its RAA. Assume that the RAA is 100. The PTR record is constructed at a 2 bit grouping:
0.1.2.1.0.0.0.hhit.arpa IN PTR raa.bar.com.
An HDA may be an ISP or any third party that takes on the business to provide RVS and other needed services for HIP enabled devices. The HDA is an 18 bit field (262,144 HDAs per RAA) assigned sequentially by an RAA. An HDA should maintain a set of RVS servers that its client HIP-enabled customers use. How this is done and scales to the potentially millions of customers is outside the scope of this document. This service should be discoverable through the DNS zone maintained by the HDA's RAA. An RAA may assign a block of values to an individual organization. This is completely up to the individual RAA's published policy for delegation.
HID related services should be discoverable via DNS. For example the RVS for a HID could be found via the following. Assume that the RAA is 100 and the HDA is 50. The PTR record is constructed at a 2 bit grouping:
2.0.3.0.0.0.0.0.0.1.3.1.0.0.0.0.hhit.arpa IN PTR rvs.foo.com.
The RAA is running its zone, 1.3.1.0.0.0.0.hhit.arpa under the hhit.arpa zone.
ORCHIDv2 has a number of inputs including a context, some header bits, the hash algorithm, and the public key. The output is a 96 bit value. Hierarchical HIT makes the following changes. The HID is added as part of the header bits and the output is a 64 bit value, derived the same way as the 96 bit hash.
Input := HID | HOST_ID OGA ID := 4-bit Orchid Generation Algorithm identifier The HIT Suite ID = 0x40 Hash Input := Context ID | Input Same Context ID as HIPv2 Prefix := HIPv2 Prefix HID := Hierarchy ID Hash := Hash_function( Hash Input ) Encode_64 := Same as Encode_96, but only 64 bits ORCHID := Prefix | OGA ID | HID | Encode_64( Hash )
Hierarchical HIT uses the same context as all other HIPv2 HIT Suites as they are clearly separated by the distinct HIT Suite ID.
The 64 bit hash size does have an increased risk of collisions over the 96 bit hash size used for the other HIT Suites. There is a 0.01% probability of a collision in a population of 66 million. The probability goes up to 1% for a population of 663 million. See for the collision probability formula. However, this risk of collision is within a single HDA. Further, all HDAs are expected to provide a registration process for reverse lookup validation. This registration process would reject a collision, forcing the client to generate a new HI and thus hierarchical HIT and reapplying to the registration process.
The HIP parameters carry information that is necessary for establishing and maintaining a HIP association. For example, the device's public keys as well as the signaling for negotiating ciphers and payload handling are encapsulated in HIP parameters. Additional information, meaningful for end hosts or middleboxes, may also be included in HIP parameters. The specification of the HIP parameters and their mapping to HIP packets and packet types is flexible to allow HIP extensions to define new parameters and new protocol behavior.
The HIT_SUITE_LIST parameter contains a list of the supported HIT suite IDs of the Responder. Based on the HIT_SUITE_LIST, the Initiator can determine which source HIT Suite IDs are supported by the Responder. The HIT_SUITE_LIST parameter is defined in Section 5.2.10 of . The following HIT Suite IDs are defined for Hierarchical HITs, and the relationship between the four-bit ID value used in the OGA ID field and the eight-bit encoding within the HIT_SUITE_LIST ID field is clarified:
HIT Suite Four-bit ID Eight-bit encoding ECDSA/hier/SHA-256 4 0x40
Note that the Hierarchical HIP HIT Suite ID allows the devices to use the hierarchical RVS discovery and authentication services to validate the peer and discover available services. The Responder SHOULD respond with a HIP hierarchical HIT suite ID when the HIT of the Initiator is a HIP hierarchical HIT.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Client Information / / / / +-------------------------------+ / | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type [TBD-IANA] Length length in octets, excluding Type, Length, and Padding Client The information required by the HDA in the format Information required by the HDA.
This parameter contains client information to include in the HIT registration. The specific content and format is set by the HDA.
Hierarchical HIT registration SHOULD be performed using the HIP Registration Extension . The client either uses an X.509 certificate , or use a PSK, as defined in Appendix A of HIP-DEX , to validate the registration. The Registration should include additional client information. This information may be contained within the X.509 certificate and/or is carried in the CLIENT_INFO parameter, see . The Registrar can include its requirements in the R1 packet, and the client provide its information in the I2 packet. This parameter may be encrypted within the ENCRYPTED parameter. If the CLIENT_INFO contains Personal Identifying Information (PII), then it MUST be placed into the ENCRYPTED parameter. The content and internal format of the CLIENT_INFO parameter is set by the HDA's policy and is outside the scope of this document. Examples of client information can by phone number, IMEI, and ICCID.
This requires the HIP client to possess a client certificate trusted by the HDA/Registrar. Registration will either succeed or fail.
This requires the HIP client and the HDA/Registrar to share a PSK. The PSK may already exist prior to starting the registration and just be used within the registration. A PSK out-of-band exchange may be triggered by performing the registration without any authentication. If no client authentication is included in the I2 packet, the registration fails with "No Authentication provided". If the I2 packet included the proper HDA required client information, the HDA can use it to set up a side channel for an out-of-band delivery of a PSK. And example of this would be to send an SMS message with the PSK. Once the client possesses the PSK, it can rerun the registration at which point the HI and HIT duplicate checks are performed.
The Registration Type used in the REG_REQUEST is:
Number Registration Type ------ ----------------- 2 HIT Registration
The Registration may fail. In fact, with PSK, this may be the response to expect an SMS message with the PSK to use in a second registration request. Failure Types used in the REG_FAIL are:
Failure Type Reason ------------ ----------------------- [TBD-IANA] Hierarchical HIT Already Registered [TBD-IANA] HI Already Registered [TBD-IANA] Previously Registered HI with different device information [TBD-IANA] No Authentication provided [TBD-IANA] Invalid Authentication [TBD-IANA] Invalid Authentication, new PSK sent via SMS
If the failure type is "Hierarchical HIT Already Registered", the client's HI is hashing to an existing HIT and must generate a new HI and hierarchical HIT and reregister. If the failure is "HI Already Registered", the client should assume it is registered. If the failure is "Previously Registered HI with different device information", either the client managed to generate a duplicate HI, probably indicating a weak key generation algorithm, or the client was previously registered on a different device. Resolving this conflict will be left to the HDA's policy.
A simple HDA policy would be to require the device to generate a new HI and thus HHIT and try registration again. The HDA policy may also provide a URL for "Previous Registration Resolution". This contact is primarily to assist a device that was registered, but had some local failure resulting in a new registration attempt.
All HIP clients with hierarchical HITs maintain an RVS connection with their HDA's RVS server(s). How the HDA scales this service up to a potential population in the millions is out of scope of this document. Lifetime management of these connections is also out of scope. One approach an HDA can use to address the scaling challenge is to add an internal level of hierarchy to assign a set number of devices per RVS server. Peering agreements between HDAs would allow for geographically close RVS to a device. This may reduce the latency for use of a device's current RVS. This is a subject of another document.
A service Initiator uses some service to discover the HIT of the service Responder. The Initiator uses the hierarchical information in the HIT to find the Responder's RVS. A trusted RVS discover method could use the DNS PTR to RVS as shown in . An I1 is sent to that RVS which forwards it to the Responder. The potential Responder uses the HIT in the I1 to query the Initiator's RVS about the Initiator. The nature of information, and method of communication are determined by the Initiator's HDA and the Responder's (and or HDA's) relationship with it. Based on the Responder's local policy, this information will be used to determine if the contact is to be accepted. If accepted, the Responder may proceed sending an R1 to the Initiator. It may alternatively initiate some non-HIP process. It should be noted that this R1 may contain a REG_INFO list for the Initiator to validate that the Responder does offer the desired service.
Both the Initiator and Responder MAY validate a peer host as a defense against a second pre-image attack on the HHIT. This may occur via a CERT in R1 or I2. It may be through a back end process associated with the R1 or I2 validation to look up the HHIT and retrieve the registered HI.
IANA will need to make the following changes to the "Host Identity Protocol (HIP) Parameters" registries: This document defines the new HIT Suite "Hierarchy with ECDSA/SHA256" (see ). This document defines the new CLIENT_INFO parameter (see ). The parameter value will be assigned by IANA. This document defines the new Registration Type for the REG_REQUEST parameter "HIT Registration" (see ). This document defines the new Failure Types for the REG_FAIL parameter (see ).
Introducing the RAA management organization may be the largest hurdle for hierarchical HITs. Thus it would be best if this were adopted by an organization already in the business of allocating numbers within either the Internet or the Mobile, cellular, infrastructure. One consideration would be to reserve the first N RAA values to map to the existing DNS TLDs. For example, these TLDs can be organized in an ascending order and numbered accordingly. Thus the 2 character TLDs will be a lower number than the 3 character TLDs. After that, it could be a first come, first numbered assignment process.
There are potential risks with the hierarchical HIT, the Registry service, and the discovery of potential peer hosts using its hierarchical HIT. A 64 bit hash space presents a real risk of second pre-image attacks. The HHIT Registry services effectively block attempts to "take over" a HHIT. It does not stop a rogue attempting to impersonate a known HHIT. This attack can be mitigated by the Responder using DNS to find the HI for the HHIT or the RVS for the HHIT that then provides the registered HI. The two risks with hierarchical HITs are the use of an invalid HID and forced HIT collisions. The use of the "hhit.arpa." DNS zone is a strong protection against invalid HIDs. Querying an HDA's RVS for a HIT under the HDA protects against talking to unregistered clients. The Registry service has direct protection against forced or accidental HIT hash collisions. By using the HIP Registration Extension, the Registry service is protected from direct attacks. This service does rely on either the integrity of a PKI service or an out-of-band PSK delivery process. Thus the risk to the Registry service is highly related to the trust in these authentication setup services. Further, the duplicate HI resolution process may require human interaction with related social engineering risks. Finally the peer host discovery process relies on trusting the finding the proper HDA for the host and its forwarding the I1 to the proper Responder. A rogue RVS, impersonating the RVS for the HIT, could redirect the I1 to a client that has forced a collision with the HIT and the Initiator would be none the wiser. The only defense against this is if the Initiator has some other source for the Responder HI and validate the HI in the R1.
Mobile-privacy-attack details how Eve can follow a communication between two mobile peers using the session Identifiers and deep knowledge about those Identifiers gained by hacking servers that log PII related to the Identifiers. Hierarchical HITs not only does not mitigate this attack, it can actually aggravate it by supplying the HDA where the HHIT is registered. A HIP Privacy Enhanced Base Exchange, to be defined in a separate draft, along with a Privacy Enhanced ESP tunnel, can be used to hide all the HIP and ESP Identifiers from Eve.
Sue Hares of Huawei contributed to the clarity in this document.
The accepted formula for calculating the probability of a collision is:
p = 1 - e^{-k^2/(2n)} P Collision Probability n Total possible population k Actual population
--------------93842D034738C073F2F78A99-- From nobody Fri Jul 26 11:36:05 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7986B1200D7 for ; Fri, 26 Jul 2019 11:36:03 -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, 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 pURKUUSkonak for ; Fri, 26 Jul 2019 11:36:01 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [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 C2FC7120071 for ; Fri, 26 Jul 2019 11:36:01 -0700 (PDT) Received: from [2001:67c:370:128:81c:6a39:ce57:ba8b] (port=50941) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1hr54S-00042p-4a; Fri, 26 Jul 2019 11:36:01 -0700 To: Robert Moskowitz , "xml2rfc@ietf.org" References: <84eafb24-f652-0c87-8063-2f7e381709e3@htt-consult.com> From: Henrik Levkowetz Message-ID: <5a6ed5aa-4da4-d336-0b42-78288a739c4a@levkowetz.com> Date: Fri, 26 Jul 2019 20:35:49 +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: <84eafb24-f652-0c87-8063-2f7e381709e3@htt-consult.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sfDihpIph9Nk76xUMqvp1ovFPtswMvN6t" X-SA-Exim-Connect-IP: 2001:67c:370:128:81c:6a39:ce57:ba8b X-SA-Exim-Rcpt-To: xml2rfc@ietf.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: [xml2rfc] Problems running xml2rfc on Fedora 30 X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 18:36:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sfDihpIph9Nk76xUMqvp1ovFPtswMvN6t Content-Type: multipart/mixed; boundary="AUfKJrAPSjoHMu8R8Ghaxv5VRcqfmb3AI"; protected-headers="v1" From: Henrik Levkowetz To: Robert Moskowitz , "xml2rfc@ietf.org" Message-ID: <5a6ed5aa-4da4-d336-0b42-78288a739c4a@levkowetz.com> Subject: Re: [xml2rfc] Problems running xml2rfc on Fedora 30 References: <84eafb24-f652-0c87-8063-2f7e381709e3@htt-consult.com> In-Reply-To: <84eafb24-f652-0c87-8063-2f7e381709e3@htt-consult.com> --AUfKJrAPSjoHMu8R8Ghaxv5VRcqfmb3AI Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Bob, This is a network connectivity issue, which we've pretty much never seen until this year. Something changed, but I'm not sure what. In any case, for the next release I've added re-tries within the tool to handle this. For now, the best advice I can give is to re-try. Best regards, Henrik On 2019-07-26 18:40, Robert Moskowitz wrote: > This is the first time running xml2rfc on my new, Fedora 30 build. >=20 > I had done the 'pip install xml2rfc' when I built this system a couple = > months ago. Today I went to run it and got errors. SO I grabbed the=20 > xml from a draft I worked with back on Fedora 28 and got the following = > for my efforts: >=20 > $ xml2rfc draft-moskowitz-hierarchical-hip-06.xml > Parsing file draft-moskowitz-hierarchical-hip-06.xml > Traceback (most recent call last): > File "/usr/bin/xml2rfc", line 11, in > load_entry_point('xml2rfc=3D=3D2.22.3', 'console_scripts', 'xml2rf= c')() > File "/usr/lib/python2.7/site-packages/xml2rfc/run.py", line 386, in= main > xmlrfc =3D parser.parse(remove_pis=3Doptions.remove_pis, normalize= =3DTrue) > File "/usr/lib/python2.7/site-packages/xml2rfc/parser.py", line 599,= =20 > in parse > include=3DTrue, line_no=3Dgetattr(element, 'sourceline', 0)) > File "/usr/lib/python2.7/site-packages/xml2rfc/parser.py", line 302,= =20 > in getReferenceRequest > result =3D self.cache(url) > File "/usr/lib/python2.7/site-packages/xml2rfc/parser.py", line 368,= =20 > in cache > r =3D session.get(url) > File "/usr/lib/python2.7/site-packages/requests/sessions.py", line=20 > 546, in get > return self.request('GET', url, **kwargs) > File "/usr/lib/python2.7/site-packages/requests/sessions.py", line=20 > 533, in request > resp =3D self.send(prep, **send_kwargs) > File "/usr/lib/python2.7/site-packages/requests/sessions.py", line=20 > 646, in send > r =3D adapter.send(request, **kwargs) > File "/usr/lib/python2.7/site-packages/requests/adapters.py", line=20 > 498, in send > raise ConnectionError(err, request=3Drequest) > requests.exceptions.ConnectionError: ('Connection aborted.',=20 > BadStatusLine('No status line received - the server has closed the=20 > connection',)) >=20 >=20 > Please advise me on how to fix this. I can provide the xml if needed. >=20 >=20 >=20 > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc >=20 --AUfKJrAPSjoHMu8R8Ghaxv5VRcqfmb3AI-- --sfDihpIph9Nk76xUMqvp1ovFPtswMvN6t Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl07SAYACgkQTptXS4+7 FxpgcxAAqT/7G7ioCq5QYa4/5ZgkMD3Qduspod6apsxRGAWmC8lU0bSMvEoX9wj6 eyaizMPCiVTCgks/kKMK/ITvQtWF8i+EyHiHLPtoFAjIuhYhQ4fJUlsGTSboLIyJ UbbUf+yqOrJ0JypvnmE3mAxgZ6apPISRLfAUggKHjvjdRktrzuhFTDRL8R/tIHa8 vagxsJmDNWXjSeq0vMzaoeXMvlIhEVl0qzuedXiywmW4KptfQx5TCZsmeDFA9Z/V GPSP06s0vAJC6bAOEPmxY/BgtPtJniWVN/TrMToQpUo7uCe5qFUQs85i4snnb330 VfKhqjk8aZ0lsc5W9J9rFJKJF8Q3y+jw34i/ieCFtP1KvjDOY4DnCgRmZMSoj5zS PW0xM7ggtsoy7PAEU5BUdyEYyaZAitgN1sg0I2sHBNotwxfFUBdqGICEswldArMM aFdXXv/H18eCrGj7n8hKqkVOtmwPpUT9k+qiLVyN5CH/8Gr85bOP0dccA+T7QEMO 20WlpXzVANIqf/tNfNRrm1D0PLSP2W2eGZMIdqKtRNwPj54NJbU1YX8VEKJOBC0i fCSZosBds5ldXqD0RkoWvg2jtCy4WtGaLhJHkMfMdwrDPSbvM3zhtF13H0xdEB0P Y3qIMxn+a2erlt6tpMhIJncZcTE3gC3eeujRdDfsYB418bW7a+Y= =qbhd -----END PGP SIGNATURE----- --sfDihpIph9Nk76xUMqvp1ovFPtswMvN6t-- From nobody Fri Jul 26 11:38:48 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C8D12011B for ; Fri, 26 Jul 2019 11:38:46 -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, 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 HQKN0jP4zwkZ for ; Fri, 26 Jul 2019 11:38:45 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [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 4809A1201A3 for ; Fri, 26 Jul 2019 11:38:27 -0700 (PDT) Received: from [2001:67c:370:128:81c:6a39:ce57:ba8b] (port=50982) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1hr56o-00007t-GP; Fri, 26 Jul 2019 11:38:27 -0700 To: Robert Moskowitz , Julian Reschke , "xml2rfc@ietf.org" References: <84eafb24-f652-0c87-8063-2f7e381709e3@htt-consult.com> <8e2f08b5-0b33-572d-dd8b-b90ddde888d9@gmx.de> From: Henrik Levkowetz Message-ID: <191e74ef-2216-c566-8830-ddd418e89002@levkowetz.com> Date: Fri, 26 Jul 2019 20:38: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: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="SSfWn3QlmecgPBdvjp1m2LCmDccOTxAht" X-SA-Exim-Connect-IP: 2001:67c:370:128:81c:6a39:ce57:ba8b X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, julian.reschke@gmx.de, 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: [xml2rfc] Problems running xml2rfc on Fedora 30 X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 18:38:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SSfWn3QlmecgPBdvjp1m2LCmDccOTxAht Content-Type: multipart/mixed; boundary="Q2682aCVSbAo04XSGLGf3u6AP485OP73k"; protected-headers="v1" From: Henrik Levkowetz To: Robert Moskowitz , Julian Reschke , "xml2rfc@ietf.org" Message-ID: <191e74ef-2216-c566-8830-ddd418e89002@levkowetz.com> Subject: Re: [xml2rfc] Problems running xml2rfc on Fedora 30 References: <84eafb24-f652-0c87-8063-2f7e381709e3@htt-consult.com> <8e2f08b5-0b33-572d-dd8b-b90ddde888d9@gmx.de> In-Reply-To: --Q2682aCVSbAo04XSGLGf3u6AP485OP73k Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Bob, On 2019-07-26 19:30, Robert Moskowitz wrote: > Here is the xml. I believe it is unchanged for what I used on my old=20 > Fedora 28 system (back at home) and submitted long ago... >=20 > And where does one open a ticket? https://trac.tools.ietf.org/tools/xml2rfc/trac/. Log in with your tools password (not datatracker, unless you've set them to be the same) and you'll see a 'New ticket' link in the main menubar. Henrik > On 7/26/19 1:26 PM, Julian Reschke wrote: >> On 26.07.2019 18:40, Robert Moskowitz wrote: >>> This is the first time running xml2rfc on my new, Fedora 30 build. >>> >>> I had done the 'pip install xml2rfc' when I built this system a coupl= e >>> months ago. Today I went to run it and got errors. SO I grabbed the= >>> xml from a draft I worked with back on Fedora 28 and got the followin= g >>> for my efforts: >>> >>> $ xml2rfc draft-moskowitz-hierarchical-hip-06.xml >>> Parsing file draft-moskowitz-hierarchical-hip-06.xml >>> Traceback (most recent call last): >>> File "/usr/bin/xml2rfc", line 11, in >>> load_entry_point('xml2rfc=3D=3D2.22.3', 'console_scripts', 'xml2= rfc')() >>> File "/usr/lib/python2.7/site-packages/xml2rfc/run.py", line 386, = in >>> main >>> xmlrfc =3D parser.parse(remove_pis=3Doptions.remove_pis,=20 >>> normalize=3DTrue) >>> File "/usr/lib/python2.7/site-packages/xml2rfc/parser.py", line 59= 9, >>> in parse >>> include=3DTrue, line_no=3Dgetattr(element, 'sourceline', 0)) >>> File "/usr/lib/python2.7/site-packages/xml2rfc/parser.py", line 30= 2, >>> in getReferenceRequest >>> result =3D self.cache(url) >>> File "/usr/lib/python2.7/site-packages/xml2rfc/parser.py", line 36= 8, >>> in cache >>> r =3D session.get(url) >>> File "/usr/lib/python2.7/site-packages/requests/sessions.py", line= >>> 546, in get >>> return self.request('GET', url, **kwargs) >>> File "/usr/lib/python2.7/site-packages/requests/sessions.py", line= >>> 533, in request >>> resp =3D self.send(prep, **send_kwargs) >>> File "/usr/lib/python2.7/site-packages/requests/sessions.py", line= >>> 646, in send >>> r =3D adapter.send(request, **kwargs) >>> File "/usr/lib/python2.7/site-packages/requests/adapters.py", line= >>> 498, in send >>> raise ConnectionError(err, request=3Drequest) >>> requests.exceptions.ConnectionError: ('Connection aborted.', >>> BadStatusLine('No status line received - the server has closed the >>> connection',)) >>> >>> >>> Please advise me on how to fix this. I can provide the xml if needed= =2E >> >> I suspect something is wrong with your reference includes (or actually= >> with the server you're trying to reach). >> >> Please send XML :-) >> >> Best regards, Julian >> >> PS: and we should open a ticket to get more usable error messages... >> >> >> >=20 >=20 >=20 > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc >=20 --Q2682aCVSbAo04XSGLGf3u6AP485OP73k-- --SSfWn3QlmecgPBdvjp1m2LCmDccOTxAht Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl07SKAACgkQTptXS4+7 FxoSuw/+INc9t5AgzjDDgAg163Q1D9UvA9ZsGh2Qtnln6dn2mOZ9OCEP8azHMCSR J9MM0LaShnul33NJXZRXUGPnKRxg9regKm5z2i/GiC1JhC8v1h9OtStwKvhYhPkY q48Hh3WmDBxA/SLXuAw2CW92i8Roud7IrwJbXOoTGtVJmUCHbsM7eHip45RQQJ1F UL4VHntuQmvyZ3+qS5V5XRE/RlEs4L6/RTiarp3BOJjTV1We0N66Z3CYFasdzM5n sKjbo6AVxeRzUlHI2uw1TI59MEnOPnmmYj70pcBcZYTR00OFTtPCU97io/D34cGk hYqdmhVCEMUs4gt35LySaYvFXWKl1hAS7Xi4NtcfYE5D4YEyetjBR5l1fgVMv+54 YzlSU0buOjSAEEoiiBOIH/zHlFNTFhqbmDc0Kdq5N25wEmq2fJreiKbhxD8GHbX2 lB3cA+xook/oUh8R3lY6a8YtGA5U2uZG1cA3z3DpAPY3VL3m5SiJ2TqmJCLj9BNR VepD6zwsY+ZDxUGc5wQXGtGlfWYor7/newNJ+IEOlxwQgL4n3MBnEKZSQKp9YQ1J mul/Z683UuWT7iQJ5DxAY0wuPGb20gHBUAkjTaE1V15UiI9uQ0uhpovhm55PixZA FgOaf7kxVV27G+FH3JFLSVqQoQKHIoofyntYbdeLZtMFPseF4Bw= =yKHd -----END PGP SIGNATURE----- --SSfWn3QlmecgPBdvjp1m2LCmDccOTxAht-- From nobody Sat Jul 27 06:43:37 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDA212012A for ; Sat, 27 Jul 2019 06:43:36 -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, 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 IZFAsi5xz9VL for ; Sat, 27 Jul 2019 06:43:33 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [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 5B75C120271 for ; Sat, 27 Jul 2019 06:43:33 -0700 (PDT) Received: from localhost ([::1]:40016 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1hrMyy-0004Tn-W5; Sat, 27 Jul 2019 06:43:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Cc: xml2rfc@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: henrik@levkowetz.com, daveoran@orandom.net X-Trac-Project: xml2rfc Date: Sat, 27 Jul 2019 13:43:32 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/412 Message-ID: <068.029816f39c428be797b412008be6a87e@tools.ietf.org> X-Trac-Ticket-ID: 412 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, daveoran@orandom.net, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: [xml2rfc] #412 (Version 2 cli): XML2RFC is blowing up on the attached draft X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2019 13:43:36 -0000 #412: XML2RFC is blowing up on the attached draft i couldn't find anything useful in the traceback: ORAN-M-51B7:Flowbalance Draft oran$ xml2rfc draft-oran-icnrg- flowbalance-00.xml Parsing file draft-oran-icnrg-flowbalance-00.xml Traceback (most recent call last): File "/usr/local/bin/xml2rfc", line 11, in load_entry_point('xml2rfc==2.5.2', 'console_scripts', 'xml2rfc')() File "/usr/local/lib/python2.7/site-packages/xml2rfc/run.py", line 233, in main pagedwriter.write(filename) File "/usr/local/lib/python2.7/site-packages/xml2rfc/writers/base.py", line 1259, in write self._build_index() File "/usr/local/lib/python2.7/site-packages/xml2rfc/writers/base.py", line 1103, in _build_index self._indexRef(ref_counter, title=title, anchor=ref.attrib["anchor"]) File "src/lxml/lxml.etree.pyx", line 2452, in lxml.etree._Attrib.__getitem__ (src/lxml/lxml.etree.c:70080) KeyError: 'anchor' -- ----------------------------------+---------------------------------- Reporter: daveoran@orandom.net | Owner: henrik@levkowetz.com Type: defect | Status: new Priority: major | Milestone: Component: Version 2 cli | Version: 2.10.x Keywords: | ----------------------------------+---------------------------------- Ticket URL: xml2rfc From nobody Sat Jul 27 08:10:08 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B19912001A for ; Sat, 27 Jul 2019 08:10:07 -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, 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 7iJIfvpEuDVx for ; Sat, 27 Jul 2019 08:10:05 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [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 E609D12000E for ; Sat, 27 Jul 2019 08:10:05 -0700 (PDT) Received: from localhost ([::1]:41810 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1hrOKj-0000uC-FY; Sat, 27 Jul 2019 08:10:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Cc: xml2rfc@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: henrik@levkowetz.com, julian.reschke@gmx.de X-Trac-Project: xml2rfc Date: Sat, 27 Jul 2019 15:10:05 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/412#comment:1 Message-ID: <083.4e937adb5c09a75ca8b3c53aff4c42cc@tools.ietf.org> References: <068.029816f39c428be797b412008be6a87e@tools.ietf.org> X-Trac-Ticket-ID: 412 In-Reply-To: <068.029816f39c428be797b412008be6a87e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, julian.reschke@gmx.de, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc] #412 (Version 2 cli): XML2RFC is blowing up on the attached draft X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2019 15:10:08 -0000 #412: XML2RFC is blowing up on the attached draft Comment (by julian.reschke@gmx.de): Diagnostics from rfc2629.xslt: {{{ WARNING: missing anchor on reference: An Improved Hop-by-hop Interest Shaper for Congestion Control in Named Data Networking, in ACM SIGCOMMx 2013 (at line 245) WARNING: missing text in address/phone (at line 59) }}} So the @anchor element is missing on the reference. (rfc2629.xslt reports that as WARNING but it really is an ERROR). -- -----------------------------------+---------------------------------- Reporter: daveoran@orandom.net | Owner: henrik@levkowetz.com Type: defect | Status: new Priority: major | Milestone: Component: Version 2 cli | Version: 2.10.x Resolution: | Keywords: -----------------------------------+---------------------------------- Ticket URL: xml2rfc From nobody Wed Jul 31 11:09:59 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E50EA120628 for ; Wed, 31 Jul 2019 11:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 bmQlcj9t4tCV for ; Wed, 31 Jul 2019 11:09:56 -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 2AB4E1201E5 for ; Wed, 31 Jul 2019 11:09:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id E384C60D1B for ; Wed, 31 Jul 2019 14:09:43 -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 Rjvl0Lp98arb for ; Wed, 31 Jul 2019 14:09:40 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 1467B6096F for ; Wed, 31 Jul 2019 14:09:39 -0400 (EDT) To: "xml2rfc@ietf.org" From: Robert Moskowitz Message-ID: <08a2115c-54a4-b049-02ea-340f8e7dce20@htt-consult.com> Date: Wed, 31 Jul 2019 14:09:32 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [xml2rfc] xml to markdown? X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 18:09:58 -0000 I am having to work with people that prefer markdown for creating their IDs.  They go the md -> xml -> ID route. I have yet to figure out how to read markdown drafts let alone work with that format. Is there a tool I can use to convert my xml to markdown so that I can see what I have been doing looks like in markdown and see if all the xml features I use (like hangtext in defs) are mapped to markdown? thanks From nobody Wed Jul 31 11:21:09 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1B712067C for ; Wed, 31 Jul 2019 11:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 DTrCfzlZsaah for ; Wed, 31 Jul 2019 11:21:04 -0700 (PDT) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680054.outbound.protection.outlook.com [40.107.68.54]) (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 E38B81206AB for ; Wed, 31 Jul 2019 11:21:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ELMBA13bIgYwKkxNOp/ZC4WxrGprNs5I8Ih8nbvh683k6Sd6CajMWVOdwL14+DaMP1WAz/YtcQGubSMmAvSTo54dyJkZGg/kX5V2QMoPfg4PWuZc8hg6Z+mRDZpZPAiQKxS/pId5BqN1Ig8mUvTsggXFbcbHdi0iAruAusiq5TXU98Bi7+ghHft2sD0yTRm0A5f8y4lxrnHZUPknuMiszQ1es+mLCP9RgWwsTblt2KnWeXPjottOa+T7JHOuNTSiREkuyWwYCIU/ZnCa3E+RBKum37Jw3HTrj7g+OWCX3wPdx1dhUZIY6/Tgjq+vU2BVIUzqrliixAVrqErIZOc45w== 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=8pwkGILb2KvdgAoa5KFqjVKLaSw3pyg38EE0LyqIdLA=; b=JM/woZUp8sf9hTv56VK19eH+WOlEM0jVqtWm6IHfC7h6to4+6qPOfk/Iy0dglkY2Ek8H35py7J1nXilyqgz3oEiBBjx8xMGbn73n9UA86wfYaAvNBvps0jtW7yJFjqjwqDDkuZZI+qzJbphaVRySuDlwv48iHH4CpOLvM0fOmYcSuKoqbC5m2KGmjGIH1UNcdAE00MdUG5s7479zqZ2Ujw7uaWNxQNJ+PfCuBm040RPm746jTroGm8/PCiP1zJXvF6Gbv+08y6mL023WdTS4/Y5YgTMEvL29OS96noI6wyFCWMI98WsvQmlrldNMiiQHVkyxpc51tN7nZiyPyI4O7w== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8pwkGILb2KvdgAoa5KFqjVKLaSw3pyg38EE0LyqIdLA=; b=LjHTAHGm/HQZNR1s46JugUraRDbVTnILUIq01DqM7Mv6Qj42BXATiIu987KhVrg866Og2SCy0y9Svn1e26vKWbk+NiaBnJorcoShEnD5QpbtIblsYRPQ7HcuyWwaSlJU9zozjGXwuprtSWHC3cf4NhadGfjRZfEbn1NKGa0Yj+A= Received: from SN6PR15MB2382.namprd15.prod.outlook.com (52.135.65.142) by SN6PR15MB2287.namprd15.prod.outlook.com (52.135.65.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.10; Wed, 31 Jul 2019 18:21:00 +0000 Received: from SN6PR15MB2382.namprd15.prod.outlook.com ([fe80::2008:6d9c:8b6f:c1ea]) by SN6PR15MB2382.namprd15.prod.outlook.com ([fe80::2008:6d9c:8b6f:c1ea%7]) with mapi id 15.20.2115.005; Wed, 31 Jul 2019 18:21:00 +0000 From: Scott Mansfield To: Robert Moskowitz , "xml2rfc@ietf.org" Thread-Topic: [xml2rfc] xml to markdown? Thread-Index: AQHVR8s0MSCVWBt93UuqYWCx6a2arKblCEoQ Date: Wed, 31 Jul 2019 18:20:59 +0000 Message-ID: References: <08a2115c-54a4-b049-02ea-340f8e7dce20@htt-consult.com> In-Reply-To: <08a2115c-54a4-b049-02ea-340f8e7dce20@htt-consult.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=scott.mansfield@ericsson.com; x-originating-ip: [38.98.217.150] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: eb4a4a9c-bd8a-4946-96af-08d715e3d6b6 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:SN6PR15MB2287; x-ms-traffictypediagnostic: SN6PR15MB2287: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 011579F31F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(366004)(396003)(136003)(376002)(346002)(13464003)(199004)(189003)(478600001)(305945005)(99936001)(966005)(74316002)(14454004)(66446008)(76116006)(25786009)(7736002)(66946007)(71200400001)(71190400001)(66556008)(64756008)(66476007)(66616009)(2501003)(7696005)(99286004)(11346002)(446003)(476003)(6506007)(53546011)(102836004)(486006)(256004)(44832011)(186003)(26005)(76176011)(66066001)(81156014)(86362001)(6436002)(316002)(110136005)(6246003)(3846002)(6116002)(5660300002)(55016002)(68736007)(52536014)(2906002)(6306002)(9686003)(53936002)(229853002)(8936002)(81166006)(8676002)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN6PR15MB2287; H:SN6PR15MB2382.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 8A2T0DptHm4h8yiE2jrzXS3esLeFMqTEGUlxxYrqgdnq6ULKKAAx2DUozdh2xNrz5WRzutdXKkSnWcrK7LTDSYPxKxJHnvM0DbB26i/8FI+mosCu0miJktU1mBRJt/4cNXYmZ3Xaw0c7TT4rGwstSjdbKpSHkvsiGhv52KV4qsVN7C39LmpVXPygI5+oNZVbNwVwsdA20ADvWESzOhK+4/IURfw+CbRN4sMTc4tcEgY9Y6s0hyNvopmext6YtSD0J7EA1VVM8q6ce7tQH0kEnJx5xMv8hDcv3wASqMe7h75TINf0JP0zLDCKohhtzqV5ezXVsw3GKUeaThsFfHlAY+ppDuigB68buzN0PDITaBP+dT7gpF9SYumZlCzPF9lkq5SP3z7qRpMzDAHS2LNSS7hIoQ/KDLLgdSFKPpO2E8w= Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0479_01D547AB.2C0A9B50" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: eb4a4a9c-bd8a-4946-96af-08d715e3d6b6 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2019 18:20:59.9244 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: scott.mansfield@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR15MB2287 Archived-At: Subject: Re: [xml2rfc] xml to markdown? X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 18:21:08 -0000 ------=_NextPart_000_0479_01D547AB.2C0A9B50 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit +1 I would really-really-really like an ABNF (or something) that provided a concise description of how the md maps to xml which maps to ID format. The md tooling that I got from here --> https://github.com/martinthomson/i-d-template has increased my productivity because I only have to worry about content. Regards, -scott. -----Original Message----- From: xml2rfc On Behalf Of Robert Moskowitz Sent: Wednesday, July 31, 2019 2:10 PM To: xml2rfc@ietf.org Subject: [xml2rfc] xml to markdown? I am having to work with people that prefer markdown for creating their IDs. They go the md -> xml -> ID route. I have yet to figure out how to read markdown drafts let alone work with that format. Is there a tool I can use to convert my xml to markdown so that I can see what I have been doing looks like in markdown and see if all the xml features I use (like hangtext in defs) are mapped to markdown? thanks _______________________________________________ xml2rfc mailing list xml2rfc@ietf.org https://www.ietf.org/mailman/listinfo/xml2rfc ------=_NextPart_000_0479_01D547AB.2C0A9B50 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVcTCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIGAjCCA+qgAwIBAgIR ALiW66rAzy4bAGYQ+J3LjhEwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoM CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMB4XDTE3MTEw NjE1NDEyOVoXDTIwMTEwNjE1NDEyOFowbDERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD1Nj b3R0IE1hbnNmaWVsZDErMCkGCSqGSIb3DQEJARYcc2NvdHQubWFuc2ZpZWxkQGVyaWNzc29uLmNv bTEQMA4GA1UEBRMHRVNDT01BTjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI0FubTp mqEsGKLyzK8ercOcS3oDhD9dqkMkcQHl6VnDNtZ0RLdHcyAG0aCuqm+Q56xA1FkjxcwKX0n1nUCp GwQthPZ+8VCZ5kZ8Nm0la9685gOfPhmxp3nr1oE36yiKmynpPETStz61j3xJGAR+QmGScTkAQoQC aHZcVKp5E52E4iLNB/WHbOoQgQA7nF9dBRSNM2AB1CLHUeCK+cDCAybF3tPP68j3XrqiPSci8xC9 quLhWw8wrm4D1IZeAdyst8dtJhMHofJ/QhBL9k6ZzDXV3qmRLzC9sx/iEYTnx0CRaNZxQW5RQ1kd MxMwhUDvyc268ogTcFcRUjVFqVlCAjkCAwEAAaOCAcIwggG+MEgGA1UdHwRBMD8wPaA7oDmGN2h0 dHA6Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwgYIG CCsGAQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBI BggrBgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5k aXZpZHVhbGNhdjMuY2VyMCcGA1UdEQQgMB6BHHNjb3R0Lm1hbnNmaWVsZEBlcmljc3Nvbi5jb20w VQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0 b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUF BwMCMB0GA1UdDgQWBBRaoqe7RYT60Apt3h4pCKxcZ3n2/jAfBgNVHSMEGDAWgBQcexmel5x2rCA9 2NzjkWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggIBAMxVMvMki5LD424D apnPWAgmI9LaPNRrBhMD5VmiUe3EFoZouN651tAJ5djgWHDHAVwj24atrhVB4rhhxawRvrGlDCDc DPzfLenpOZMi82l/+Tkbbfbl8rA8X/Jl6JVYYDXb61KI7naJD9aatfTZ1CXk4CNY6K2+ksX4lOiJ tG4bv+6/SvDikY682e/pptcBxM0w/imluDOmKzKm/7gTFOiJ5OpUcsN3svDkqhgfu+U6Kj6ANLaE LPVJrWniINVy6RJzKxgJL19cDFNfgETPtOZAeCjlKysi/7kxklmqdGXWyGm9Fya1W3UkRsYfGQVx pTgxkq0Ss6aexaitFpd7aQG5GcZOnT6hUwhquWuDp5vfMDdTf4/eokkOzUqRYQD1PcuqIWQLG/EU oKjBeuTm9ji3YC0XegV8eC2Fxo6ZaKfIlZLIcNGO3lFa2LUCyLQOPhGjrifNRXqV1bt3geVIlNLm HWGJICfjjZLMotimh2hfFH/ONZyPAgDiqqrUG0GnqonQ3LeeZ3RlSaucGt3VT0JXXJqg2f+vqiZF 65rv52k/d3M4SgbjHN9llU/YUW2dfwAXQsrWqWCWmJsHUqCtdQv8aFpTTwtwNuwVYTe7byV+fBow EQhML/tQfBDSiHBoMmK5GtyPQ9X5I2M71QwkL5R4GKqyUi3i116dk3nHg7sRMIIGwjCCBKqgAwIB AgIQU7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0BAQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVy YTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEw MjcxMjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJp Y3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AOzy3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5DtjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpR eQvt8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVb gt6jRrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1NwkTepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCo GyFlhFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJkwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/x vy/20aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7 MkCYrEqHMRaojI/VStloQgW76E76zQ2byw5QxrhOUbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygt QwuTLUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S 2WMday0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP05tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKH OTqdGTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QLsgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBX AgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50 cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0 LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/ AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6 Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZ npecdqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZI hvcNAQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PLFpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1 pmI5s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUbAL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS 4q90BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKy yFRypF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHo Qs86IWst821ww0wxsCpEfClIvF7fBw2QkbG/1PwuzAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eC a8QDXnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4 ruN7C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZ rPbNQUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9 mjbHXSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6 B+1i6Ds5j0Qpj5aQMYIDVjCCA1ICAQEwXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nz b24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQC4luuqwM8uGwBmEPid y44RMAkGBSsOAwIaBQCgggHPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTE5MDczMTE4MjA1OFowIwYJKoZIhvcNAQkEMRYEFAAgpZ0580C6nDqN+PDZ81BoFJUyMGsG CSsGAQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEAuJbrqsDPLhsAZhD4ncuOETBtBgsqhkiG 9w0BCRACCzFeoFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxF cmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEAuJbrqsDPLhsAZhD4ncuOETCBkwYJKoZIhvcN AQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUD BAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCGjALBglghkgBZQMEAgMw CwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQBQfoUadpBJLxfBh3B0 +OVcCQ+t7UhY4GTirQuHBURRHFCrPhKUvwubWNxWIPEcZWGAGt/Lsf+Yavx3K651UsVAbSTICaRa 56DOw0tb7l3DQSWRUgiF9hHwLNzYi2btHXZC6LmzjWsEMIwM8KUlGjBYmWUQ08CgRiSzsGJa3So1 lhwC4Wvqz8V3fgh8IzVV6oInDkF1oSPV7QuWN3/+pqaFYAawhV/7ovNUAEnVelapo1apZLNtHtdX GaByVhI8U1bmUO79qRyiKT2J+DvZVz1Nlom1qcPCY0abg1U9U6wKkQbpBrPLCIBPlDCVA3gYmCqu T2b9aKvMMPT/Zu3gFK58AAAAAAAA ------=_NextPart_000_0479_01D547AB.2C0A9B50-- From nobody Wed Jul 31 11:33:44 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D80781201EF for ; Wed, 31 Jul 2019 11:33:42 -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=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 iSrYZVRWTUtJ for ; Wed, 31 Jul 2019 11:33:37 -0700 (PDT) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 E3B2312019C for ; Wed, 31 Jul 2019 11:33:36 -0700 (PDT) Received: by mail-qt1-x82a.google.com with SMTP id h18so67587038qtm.9 for ; Wed, 31 Jul 2019 11:33:36 -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=3gg801Vu6SqaON1c/FBIQEFTabXJJd4q8GXdY0UdDEo=; b=uXt7vxB1DITDQ2xF72wshganA2WiJSsgeoa5WAoIOk25U9UrCjv7Wttf+2aT05cZGX qGU1mm2BlSkMAj9aRZ06YJgiDnNdpReo1UDVlH/HiIFFW0i/egDx0ZHh0LoS/2dEcQQM y59yh8q5+1anP1SVOvUnSUpmjSKD246xlRYaOmRfZHLBwooANvnGUEP5LIZ3UqjrplYH C76vjKZu6hZxPtUVFbCb8FuJZzuz0gXn+BTcXy6WaKodDnapBSNNVAQq+sdDD+E8qT/O GJ6QvSZAvvoCZss4rf1t8AFWqhpTaNZwHU6wbs3Yl16Sf3VvTKhzi5Vl8pqJ6zwJoS3/ U2oA== 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=3gg801Vu6SqaON1c/FBIQEFTabXJJd4q8GXdY0UdDEo=; b=PM649S9GbXjyiu8nHcfuqbbUtAibBfuc2wRvJ/BSQRLOy3NQqFXkekvHMqURdPR4Uw RKC5nBW+GpwKELKwhQg2SX4bwypBsPihC2ubEwPuo4OKSLPO8KeYNPVSl20LRWjrlu08 TP9Cczdv9HdvnE6PHH1MmMIa2emC5GnwfZo5ET0VqO5tm0YmChWteHtNl36wEpyMMN2A ZPvhk39h7a7I4fFMGu0/krrUHYqdUQ4+h70pYBKJlrM/ErkDbHTqbcGbULXSfHIV3/pl NTVAHq1BugPbxx1vNAonokVWwSf1qbJ4bIu5nLS/svNC4Oiju4KDaCOXDFVl6F54CYFT xfLw== X-Gm-Message-State: APjAAAVcqCESzY1/7AkQ1OIZdwJf51Cib6tMrBreig9vYXrNd1mFgYtk q+XX51mOuctvnum9rxdeNMoGFwHRxQiDsfKAs8kzpVhW9MU= X-Google-Smtp-Source: APXvYqxWtwwtQUKPcAUxS3ZhqOb2pvLKQq5AGa4xWzPh/WaYnad7fTwbsD2z4KO6mIY3qMPikTzkq8PT3NVJnkFAxJ0= X-Received: by 2002:ac8:2194:: with SMTP id 20mr58310615qty.203.1564598015909; Wed, 31 Jul 2019 11:33:35 -0700 (PDT) MIME-Version: 1.0 References: <08a2115c-54a4-b049-02ea-340f8e7dce20@htt-consult.com> In-Reply-To: <08a2115c-54a4-b049-02ea-340f8e7dce20@htt-consult.com> From: "Andrew G. Malis" Date: Wed, 31 Jul 2019 14:33:25 -0400 Message-ID: To: Robert Moskowitz Cc: "xml2rfc@ietf.org" , Carsten Bormann Content-Type: multipart/mixed; boundary="000000000000f495df058efe5cc9" Archived-At: Subject: Re: [xml2rfc] xml to markdown? X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 18:33:43 -0000 --000000000000f495df058efe5cc9 Content-Type: multipart/alternative; boundary="000000000000f495dd058efe5cc7" --000000000000f495dd058efe5cc7 Content-Type: text/plain; charset="UTF-8" Bob, While I don't have such a tool (although Carsten may), I do have a draft that uses a lot of kramdown features, please feel free to use it as a template. I use the tools at https://xml2rfc.tools.ietf.org/experimental.html for converting kramdown to text. In the top dialog box, "Convert Your XML Source", choose kramdown rather than xml2rfc as the input type. I go straight to text rather than generating xml as an intermediate step, although that option is available further down on that same page. I've attached my draft source and output so that you can compare them side by side. Cheers, Andy On Wed, Jul 31, 2019 at 2:10 PM Robert Moskowitz wrote: > I am having to work with people that prefer markdown for creating their > IDs. They go the md -> xml -> ID route. > > I have yet to figure out how to read markdown drafts let alone work with > that format. > > Is there a tool I can use to convert my xml to markdown so that I can > see what I have been doing looks like in markdown and see if all the xml > features I use (like hangtext in defs) are mapped to markdown? > > thanks > > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc > --000000000000f495dd058efe5cc7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Bob,

While I don't have such a tool= (although Carsten may), I do have a draft that uses a lot of kramdown feat= ures, please feel free to use it as a template. I use the tools at=C2=A0https://xml2rfc.t= ools.ietf.org/experimental.html for converting kramdown to text. In the= top dialog box, "Convert Your XML Source", choose kramdown rathe= r than xml2rfc as the input type. I go straight to text rather than generat= ing xml as an intermediate step, although that option is available further = down on that same page.

I've attached my draft= source and output so that you can compare them side by side.
Cheers,
Andy


On Wed, Jul 31, 2019= at 2:10 PM Robert Moskowitz <rgm= @htt-consult.com> wrote:
I am having to work with people that prefer markdown for cr= eating their
IDs.=C2=A0 They go the md -> xml -> ID route.

I have yet to figure out how to read markdown drafts let alone work with that format.

Is there a tool I can use to convert my xml to markdown so that I can
see what I have been doing looks like in markdown and see if all the xml features I use (like hangtext in defs) are mapped to markdown?

thanks

_______________________________________________
xml2rfc mailing list
xml2rfc@ietf.org<= br> https://www.ietf.org/mailman/listinfo/xml2rfc
--000000000000f495dd058efe5cc7-- --000000000000f495df058efe5cc9 Content-Type: text/plain; charset="US-ASCII"; name="draft-malis-detnet-controller-plane-framework-02.txt" Content-Disposition: attachment; filename="draft-malis-detnet-controller-plane-framework-02.txt" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_jyrl88wi1 CgoKCk5ldHdvcmsgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBBLiBNYWxpcwpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgSW5kZXBlbmRlbnQKSW50ZW5kZWQgc3RhdHVzOiBJbmZv cm1hdGlvbmFsICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBYLiBHZW5nCkV4cGly ZXM6IEphbnVhcnkgMjUsIDIwMjAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgTS4gQ2hlbgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBIdWF3ZWkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRi4gUWluCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENoaW5hIE1vYmls ZQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEp1bHkgMjQsIDIwMTkKCgogICAgICBEZXRlcm1pbmlzdGljIE5ldHdvcmtpbmcgKERldE5l dCkgQ29udHJvbGxlciBQbGFuZSBGcmFtZXdvcmsKICAgICAgICAgICAgZHJhZnQtbWFsaXMtZGV0 bmV0LWNvbnRyb2xsZXItcGxhbmUtZnJhbWV3b3JrLTAyCgpBYnN0cmFjdAoKICAgVGhpcyBkb2N1 bWVudCBwcm92aWRlcyBhIGZyYW1ld29yayBvdmVydmlldyBmb3IgdGhlIERldGVybWluaXN0aWMK ICAgTmV0d29ya2luZyAoRGV0TmV0KSBjb250cm9sbGVyIHBsYW5lLiAgSXQgZGlzY3Vzc2VzIGNv bmNlcHRzIGFuZAogICByZXF1aXJlbWVudHMgdGhhdCB3aWxsIGJlIGJhc2lzIGZvciBEZXRuZXQg Y29udHJvbGxlciBwbGFuZSBzb2x1dGlvbgogICBkb2N1bWVudHMuCgpTdGF0dXMgb2YgVGhpcyBN ZW1vCgogICBUaGlzIEludGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCBpbiBmdWxsIGNvbmZvcm1h bmNlIHdpdGggdGhlCiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkuCgogICBJbnRl cm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVl cmluZwogICBUYXNrIEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFs c28gZGlzdHJpYnV0ZQogICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBU aGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LQogICBEcmFmdHMgaXMgYXQgaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8uCgogICBJbnRlcm5ldC1EcmFmdHMgYXJl IGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMKICAgYW5k IG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50 cyBhdCBhbnkKICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURy YWZ0cyBhcyByZWZlcmVuY2UKICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4g YXMgIndvcmsgaW4gcHJvZ3Jlc3MuIgoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGly ZSBvbiBKYW51YXJ5IDI1LCAyMDIwLgoKQ29weXJpZ2h0IE5vdGljZQoKICAgQ29weXJpZ2h0IChj KSAyMDE5IElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlCiAgIGRv Y3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLgoKICAgVGhpcyBkb2N1bWVudCBp cyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbAogICBQcm92aXNp b25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzCiAgIChodHRwczovL3RydXN0ZWUuaWV0Zi5v cmcvbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YKICAgcHVibGljYXRpb24g b2YgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzCiAgIGNhcmVm dWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rpb25zIHdpdGgg cmVzcGVjdAogICB0byB0aGlzIGRvY3VtZW50LiAgQ29kZSBDb21wb25lbnRzIGV4dHJhY3RlZCBm cm9tIHRoaXMgZG9jdW1lbnQgbXVzdAoKCgpNYWxpcywgZXQgYWwuICAgICAgICAgICBFeHBpcmVz IEphbnVhcnkgMjUsIDIwMjAgICAgICAgICAgICAgICAgW1BhZ2UgMV0KDApJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgRGV0TmV0IENvbnRyb2xsZXIgUGxhbmUgICAgICAgICAgICAgICBKdWx5IDIw MTkKCgogICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UgdGV4dCBhcyBkZXNjcmliZWQg aW4gU2VjdGlvbiA0LmUgb2YKICAgdGhlIFRydXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBw cm92aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFzCiAgIGRlc2NyaWJlZCBpbiB0aGUgU2ltcGxpZmll ZCBCU0QgTGljZW5zZS4KClRhYmxlIG9mIENvbnRlbnRzCgogICAxLiAgSW50cm9kdWN0aW9uICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDIKICAgICAx LjEuICBUZXJtaW5vbG9neSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gICAzCiAgIDIuICBEZXROZXQgQ29udHJvbGxlciBQbGFuZSBSZXF1aXJlbWVudHMgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNAogICAzLiAgRGV0TmV0IENvbnRyb2wgUGxhbmUgQXJj aGl0ZWN0dXJlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDUKICAgICAzLjEuICBEaXN0 cmlidXRlZCBDb250cm9sIFBsYW5lIGFuZCBTaWduYWxpbmcgUHJvdG9jb2xzIC4gLiAuIC4gICA1 CiAgICAgMy4yLiAgU0ROL0Z1bGx5IENlbnRyYWxpemVkIENvbnRyb2wgUGxhbmUgLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAgNgogICAgIDMuMy4gIEh5YnJpZCBDb250cm9sIFBsYW5lICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDcKICAgNC4gIERldE5ldCBDb250cm9sIFBs YW5lIEFkZGl0aW9uYWwgRGV0YWlscyBhbmQgSXNzdWVzICAuIC4gLiAuIC4gICA4CiAgICAgNC4x LiAgRXhwbGljaXQgUGF0aHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAgOAogICAgIDQuMi4gIFJlc291cmNlIFJlc2VydmF0aW9uICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgIDgKICAgICA0LjMuICBQUkVPRiBTdXBwb3J0IC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA5CiAgICAgNC40LiAgRGV0TmV0 IGluIGEgVHJhZGl0aW9uYWwgTVBMUyBEb21haW4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgOQog ICAgIDQuNS4gIElQICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgMTAKICAgICA0LjYuICBEZXROZXQgd2l0aCBTZWdtZW50IFJvdXRpbmcgKFNS KSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEwCiAgIDUuICBNYW5hZ2VtZW50IFBsYW5lIE92 ZXJ2aWV3IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMgogICAgIDUuMS4g IFByb3Zpc2lvbmluZyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgMTIKICAgICA1LjIuICBEZXROZXQgT3BlcmF0aW9ucywgQWRtaW5pc3RyYXRpb24gYW5kIE1h aW50ZW5hbmNlIChPQU0pIC4gIDEyCiAgICAgICA1LjIuMS4gIE9BTSBmb3IgUGVyZm9ybWFuY2Ug TW9uaXRvcmluZyAoUE0pIC4gLiAuIC4gLiAuIC4gLiAuICAxMgogICAgICAgNS4yLjIuICBPQU0g Zm9yIEZhdWx0L0RlZmVjdCBNYW5hZ2VtZW50IChGTSkgIC4gLiAuIC4gLiAuIC4gLiAgMTMKICAg Ni4gIElBTkEgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDEzCiAgIDcuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMwogICA4LiAgQWNrbm93bGVkZ21lbnRzIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTMKICAgOS4gIFJlZmVy ZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDEzCiAgICAgOS4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAxNAogICAgIDkuMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTUKICAgQXV0aG9ycycgQWRkcmVzc2Vz ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE5CgoxLiAg SW50cm9kdWN0aW9uCgogICBEZXRlcm1pbmlzdGljIE5ldHdvcmtpbmcgKERldE5ldCkgcHJvdmlk ZXMgdGhlIGNhcGFiaWxpdHkgdG8gY2FycnkKICAgc3BlY2lmaWVkIHVuaWNhc3QgYW5kL29yIG11 bHRpY2FzdCBkYXRhIGZsb3dzIGZvciByZWFsLXRpbWUKICAgYXBwbGljYXRpb25zIHdpdGggZXh0 cmVtZWx5IGxvdyBkYXRhIGxvc3MgcmF0ZXMgYW5kIGJvdW5kZWQgbGF0ZW5jeQogICB3aXRoaW4g YSBuZXR3b3JrIGRvbWFpbi4gIEFzIGRpc2N1c3NlZCBpbiB0aGUgRGV0ZXJtaW5pc3RpYwogICBO ZXR3b3JraW5nIEFyY2hpdGVjdHVyZSBbSS1ELmlldGYtZGV0bmV0LWFyY2hpdGVjdHVyZV0sIHRl Y2huaXF1ZXMKICAgdXNlZCB0byBwcm92aWRlIHRoaXMgY2FwYWJpbGl0eSBpbmNsdWRlIHJlc2Vy dmluZyBkYXRhIHBsYW5lCiAgIHJlc291cmNlcyBmb3IgaW5kaXZpZHVhbCAob3IgYWdncmVnYXRl ZCkgRGV0TmV0IGZsb3dzIGluIHNvbWUgb3IgYWxsCiAgIG9mIHRoZSBpbnRlcm1lZGlhdGUgbm9k ZXMgYWxvbmcgdGhlIHBhdGggb2YgdGhlIGZsb3csIHByb3ZpZGluZwogICBleHBsaWNpdCByb3V0 ZXMgZm9yIERldE5ldCBmbG93cyB0aGF0IGRvIG5vdCBpbW1lZGlhdGVseSBjaGFuZ2Ugd2l0aAog ICB0aGUgbmV0d29yayB0b3BvbG9neSwgYW5kIGRpc3RyaWJ1dGluZyBkYXRhIGZyb20gRGV0TmV0 IGZsb3cgcGFja2V0cwogICBvdmVyIHRpbWUgYW5kL29yIHNwYWNlIHRvIGVuc3VyZSBkZWxpdmVy eSBvZiBlYWNoIHBhY2tldCdzIGRhdGEgaW4KICAgc3BpdGUgb2YgdGhlIGxvc3Mgb2YgYSBwYXRo LgoKCgoKTWFsaXMsIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDI1LCAyMDIwICAg ICAgICAgICAgICAgIFtQYWdlIDJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgIERldE5ldCBD b250cm9sbGVyIFBsYW5lICAgICAgICAgICAgICAgSnVseSAyMDE5CgoKICAgVGhlIERldE5ldCBk YXRhIHBsYW5lIGlzIGRlZmluZWQgaW4gYSBzZXQgb2YgZG9jdW1lbnRzIHRoYXQgYXJlCiAgIGFu Y2hvcmVkIGJ5IHRoZSBEZXROZXQgRGF0YSBQbGFuZSBGcmFtZXdvcmsKICAgW0ktRC5pZXRmLWRl dG5ldC1kYXRhLXBsYW5lLWZyYW1ld29ya10gYW5kIHRoZSBhc3NvY2lhdGVkIERldE5ldCBNUExT CiAgIFtJLUQuaWV0Zi1kZXRuZXQtbXBsc10gYW5kIElQIFtJLUQuaWV0Zi1kZXRuZXQtaXBdIGRh dGEgcGxhbmUKICAgc3BlY2lmaWNhdGlvbnMsIHdpdGggYWRkaXRpb25hbCBkZXRhaWxzIGFuZCBz dWJuZXQgbWFwcGluZ3MgcHJvdmlkZWQKICAgaW4gW0ktRC5pZXRmLWRldG5ldC1pcC1vdmVyLW1w bHNdLAogICBbSS1ELmlldGYtZGV0bmV0LW1wbHMtb3Zlci11ZHAtaXBdLCBbSS1ELmlldGYtZGV0 bmV0LW1wbHMtb3Zlci10c25dLAogICBbSS1ELmlldGYtZGV0bmV0LWlwLW92ZXItdHNuXSwgYW5k CiAgIFtJLUQuaWV0Zi1kZXRuZXQtdHNuLXZwbi1vdmVyLW1wbHNdLgoKICAgV2hpbGUgdGhlIERl dG5ldCBBcmNoaXRlY3R1cmUgYW5kIERhdGEgUGxhbmUgRnJhbWV3b3JrIGRvY3VtZW50cyBhcmUK ICAgcHJpbWFyaWx5IGNvbmNlcm5lZCB3aXRoIGRhdGEgcGxhbmUgb3BlcmF0aW9ucywgdGhleSBk byBjb250YWluIHNvbWUKICAgcmVmZXJlbmNlcyBhbmQgcmVxdWlyZW1lbnRzIGZvciBmdW5jdGlv bnMgdGhhdCB3b3VsZCBiZSByZXF1aXJlZCBpbgogICBvcmRlciB0byBhdXRvbWF0ZSBEZXROZXQg c2VydmljZSBwcm92aXNpb25pbmcgYW5kIG1vbml0b3JpbmcgdmlhIGEKICAgRGV0TmV0IGNvbnRy b2xsZXIgcGxhbmUuICBUaGUgcHVycG9zZSBvZiB0aGlzIGRvY3VtZW50IGlzIHRvIGdhdGhlcgog ICB0aGVzZSByZWZlcmVuY2VzIGFuZCByZXF1aXJlbWVudHMgaW50byBhIHNpbmdsZSBkb2N1bWVu dCBhbmQgZGlzY3VzcwogICBob3cgdmFyaW91cyBwb3NzaWJsZSBEZXROZXQgY29udHJvbGxlciBw bGFuZSBhcmNoaXRlY3R1cmVzIGNvdWxkIGJlCiAgIHVzZWQgdG8gc2F0aXNmeSB0aGVzZSByZXF1 aXJlbWVudHMsIHdoaWxlIG5vdCBwcm92aWRpbmcgdGhlIGFjdHVhbAogICBwcm90b2NvbCBkZXRh aWxzIGZvciBhIERldE5ldCBjb250cm9sbGVyIHBsYW5lIHNvbHV0aW9uLiAgU3VjaAogICBjb250 cm9sbGVyIHBsYW5lIHByb3RvY29sIHNvbHV0aW9ucyB3aWxsIGJlIHRoZSBzdWJqZWN0IG9mIHN1 YnNlcXVlbnQKICAgZG9jdW1lbnRzLgoKICAgTm90ZSB0aGF0IGluIHRoZSBEZXROZXQgb3ZlcmFs bCBhcmNoaXRlY3R1cmUsIHRoZSBjb250cm9sbGVyIHBsYW5lCiAgIGluY2x1ZGVzIHdoYXQgYXJl IG1vcmUgdHJhZGl0aW9uYWxseSBjb25zaWRlcmVkIHNlcGFyYXRlIGNvbnRyb2wgYW5kCiAgIG1h bmFnZW1lbnQgcGxhbmVzLiAgVHJhZGl0aW9uYWxseSwgdGhlIG1hbmFnZW1lbnQgcGxhbmUgaXMg cHJpbWFyaWx5CiAgIGludm9sdmVkIHdpdGggbm9kZSBhbmQgbmV0d29yayBwcm92aXNpb25pbmcs IG9wZXJhdGlvbmFsIE9BTSBmb3IKICAgcGVyZm9ybWFuY2UgbW9uaXRvcmluZywgYW5kIHRyb3Vi bGVzaG9vdGluZyBuZXR3b3JrIGJlaGF2aW9ycyBhbmQKICAgb3V0YWdlcywgd2hpbGUgdGhlIGNv bnRyb2wgcGxhbmUgaXMgcHJpbWFyaWx5IHJlc3BvbnNpYmxlIGZvciB0aGUKICAgaW5zdGFudGlh dGlvbiBhbmQgbWFpbnRlbmFuY2Ugb2YgZmxvd3MsIE1QTFMgbGFiZWwgYWxsb2NhdGlvbiBhbmQK ICAgZGlzdHJpYnV0aW9uLCBhbmQgYWN0aXZlIGluLWJhbmQgb3Igb3V0LW9mLWJhbmQgc2lnbmFs aW5nIHRvIHN1cHBvcnQKICAgdGhlc2UgZnVuY3Rpb25zLiAgSW4gdGhlIERldE5ldCBhcmNoaXRl Y3R1cmUsIGFsbCBvZiB0aGlzCiAgIGZ1bmN0aW9uYWxpdHkgaXMgY29tYmluZWQgaW50byBhIHNp bmdsZSBDb250cm9sbGVyIFBsYW5lLiAgU2VlCiAgIFNlY3Rpb24gNC40LjIgb2YgW0ktRC5pZXRm LWRldG5ldC1hcmNoaXRlY3R1cmVdIGFuZCB0aGUgYWdncmVnYXRpb24KICAgb2YgQ29udHJvbCBh bmQgTWFuYWdlbWVudCBwbGFuZXMgaW4gW1JGQzc0MjZdIGZvciBmdXJ0aGVyIGRldGFpbHMuCgox LjEuICBUZXJtaW5vbG9neQoKICAgVGhpcyBkb2N1bWVudCB1c2VzIHRoZSB0ZXJtaW5vbG9neSBl c3RhYmxpc2hlZCBpbiB0aGUgRGV0TmV0CiAgIEFyY2hpdGVjdHVyZSBbSS1ELmlldGYtZGV0bmV0 LWFyY2hpdGVjdHVyZV0sIGFuZCB0aGUgcmVhZGVyIGlzCiAgIGFzc3VtZWQgdG8gYmUgZmFtaWxp YXIgd2l0aCB0aGF0IGRvY3VtZW50IGFuZCBpdHMgdGVybWlub2xvZ3kuCgogICBUaGUga2V5IHdv cmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIs CiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJOT1QgUkVDT01NRU5E RUQiLCAiTUFZIiwgYW5kCiAgICJPUFRJT05BTCIgaW4gdGhpcyBkb2N1bWVudCBhcmUgdG8gYmUg aW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIEJDUAogICAxNCBbUkZDMjExOV0gW1JGQzgxNzRd IHdoZW4sIGFuZCBvbmx5IHdoZW4sIHRoZXkgYXBwZWFyIGluIGFsbAogICBjYXBpdGFscywgYXMg c2hvd24gaGVyZS4KCgoKCgpNYWxpcywgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkg MjUsIDIwMjAgICAgICAgICAgICAgICAgW1BhZ2UgM10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgRGV0TmV0IENvbnRyb2xsZXIgUGxhbmUgICAgICAgICAgICAgICBKdWx5IDIwMTkKCgoyLiAg RGV0TmV0IENvbnRyb2xsZXIgUGxhbmUgUmVxdWlyZW1lbnRzCgogICBPdGhlciBEZXROZXQgZG9j dW1lbnRzLCBpbmNsdWRpbmcgW0ktRC5pZXRmLWRldG5ldC1hcmNoaXRlY3R1cmVdIGFuZAogICBb SS1ELmlldGYtZGV0bmV0LWRhdGEtcGxhbmUtZnJhbWV3b3JrXSwgY29udGFpbiByZXF1aXJlbWVu dHMgZm9yIHRoZQogICBDb250cm9sbGVyIFBsYW5lLiAgRm9yIGNvbnZlbmllbmNlLCB0aGVzZSBy ZXF1aXJlbWVudHMgaGF2ZSBiZWVuCiAgIGNvbXBpbGVkIGhlcmUuICBUaGUgcHJpbWFyeSByZXF1 aXJlbWVudHMgb2YgdGhlIERldE5ldCBDb250cm9sbGVyCiAgIFBsYW5lIGFyZSB0aGF0IGl0IG11 c3QgYmUgYWJsZSB0bzoKCiAgIG8gIFN1cHBvcnQgdGhlIGR5bmFtaWMgY3JlYXRpb24sIG1vZGlm aWNhdGlvbiwgYW5kIGRlbGV0aW9uIG9mIERldE5ldAogICAgICBmbG93cy4gIFRoaXMgbWF5IGlu Y2x1ZGUgc29tZSBvciBhbGwgb2YgZXhwbGljaXQgcGF0aAogICAgICBkZXRlcm1pbmF0aW9uLCBs aW5rIGJhbmR3aWR0aCByZXNlcnZhdGlvbnMsIHJlc3RyaWN0aW5nIGZsb3dzIHRvCiAgICAgIElF RUUgODAyLjEgVGltZS1TZW5zaXRpdmUgTmV0d29ya2luZyAoVFNOKSBsaW5rcywgbm9kZSBidWZm ZXIgYW5kCiAgICAgIG90aGVyIHJlc291cmNlIHJlc2VydmF0aW9ucywgc3BlY2lmaWNhdGlvbiBv ZiByZXF1aXJlZCBxdWV1aW5nCiAgICAgIGRpc2NpcGxpbmVzIGFsb25nIHRoZSBwYXRoLCBhYmls aXR5IHRvIG1hbmFnZSBiaWRpcmVjdGlvbmFsIGZsb3dzLAogICAgICBldGMuLCBhcyBuZWVkZWQg Zm9yIGEgZmxvdy4KCiAgIG8gIFN1cHBvcnQgRGV0TmV0IGZsb3cgYWdncmVnYXRpb24gYW5kIGRl LWFnZ3JlZ2F0aW9uIHZpYSB0aGUgYWJpbGl0eQogICAgICB0byBkeW5hbWljYWxseSBjcmVhdGUg YW5kIGRlbGV0ZSBmbG93IGFnZ3JlZ2F0ZXMgKEZBcyksIGFuZCBiZQogICAgICBhYmxlIHRvIG1v ZGlmeSBleGlzdGluZyBGQXMgYnkgYWRkaW5nIG9yIGRlbGV0aW5nIG1lbWJlcnMuCgogICBvICBP cGVyYXRlIGluIGEgY29udmVyZ2VkIG5ldHdvcmsgZG9tYWluIHRoYXQgY29udGFpbnMgYm90aCBE ZXROZXQKICAgICAgYW5kIG5vbi1EZXROZXQgZmxvd3MuCgogICBvICBBbGxvdyBmbG93IGluc3Rh bnRpYXRpb24gcmVxdWVzdHMgdG8gb3JpZ2luYXRlIGluIGFuIGVuZAogICAgICBhcHBsaWNhdGlv biAodmlhIGFuIEFwcGxpY2F0aW9uIFByb2dyYW1taW5nIEludGVyZmFjZSAoQVBJKSwgdmlhCiAg ICAgIHN0YXRpYyBwcm92aXNpb25pbmcsIG9yIHZpYSBhIGR5bmFtaWMgY29udHJvbCBwbGFuZSwg c3VjaCBhcyBhCiAgICAgIGNlbnRyYWxpemVkIFNETiBjb250cm9sbGVyIG9yIGRpc3RyaWJ1dGVk IHNpZ25hbGluZyBwcm90b2NvbHMuCiAgICAgIFNlZSBTZWN0aW9uIDMgZm9yIGZ1cnRoZXIgZGlz Y3Vzc2lvbiBvZiB0aGVzZSBvcHRpb25zLgoKICAgbyAgSW4gdGhlIGNhc2Ugb2YgdGhlIERldE5l dCBNUExTIGRhdGEgcGxhbmUsIG1hbmFnZSBEZXROZXQgUy1MYWJlbAogICAgICBhbmQgRi1MYWJl bCBhbGxvY2F0aW9uIGFuZCBkaXN0cmlidXRpb24uCgogICBvICBBbHNvIGluIHRoZSBjYXNlIG9m IHRoZSBEZXROZXQgTVBMUyBkYXRhIHBsYW5lLCBzdXBwb3J0IHBhY2tldAogICAgICByZXBsaWNh dGlvbiwgZHVwbGljYXRlIGVsaW1pbmF0aW9uLCBhbmQgcGFja2V0IG9yZGVyaW5nIGZ1bmN0aW9u cwogICAgICAoUFJFT0YpLCBhbmQgdG8gYmUgYWJsZSB0byBwbGFjZSB0aGVzZSBmdW5jdGlvbnMg YXQgYXBwcm9wcmlhdGUKICAgICAgcGxhY2VzIGluIHRoZSBuZXR3b3JrLgoKICAgbyAgU3VwcG9y dCBhcHBsaWNhdGlvbnMgdGhhdCByZXF1aXJlIHRoZSBhYmlsaXR5IHRvIHN5bmNocm9uaXplIHRo ZQogICAgICBjbG9ja3MgaW4gZW5kIHN5c3RlbXMgdG8gdGhlIGV4dGVudCBzdXBwb3J0ZWQgYnkg dGhlIERldE5ldCBkYXRhCiAgICAgIHBsYW5lLgoKICAgbyAgU3VwcG9ydCBxdWV1ZSBjb250cm9s IHRlY2huaXF1ZXMgZGVmaW5lZCBpbiBTZWN0aW9uIDQuNSBvZgogICAgICBbSS1ELmlldGYtZGV0 bmV0LWFyY2hpdGVjdHVyZV0gYW5kCiAgICAgIFtJLUQuZmlubi1kZXRuZXQtYm91bmRlZC1sYXRl bmN5XSB0aGF0IHJlcXVpcmUgdGltZQogICAgICBzeW5jaHJvbml6YXRpb24gYW1vbmcgbmV0d29y ayBub2Rlcy4KCiAgIG8gIEFkdmVydGlzZSBzdGF0aWMgYW5kIGR5bmFtaWMgbm9kZSBhbmQgbGlu ayByZXNvdXJjZXMgc3VjaCBhcwogICAgICBjYXBhYmlsaXRpZXMgYW5kIGFkamFjZW5jaWVzIHRv IG90aGVyIG5ldHdvcmsgbm9kZXMgKGZvciBkeW5hbWljCgoKCk1hbGlzLCBldCBhbC4gICAgICAg ICAgIEV4cGlyZXMgSmFudWFyeSAyNSwgMjAyMCAgICAgICAgICAgICAgICBbUGFnZSA0XQoMCklu dGVybmV0LURyYWZ0ICAgICAgICAgICBEZXROZXQgQ29udHJvbGxlciBQbGFuZSAgICAgICAgICAg ICAgIEp1bHkgMjAxOQoKCiAgICAgIHNpZ25hbGluZyBhcHByb2FjaGVzKSBvciB0byBuZXR3b3Jr IGNvbnRyb2xsZXJzIChmb3IgY2VudHJhbGl6ZWQKICAgICAgYXBwcm9hY2hlcykuCgogICBvICBB ZGFwdCB0byBuZXR3b3JrIHRvcG9sb2d5IGNoYW5nZXMgc3VjaCBhcyBsaW5rcyBvciBub2RlcyBm YWlsdXJlcy4KCiAgIG8gIFNjYWxlIHRvIGhhbmRsZSB0aGUgbnVtYmVyIG9mIERldE5ldCBmbG93 cyBleHBlY3RlZCBpbiBhIGRvbWFpbgogICAgICAod2hpY2ggbWF5IHJlcXVpcmUgcGVyLWZsb3cg c2lnbmFsaW5nIG9yIHByb3Zpc2lvbmluZykuICBUaGlzIGlzCiAgICAgIHNpbWlsYXIgdG8gc2Nh bGFiaWxpdHkgcmVxdWlyZW1lbnRzIGFzc29jaWF0ZWQgd2l0aCBuZXR3b3JrCiAgICAgIHNsaWNp bmcgW0ktRC5kb25nLXNwcmluZy1zci1mb3ItZW5oYW5jZWQtdnBuXS4KCiAgIG8gIFByb3Zpc2lv biBmbG93IGlkZW50aWZpY2F0aW9uIGluZm9ybWF0aW9uIGF0IGVhY2ggb2YgdGhlIG5vZGVzCiAg ICAgIGFsb25nIHRoZSBwYXRoLiAgRmxvdyBpZGVudGlmaWNhdGlvbiBtYXkgZGlmZmVyIGRlcGVu ZGluZyBvbiB0aGUKICAgICAgbG9jYXRpb24gaW4gdGhlIG5ldHdvcmsgYW5kIHRoZSBEZXROZXQg ZnVuY3Rpb25hbGl0eSAoZS5nLiB0cmFuc2l0CiAgICAgIG5vZGUgdnMuIHJlbGF5IG5vZGUpLgoK ICAgbyAgTW9uaXRvciB0aGUgcGVyZm9ybWFuY2Ugb2YgRGV0TmV0IGZsb3dzIHRvIGVuc3VyZSB0 aGF0IHRoZXkgYXJlCiAgICAgIG1lZXRpbmcgcmVxdWlyZWQgb2JqZWN0aXZlcy4KCjMuICBEZXRO ZXQgQ29udHJvbCBQbGFuZSBBcmNoaXRlY3R1cmUKCiAgIEFzIG5vdGVkIGluIHRoZSBJbnRyb2R1 Y3Rpb24sIHRoZSBEZXROZXQgY29udHJvbCBwbGFuZSBpcyByZXNwb25zaWJsZQogICBmb3IgdGhl IGluc3RhbnRpYXRpb24gYW5kIG1haW50ZW5hbmNlIG9mIGZsb3dzLCBNUExTIGxhYmVsIGFsbG9j YXRpb24KICAgYW5kIGRpc3RyaWJ1dGlvbiwgYW5kIGFjdGl2ZSBpbi1iYW5kIG9yIG91dC1vZi1i YW5kIHNpZ25hbGluZyB0bwogICBzdXBwb3J0IHRoZXNlIGZ1bmN0aW9ucy4KCiAgIFRoZSBmb2xs b3dpbmcgc2VjdGlvbnMgZGVmaW5lIHRocmVlIHBvc3NpYmxlIGNsYXNzZXMgb2YgRGV0TmV0CiAg IGNvbnRyb2wgcGxhbmUgYXJjaGl0ZWN0dXJlczogYSBmdWxseSBkaXN0cmlidXRlZCBjb250cm9s IHBsYW5lCiAgIHV0aWxpemluZyBkeW5hbWljIHNpZ25hbGluZyBwcm90b2NvbHMsIGEgZnVsbHkg Y2VudHJhbGl6ZWQgU0ROLWxpa2UKICAgY29udHJvbCBwbGFuZSwgYW5kIGEgaHlicmlkIGNvbnRy b2wgcGxhbmUuICBUaGV5IGRpc2N1c3MgdGhlIHZhcmlvdXMKICAgaW5mb3JtYXRpb24gZXhjaGFu Z2VzIGJldHdlZW4gZW50aXRpZXMgaW4gdGhlIG5ldHdvcmsgaW4gZWFjaCBvZgogICB0aGVzZSBh cmNoaXRlY3R1cmVzIGFuZCB0aGUgYWR2YW50YWdlcyBhbmQgZGlzYWR2YW50YWdlcyBvZiBlYWNo CiAgIG9wdGlvbi4KCiAgIEluIGVhY2ggb2YgdGhlIGZvbGxvd2luZyBzZWN0aW9ucywgZXhhbXBs ZXMgYXJlIHVzZWQgdG8gaWxsdXN0cmF0ZQogICBwb3NzaWJsZSBtZWNoYW5pc21zIHRoYXQgY291 bGQgYmUgdXNlZCBpbiBlYWNoIG9mIHRoZSBhcmNoaXRlY3R1cmVzLgogICBUaGVzZSBhcmUgbm90 IG1lYW50IHRvIGJlIGV4aGF1c3RpdmUgb3IgdG8gcHJlY2x1ZGUgYW55IG90aGVyCiAgIHBvc3Np YmxlIG1lY2hhbmlzbSB0aGF0IGNvdWxkIGJlIHVzZWQgaW4gcGxhY2Ugb2YgdGhvc2UgdXNlZCBp biB0aGUKICAgZXhhbXBsZXMuCgozLjEuICBEaXN0cmlidXRlZCBDb250cm9sIFBsYW5lIGFuZCBT aWduYWxpbmcgUHJvdG9jb2xzCgogICBJbiBhIGZ1bGx5IGRpc3RyaWJ1dGVkIGNvbmZpZ3VyYXRp b24gbW9kZWwsIFVzZXItdG8tTmV0d29yayBJbnRlcmZhY2UKICAgKFVOSSkgaW5mb3JtYXRpb24g aXMgdHJhbnNtaXR0ZWQgb3ZlciBhICh0by1iZS1kZWZpbmVkKSBEZXROZXQgVU5JCiAgIHByb3Rv Y29sIGZyb20gdGhlIHVzZXIgc2lkZSB0byB0aGUgbmV0d29yayBzaWRlLCBhbmQgdGhlbiBVTkkg YW5kCiAgIG5ldHdvcmsgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiBwcm9wYWdhdGUgaW4gdGhl IG5ldHdvcmsgdmlhCiAgIGRpc3RyaWJ1dGVkIGNvbnRyb2wgcGxhbmUgc2lnbmFsaW5nIHByb3Rv Y29scy4gIFVzaW5nIGFuIFJTVlAtVEUKICAgdHJhZmZpYy1lbmdpbmVlcmVkIE1QTFMgbmV0d29y ayBhcyBhbiBleGFtcGxlOgoKCgoKTWFsaXMsIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBKYW51 YXJ5IDI1LCAyMDIwICAgICAgICAgICAgICAgIFtQYWdlIDVdCgwKSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgIERldE5ldCBDb250cm9sbGVyIFBsYW5lICAgICAgICAgICAgICAgSnVseSAyMDE5CgoK ICAgMS4gIEFuIElHUCBjb2xsZWN0cyB0b3BvbG9neSBpbmZvcm1hdGlvbiBhbmQgRGV0TmV0IGNh cGFiaWxpdGllcyBvZgogICAgICAgdGhlIG5ldHdvcmsgW2RyYWZ0LWdlbmctZGV0bmV0LWluZm8t ZGlzdHJpYnV0aW9uXTsKCiAgIDIuICBUaGUgY29udHJvbCBwbGFuZSBvZiB0aGUgaW5ncmVzcyBl ZGdlIG5vZGUgcmVjZWl2ZXMgYSBmbG93CiAgICAgICBlc3RhYmxpc2htZW50IHJlcXVlc3QgZnJv bSB0aGUgVU5JIGFuZCBjYWxjdWxhdGVzIG9uZSBvciBtb3JlCiAgICAgICB2YWxpZCBwYXRoKHMp OwoKICAgMy4gIFVzaW5nIFJTVlAtVEUgW1JGQzMyMDldLCB0aGUgaW5ncmVzcyBlZGdlIG5vZGUg c2VuZHMgYSBQQVRICiAgICAgICBtZXNzYWdlIHdpdGggYW4gZXhwbGljaXQgcm91dGUuICBBZnRl ciByZWNlaXZpbmcgdGhlIFBBVEgKICAgICAgIG1lc3NhZ2UsIHRoZSBlZ3Jlc3MgZWRnZSBub2Rl IHNlbmRzIGEgUkVTViBtZXNzYWdlIHdpdGggdGhlCiAgICAgICBkaXN0cmlidXRlZCBsYWJlbCBh bmQgcmVzb3VyY2UgcmVzZXJ2YXRpb24gcmVxdWVzdC4KCiAgIEN1cnJlbnQgcmVzZXJ2YXRpb24t b3JpZW50ZWQgZGlzdHJpYnV0ZWQgY29udHJvbCBwbGFuZSBwcm90b2NvbHMsCiAgIGUuZy4gIFJT VlAtVEUgYW5kIFN0cmVhbSBSZXNlcnZhdGlvbiBQcm90b2NvbCAoU1JQKQogICBbSUVFRS44MDIu MVFjYy0yMDE4XSwgY2FuIG9ubHkgcmVzZXJ2ZSBiYW5kd2lkdGggYWxvbmcgdGhlIHBhdGgsCiAg IHdoaWxlIHRoZSBjb25maWd1cmF0aW9uIG9mIGEgZmluZS1ncmFpbmVkIHNjaGVkdWxlLCBlLmcu LCBUaW1lIEF3YXJlCiAgIFNoYXBpbmcgKFRBUykgW0lFRUUuODAyLjFRQlZfMjAxNV0sIGlzIG5v dCBzdXBwb3J0ZWQuICBJZiBSU1ZQLVRFIG9yCiAgIFNSUCB3ZXJlIHRvIGJlIHVzZWQgZm9yIGEg RGV0TmV0IGFwcGxpY2F0aW9uLCBpdCB3b3VsZCByZXF1aXJlCiAgIGV4dGVuc2lvbnMgaW4gb3Jk ZXIgdG8gc3VwcG9ydCBxdWV1ZSBhbmQgc2NoZWR1bGVyIHJlc2VydmF0aW9ucyBpbgogICBhZGRp dGlvbiB0byBiYW5kd2lkdGggcmVzZXJ2YXRpb24uCgogICBBcyBkaXNjdXNzZWQgaW4gU2VjdGlv biA0Ljkgb2YgW0ktRC5pZXRmLWRldG5ldC1hcmNoaXRlY3R1cmVdLAogICBzY2FsYWJpbGl0eSBp cyBhIHByaW1hcnkgY29uY2VybiBmb3IgRGV0TmV0LCBnaXZlbiB0aGUgbGFyZ2UgbnVtYmVyCiAg IG9mIGV4cGVjdGVkIGZsb3dzIGluIGEgRGV0TmV0IGRvbWFpbi4gIFRoaXMgY291bGQgcG90ZW50 aWFsbHkgYmUgbXVjaAogICBsYXJnZXIgdGhhbiwgZm9yIGV4YW1wbGUsIHRoZSBudW1iZXIgb2Yg TVBMUyB0cmFmZmljIHR1bm5lbHMgaW4gYQogICBuZXR3b3JrIHVzaW5nIE1QTFMgdHJhZmZpYyBl bmdpbmVlcmluZywgd2hpY2ggd291bGQgdHlwaWNhbGx5IGJlCiAgIE4qKE4tMSkgdHVubmVscywg d2hlcmUgTiBpcyB0aGUgbnVtYmVyIG9mIGVkZ2Ugcm91dGVycyBpbiB0aGUgZG9tYWluLgoKICAg RXZlbiB3aGVuIGZsb3cgYWdncmVnYXRpb24gaXMgdXNlZCwgRGV0TmV0IGRvbWFpbnMgY2FuIGJl IGV4cGVjdGVkIHRvCiAgIHN1cHBvcnQgYSB2ZXJ5IGxhcmdlIG51bWJlciBvZiBmbG93cyB0aGF0 IHdpbGwgbmVlZCBwYXJ0aWN1bGFyCiAgIHF1ZXVpbmcgZGlzY2lwbGluZXMgYW5kL29yIHJlc291 cmNlIGFsbG9jYXRpb24sIGRlcGVuZGluZyBvbiB0aGUKICAgcmVxdWlyZW1lbnRzIGZvciBlYWNo IGZsb3cuICBUaGlzIGNvdWxkIHJlcXVpcmUgYSBsYXJnZSBhbW91bnQgb2YKICAgZHluYW1pYyBz aWduYWxpbmcsIHN1Y2ggYXMgYW4gUlNWUC1URSBzZXNzaW9uIHRvIGVzdGFibGlzaCBhbmQKICAg bWFpbnRhaW4gZWFjaCBmbG93LiAgT3RoZXIgUlNWUC1URSBzY2FsYWJpbGl0eSBjb25jZXJucyBh cmUgZnVydGhlcgogICBkaXNjdXNzZWQgaW4gW1JGQzU0MzldLgoKICAgQWxsIG9mIHRoZSBhYm92 ZSB0ZW5kcyB0byBhcmd1ZSBhZ2FpbnN0IGEgcHVyZWx5IGRpc3RyaWJ1dGVkIGNvbnRyb2wKICAg cGxhbmUgZm9yIERldE5ldCBkb21haW5zLgoKMy4yLiAgU0ROL0Z1bGx5IENlbnRyYWxpemVkIENv bnRyb2wgUGxhbmUKCiAgIEluIHRoZSBmdWxseSBTRE4vY2VudHJhbGl6ZWQgY29uZmlndXJhdGlv biBtb2RlbCwgVU5JIGluZm9ybWF0aW9uIGlzCiAgIHRyYW5zbWl0dGVkIGZyb20gYSBDZW50cmFs aXplZCBVc2VyIENvbmZpZ3VyYXRpb24gKENVQykgb3IgZnJvbQogICBhcHBsaWNhdGlvbnMgdmlh IGFuIEFQSSBvciBub3J0aGJvdW5kIGludGVyZmFjZSB0byBhIENlbnRyYWxpemVkCiAgIENvbnRy b2xsZXIsIHdoaWNoIGlzIHRoZSBzb2xlIHNvdXJjZSBvZiByb3V0aW5nIGFuZCBmb3J3YXJkaW5n CiAgIGluZm9ybWF0aW9uIGZvciB0aGUgZG9tYWluLiAgQ29uZmlndXJhdGlvbnMgb2Ygbm9kZXMg Zm9yIERldE5ldCBmbG93cwogICBhcmUgcGVyZm9ybWVkIGJ5IHRoZSBjb250cm9sbGVyIHVzaW5n IGEgcHJvdG9jb2wgc3VjaCBhcyBORVRDT05GCiAgIFtSRkM2MjQxXS9ZQU5HIFtSRkM2MDIwXSBv ciBQQ0UtQ0MgW1JGQzgyODNdLiAgRm9yIGV4YW1wbGU6CgoKCk1hbGlzLCBldCBhbC4gICAgICAg ICAgIEV4cGlyZXMgSmFudWFyeSAyNSwgMjAyMCAgICAgICAgICAgICAgICBbUGFnZSA2XQoMCklu dGVybmV0LURyYWZ0ICAgICAgICAgICBEZXROZXQgQ29udHJvbGxlciBQbGFuZSAgICAgICAgICAg ICAgIEp1bHkgMjAxOQoKCiAgIDEuICBUaGUgY29udHJvbGxlciBjb2xsZWN0cyB0b3BvbG9neSBp bmZvcm1hdGlvbiBhbmQgRGV0TmV0CiAgICAgICBjYXBhYmlsaXRpZXMgb2YgdGhlIG5ldHdvcmsg dmlhIE5FVENPTkYvWUFORzsKCiAgIDIuICBUaGUgY29udHJvbGxlciByZWNlaXZlcyBhIGZsb3cg ZXN0YWJsaXNobWVudCByZXF1ZXN0IGZyb20gYSBVTkkKICAgICAgIGFuZCBjYWxjdWxhdGVzIG9u ZSBvciBtb3JlIHZhbGlkIHBhdGgocykgdGhyb3VnaCB0aGUgbmV0d29yazsKCiAgIDMuICBUaGUg Y29udHJvbGxlciBjaG9vc2VzIHRoZSBvcHRpbWFsIHBhdGggYW5kIGNvbmZpZ3VyZXMgdGhlCiAg ICAgICBkZXZpY2VzIGFsb25nIHRoYXQgcGF0aCBmb3IgZmxvdyB0cmFuc21pc3Npb24gdmlhIFBD RS1DQy4KCjMuMy4gIEh5YnJpZCBDb250cm9sIFBsYW5lCgogICBJbiB0aGUgaHlicmlkIG1vZGVs LCBhIGNvbnRyb2xsZXIgYW5kIGNvbnRyb2wgcGxhbmUgcHJvdG9jb2xzIHdvcmsKICAgdG9nZXRo ZXIgdG8gcHJvdmlkZSBEZXROZXQgc2VydmljZXMsIGFuZCB0aGVyZSBhcmUgYSBudW1iZXIgb2YK ICAgcG9zc2libGUgY29tYmluYXRpb25zLiAgRm9yIGV4YW1wbGU6CgogICAxLiAgQSBDZW50cmFs aXplZCBDb250cm9sbGVyIGNvbGxlY3RzIHRvcG9sb2d5IGluZm9ybWF0aW9uIGFuZCBEZXROZXQK ICAgICAgIGNhcGFiaWxpdGllcyBvZiB0aGUgbmV0d29yayB2aWEgYW4gSUdQIGFuZC9vciBCR1At TFMgW1JGQzc3NTJdOwoKICAgMi4gIFRoZSBjb250cm9sbGVyIHJlY2VpdmVzIGEgZmxvdyBlc3Rh Ymxpc2htZW50IHJlcXVlc3QgZnJvbSBhIFVOSQogICAgICAgYW5kIGNhbGN1bGF0ZXMgb25lIG9y IG1vcmUgdmFsaWQgcGF0aChzKSB0aHJvdWdoIHRoZSBuZXR3b3JrOwoKICAgMy4gIEJhc2VkIG9u IHRoZSBjYWxjdWxhdGlvbiByZXN1bHQsIHRoZSBDTkMgZGlzdHJpYnV0ZXMgZmxvdyBwYXRoCiAg ICAgICBpbmZvcm1hdGlvbiB0byB0aGUgaW5ncmVzcyBlZGdlIG5vZGUgYW5kIG90aGVyIGluZm9y bWF0aW9uIChlLmcuCiAgICAgICByZXBsaWNhdGlvbi9kdXBsaWNhdGUgZWxpbWluYXRpb24pIHRv IHRoZSByZWxldmFudCBub2Rlcy4KCiAgIDQuICBVc2luZyBSU1ZQLVRFLCB0aGUgaW5ncmVzcyBl ZGdlIG5vZGUgc2VuZHMgYSBQQVRIIG1lc3NhZ2Ugd2l0aCBhbgogICAgICAgZXhwbGljaXQgcm91 dGUuICBBZnRlciByZWNlaXZpbmcgdGhlIFBBVEggbWVzc2FnZSwgdGhlIGVncmVzcwogICAgICAg ZWRnZSBub2RlIHNlbmRzIGEgUkVTViBtZXNzYWdlIHdpdGggdGhlIGRpc3RyaWJ1dGVkIGxhYmVs IGFuZAogICAgICAgcmVzb3VyY2UgcmVzZXJ2YXRpb24gcmVxdWVzdC4KCiAgIG9yCgogICAxLiAg VGhlIGNvbnRyb2xsZXIgY29sbGVjdHMgdG9wb2xvZ3kgaW5mb3JtYXRpb24gYW5kIERldE5ldAog ICAgICAgY2FwYWJpbGl0eSBvZiB0aGUgbmV0d29yayB2aWEgYW4gSUdQIG9yIEJHUC1MUzsKCiAg IDIuICBUaGUgY29udHJvbCBwbGFuZSBvZiB0aGUgaW5ncmVzcyBlZGdlIG5vZGUgcmVjZWl2ZXMg YSBmbG93CiAgICAgICBlc3RhYmxpc2htZW50IHJlcXVlc3QgdmlhIGEgVU5JOwoKICAgMy4gIFRo ZSBJbmdyZXNzIGVkZ2Ugbm9kZSBzZW5kcyB0aGUgcGF0aCBlc3RhYmxpc2htZW50IHJlcXVlc3Qg dG8gdGhlCiAgICAgICBjb250cm9sbGVyIHRocm91Z2ggUENFUCBbUkZDNTQ0MF07CgogICA0LiAg QWZ0ZXIgcGF0aCBjYWxjdWxhdGlvbiwgdGhlIENOQyBzZW5kcyB0aGUgcGF0aCBpbmZvcm1hdGlv biBvZiB0aGUKICAgICAgIGZsb3cgdG8gdGhlIGluZ3Jlc3MgZWRnZSBub2RlIHZpYSBQQ0VQOwoK ICAgNS4gIFVzaW5nIFJTVlAtVEUsIHRoZSBpbmdyZXNzIGVkZ2Ugbm9kZSBzZW5kcyBhIFBBVEgg bWVzc2FnZSB3aXRoIGFuCiAgICAgICBleHBsaWNpdCByb3V0ZS4gIEFmdGVyIHJlY2VpdmluZyB0 aGUgUEFUSCBtZXNzYWdlLCB0aGUgZWdyZXNzCiAgICAgICBlZGdlIG5vZGUgc2VuZHMgYSBSRVNW IG1lc3NhZ2Ugd2l0aCB0aGUgZGlzdHJpYnV0ZWQgbGFiZWwgYW5kCiAgICAgICByZXNvdXJjZSBy ZXNlcnZhdGlvbiByZXF1ZXN0LgoKCgpNYWxpcywgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEph bnVhcnkgMjUsIDIwMjAgICAgICAgICAgICAgICAgW1BhZ2UgN10KDApJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgRGV0TmV0IENvbnRyb2xsZXIgUGxhbmUgICAgICAgICAgICAgICBKdWx5IDIwMTkK CgogICBUaGVyZSBhcmUgbWFueSBvdGhlciB2YXJpYXRpb25zIHRoYXQgY291bGQgYmUgaW5jbHVk ZWQgaW4gYSBoeWJyaWQKICAgY29udHJvbCBwbGFuZS4gIFRoaXMgZG9jdW1lbnQgY2Fubm90IGRp c2N1c3MgYWxsIHRoZSBwb3NzaWJsZSBjb250cm9sCiAgIHBsYW5lIG1lY2hhbmlzbXMgdGhhdCBj b3VsZCBiZSB1c2VkIGluIGh5YnJpZCBjb25maWd1cmF0aW9uIG1vZGVscy4KICAgRXZlcnkgc29s dXRpb24gaGFzIGl0cyBvd24gbWVjaGFuaXNtcyBhbmQgY29ycmVzcG9uZGluZyBwYXJhbWV0ZXJz CiAgIHRoYXQgYXJlIHJlcXVpcmVkIGZvciBpdCB0byB3b3JrLgoKNC4gIERldE5ldCBDb250cm9s IFBsYW5lIEFkZGl0aW9uYWwgRGV0YWlscyBhbmQgSXNzdWVzCgogICBUaGlzIHNlY3Rpb24gZGlz Y3Vzc2VzIHNvbWUgYWRkaXRpb25hbCBEZXROZXQgY29udHJvbCBwbGFuZSBkZXRhaWxzCiAgIGFu ZCBpc3N1ZXMuCgo0LjEuICBFeHBsaWNpdCBQYXRocwoKICAgRXhwbGljaXQgcGF0aHMgYXJlIHJl cXVpcmVkIGluIERldE5ldCB0byBwcm92aWRlIGEgc3RhYmxlIHRyYW5zcG9ydAogICBzZXJ2aWNl IGFuZCBndWFyYW50ZWUgdGhhdCBEZXROZXQgc2VydmljZSBpcyBub3QgZWZmZWN0ZWQgd2hlbiB0 aGUKICAgbmV0d29yayB0b3BvbG9neSBjaGFuZ2VzLiAgVGhlIGZvbGxvd2luZyBmZWF0dXJlcyBh cmUgbmVjZXNzYXJ5IHRvCiAgIGhhdmUgZXhwbGljaXQgcGF0aHMgaW4gRGV0TmV0OgoKICAgbyAg UGF0aCBjb21wdXRhdGlvbjogRGV0TmV0IGV4cGxpY2l0IHBhdGhzIG5lZWQgdG8gbWVldCB0aGUg U0xBCiAgICAgIChTZXJ2aWNlIExldmVsIEFncmVlbWVudCkgcmVxdWlyZW1lbnRzIGFuZC9vciBy ZXNvdXJjZSBndWFyYW50ZWVzCiAgICAgIGZyb20gdGhlIGFwcGxpY2F0aW9uL2NsaWVudCwgd2hp Y2ggaW5jbHVkZSBiYW5kd2lkdGgsIG1heGltdW0gZW5kLQogICAgICB0by1lbmQgZGVsYXksIG1h eGltdW0gZW5kLXRvLWVuZCBkZWxheSB2YXJpYXRpb24sIG1heGltdW0gbG9zcwogICAgICByYXRp bywgZXRjLiAgSW4gYW4gZGlzdHJpYnV0ZWQgc3lzdGVtIHdpdGggSUdQLVRFLCBDU1BGCiAgICAg IChDb25zdHJhaW5lZCBTaG9ydGVzdCBQYXRoIEZpcnN0KSBjYW4gYmUgdXNlZCB0byBjb21wdXRl IGEgc2V0IG9mCiAgICAgIGZlYXNpYmxlIHBhdGhzIGZvciBhIERldE5ldCBzZXJ2aWNlLiAgSW4g YSBzeXN0ZW0gd2l0aCBhIG5ldHdvcmsKICAgICAgY29udHJvbGxlciwgYSBQQ0UgKFBhdGggQ29t cHV0YXRpb24gRW5naW5lKSBjYW4gY29tcHV0ZSBwYXRocwogICAgICBzYXRpc2Z5aW5nIHRoZSBy ZXF1aXJlbWVudHMgb2YgRGV0TmV0IHdpdGggdGhlIG5ldHdvcmsgaW5mb3JtYXRpb24KICAgICAg Y29sbGVjdGVkIGZyb20gdGhlIERldE5ldCBkb21haW4uCgogICBvICBQYXRoIGVzdGFibGlzaG1l bnQ6IE9uY2UgdGhlIHBhdGggaGFzIGJlZW4gY29tcHV0ZWQsIHRoZSBvcHRpb25zCiAgICAgIGRp c2N1c3NlZCBpbiBTZWN0aW9uIDMgY2FuIGJlIHVzZWQgdG8gZXN0YWJsaXNoIHRoZSBwYXRoLiAg QWxzbwogICAgICBzZWUgU2VjdGlvbiA0LjQgYW5kIFNlY3Rpb24gNC42IGZvciBzb21lIGFkZGl0 aW9uYWwgY29uc2lkZXJhdGlvbnMKICAgICAgZGVwZW5kaW5nIG9uIHRoZSBkZXRhaWxzIG9mIHRo ZSBuZXR3b3JrIGluZnJhc3RydWN0dXJlLgoKICAgbyAgU3RyaWN0IG9yIGxvb3NlIHBhdGhzOiBB biBleHBsaWNpdCBwYXRoIGlzIHN0cmljdCB3aGVuIGV2ZXJ5CiAgICAgIGludGVybWVkaWF0ZSBo b3AgaXMgc3BlY2lmaWVkIHNvIHRoYXQgaXRzIHJvdXRlIGNhbid0IGNoYW5nZS4gIEFuCiAgICAg IGV4cGxpY2l0IHBhdGggaXMgbG9vc2Ugd2hlbiBhbnkgSUdQIHJvdXRlIGlzIGFsbG93ZWQgYWxv bmcgdGhlCiAgICAgIHBhdGguICBHZW5lcmFsbHksIGVuZC10by1lbmQgU0xBIGd1YXJhbnRlZXMg cmVxdWlyZSBhIHN0cmljdAogICAgICBleHBsaWNpdCBwYXRoIGluIERldE5ldC4gIEhvd2V2ZXIs IHdoZW4gdGhlIElHUCByb3V0ZSBpcyBrbm93biB0bwogICAgICBiZSBhYmxlIHRvIG1lZXQgdGhl IFNMQSByZXF1aXJlbWVudHMsIGxvb3NlIGV4cGxpY2l0IHBhdGhzIGFyZQogICAgICBhbHNvIGFj Y2VwdGFibGUuCgo0LjIuICBSZXNvdXJjZSBSZXNlcnZhdGlvbgoKICAgTmV0d29yayBjb25nZXN0 aW9uIGNvdWxkIGNhdXNlIHVuY29udHJvbGxlZCBkZWxheSBhbmQvb3IgcGFja2V0IGxvc3MuCiAg IERldE5ldCBmbG93cyBhcmUgc3VwcG9zZWQgdG8gYmUgcHJvdGVjdGVkIGZyb20gY29uZ2VzdGlv biwgc28KICAgc3VmZmljaWVudCByZXNvdXJjZSByZXNlcnZhdGlvbiBmb3IgRGV0TmV0IHNlcnZp Y2UgaXMgbmVjZXNzYXJ5LgogICBSZXNvdXJjZXMgaW4gdGhlIG5ldHdvcmsgYXJlIGNvbXBsZXgg YW5kIGhhcmQgdG8gcXVhbnRpemUsIGFuZCBtYXkKCgoKTWFsaXMsIGV0IGFsLiAgICAgICAgICAg RXhwaXJlcyBKYW51YXJ5IDI1LCAyMDIwICAgICAgICAgICAgICAgIFtQYWdlIDhdCgwKSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgIERldE5ldCBDb250cm9sbGVyIFBsYW5lICAgICAgICAgICAgICAg SnVseSAyMDE5CgoKICAgaW5jbHVkZSBzdWNoIGVudGl0aWVzIGFzIHBhY2tldCBwcm9jZXNzaW5n IHJlc291cmNlcywgcGFja2V0CiAgIGJ1ZmZlcmluZywgcG9ydCBhbmQgbGluayBiYW5kd2lkdGgs IGFuZCBzbyBvbi4gIFRoZSByZXNvdXJjZXMgYQogICBwYXJ0aWN1bGFyIGZsb3cgcmVxdWlyZXMg YXJlIGRldGVybWluZWQgYnkgdGhlIGZsb3cncyBjaGFyYWN0ZXJpc3RpY3MKICAgYW5kIFNMQS4K CiAgIG8gIFJlc291cmNlIEFsbG9jYXRpb246IFBvcnQgYmFuZHdpZHRoIGlzIG9uZSBvZiB0aGUg YmFzaWMgYXR0cmlidXRlcwogICAgICBvZiBhIG5ldHdvcmsgZGV2aWNlIHdoaWNoIGlzIGVhc3kg dG8gb2J0YWluIG9yIGNhbGN1bGF0ZS4gIEluCiAgICAgIGN1cnJlbnQgdHJhZmZpYyBlbmdpbmVl cmluZyBpbXBsZW1lbnRhdGlvbnMsIG5ldHdvcmsgcmVzb3VyY2UKICAgICAgYWxsb2NhdGlvbiBp cyBzeW5vbnltb3VzIHdpdGggYmFuZHdpZHRoIGFsbG9jYXRpb24uICBBIERldE5ldCBmbG93CiAg ICAgIGlzIGNoYXJhY3Rlcml6ZWQgd2l0aCBhIHRyYWZmaWMgc3BlY2lmaWNhdGlvbiBhcyBkZWZp bmVkIGluCiAgICAgIFtJLUQuaWV0Zi1kZXRuZXQtZmxvdy1pbmZvcm1hdGlvbi1tb2RlbF0sIGlu Y2x1ZGluZyBhdHRyaWJ1dGVzCiAgICAgIHN1Y2ggYXMgSW50ZXJ2YWwsIE1heGltdW0gUGFja2V0 cyBQZXIgSW50ZXJ2YWwsIGFuZCBNYXhpbXVtCiAgICAgIFBheWxvYWQgU2l6ZS4gIFRoZSB0cmFm ZmljIHNwZWNpZmljYXRpb24gZGVzY3JpYmVzIHRoZSB3b3JzdCBjYXNlLAogICAgICByYXRoZXIg dGhhbiB0aGUgYXZlcmFnZSBjYXNlLCBmb3IgdGhlIHRyYWZmaWMsIHRvIGVuc3VyZSB0aGF0CiAg ICAgIHN1ZmZpY2llbnQgYmFuZHdpZHRoIGFuZCBidWZmZXJpbmcgcmVzb3VyY2VzIGFyZSByZXNl cnZlZCB0bwogICAgICBzYXRpc2Z5IHRoZSB0cmFmZmljIHNwZWNpZmljYXRpb24uCgogICBvICBE ZXZpY2UgY29uZmlndXJhdGlvbiB3aXRoIG9yIHdpdGhvdXQgZmxvdyBkaXNjcmltaW5hdGlvbjog VGhlCiAgICAgIHJlc291cmNlIGFsbG9jYXRpb24gY2FuIGJlIGd1YXJhbnRlZWQgYnkgZGV2aWNl IGNvbmZpZ3VyYXRpb24uCiAgICAgIEZvciBleGFtcGxlLCBhbiBvdXRwdXQgcG9ydCBiYW5kd2lk dGggcmVzZXJ2YXRpb24gY2FuIGJlCiAgICAgIGNvbmZpZ3VyZWQgYXMgYSBwYXJhbWV0ZXIgb2Yg cXVldWUgbWFuYWdlbWVudCBhbmQgdGhlIHBvcnQKICAgICAgc2NoZWR1bGluZyBhbGdvcml0aG0u ICBXaGVuIERldE5ldCBmbG93cyBhcmUgYWdncmVnYXRlZCwgYSBncm91cAogICAgICBvZiBEZXRO ZXQgZmxvd3Mgc2hhcmUgdGhlIGFsbG9jYXRlZCByZXNvdXJjZSBpbiB0aGUgbmV0d29yawogICAg ICBkZXZpY2UuICBXaGVuIHRoZSBEZXROZXQgZmxvd3MgYXJlIHRyZWF0ZWQgaW5kZXBlbmRlbnRs eSwgdGhlCiAgICAgIGRldmljZSBzaG91bGQgbWFpbnRhaW5zIGEgbWFwcGluZyByZWxhdGlvbnNo aXAgYmV0d2VlbiBhIERldE5ldAogICAgICBmbG93IGFuZCBpdHMgY29ycmVzcG9uZGluZyByZXNv dXJjZXMuCgo0LjMuICBQUkVPRiBTdXBwb3J0CgogICBEZXROZXQgcGF0aCByZWR1bmRhbmN5IGlz IHN1cHBvcnRlZCB2aWEgcGFja2V0IHJlcGxpY2F0aW9uIGFuZAogICBkdXBsaWNhdGUgZWxpbWlu YXRpb24gKFBSRU9GKS4gIEEgRGV0TmV0IGZsb3cgaXMgcmVwbGljYXRlZCBhbmQgZ29lcwogICB0 aHJvdWdoIG11bHRpcGxlIG5ldHdvcmtzIHBhdGhzIHRvIGF2b2lkIHBhY2tldCBsb3NzIGNhdXNl ZCBieSBkZXZpY2UKICAgb3IgbGluayBmYWlsdXJlcy4gIEluIGdlbmVyYWwsIGN1cnJlbnQgY29u dHJvbCBwbGFuZSBtZWNoYW5pc21zIHRoYXQKICAgY2FuIGJlIHVzZWQgdG8gZXN0YWJsaXNoIGFu IGV4cGxpY2l0IHBhdGgsIHdoZXRoZXIgZGlzdHJpYnV0ZWQgb3IKICAgY2VudHJhbGl6ZWQsIHN1 cHBvcnQgcG9pbnQtdG8tcG9pbnQgKFAyUCkgYW5kIHBvaW50LXRvLW11bHRpcG9pbnQKICAgKFAy TVApIHBhdGggZXN0YWJsaXNobWVudC4gIFBSRU9GIHJlcXVpcmVzIHRoZSBhYmlsaXR5IHRvIGNv bXB1dGUgYW5kCiAgIGVzdGFibGlzaCBhIHBvaW50LXRvLW11bHRpcG9pbnQtdG8tcG9pbnQgKFAy TVAyUCkgcGF0aC4gIFByb3RvY29sCiAgIGV4dGVuc2lvbnMgd2lsbCBiZSByZXF1aXJlZCB0byBz dXBwb3J0IHRoaXMgbmV3IGZlYXR1cmUuCgo0LjQuICBEZXROZXQgaW4gYSBUcmFkaXRpb25hbCBN UExTIERvbWFpbgoKICAgRm9yIHRoZSBwdXJwb3NlcyBvZiB0aGlzIGRvY3VtZW50LCAidHJhZGl0 aW9uYWwgTVBMUyIgaXMgZGVmaW5lZCBhcwogICBNUExTIHdpdGhvdXQgdGhlIHVzZSBvZiBzZWdt ZW50IHJvdXRpbmcgKHNlZSBTZWN0aW9uIDQuNiBmb3IgYQogICBkaXNjdXNzaW9uIG9mIE1QTFMg d2l0aCBzZWdtZW50IHJvdXRpbmcpIG9yIE1QTFMtVFAgW1JGQzU5NjBdLgoKICAgSW4gdHJhZGl0 aW9uYWwgTVBMUyBkb21haW5zLCBhIGR5bmFtaWMgY29udHJvbCBwbGFuZSB1c2luZwogICBkaXN0 cmlidXRlZCBzaWduYWxpbmcgcHJvdG9jb2xzIGlzIHR5cGljYWxseSB1c2VkIGZvciB0aGUKICAg ZGlzdHJpYnV0aW9uIG9mIE1QTFMgbGFiZWxzIHVzZWQgZm9yIGZvcndhcmRpbmcgTVBMUyBwYWNr ZXRzLiAgVGhlCgoKCk1hbGlzLCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSAyNSwg MjAyMCAgICAgICAgICAgICAgICBbUGFnZSA5XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICBE ZXROZXQgQ29udHJvbGxlciBQbGFuZSAgICAgICAgICAgICAgIEp1bHkgMjAxOQoKCiAgIGR5bmFt aWMgc2lnbmFsaW5nIHByb3RvY29scyBtb3N0IGNvbW1vbmx5IHVzZWQgZm9yIGxhYmVsIGRpc3Ry aWJ1dGlvbgogICBhcmUgTERQIFtSRkM1MDM2XSwgUlNWUC1URSwgYW5kIEJHUCBbUkZDODI3N10g KHdoaWNoIGVuYWJsZXMgQkdQLwogICBNUExTLWJhc2VkIExheWVyIDMgVlBOcyBbUkZDNDM4NF0g YW5kIExheWVyIDIgVlBOcyBbUkZDNzQzMl0pLgoKICAgQW55IG9mIHRoZXNlIHByb3RvY29scyBj b3VsZCBiZSB1c2VkIHRvIGRpc3RyaWJ1dGUgRGV0TmV0IFNlcnZpY2UKICAgTGFiZWxzIChTLUxh YmVscykgYW5kIEFnZ3JlZ2F0aW9uIExhYmVscwogICAoQS1MYWJlbHMpW0ktRC5pZXRmLWRldG5l dC1tcGxzXS4gIEFzIGRpc2N1c3NlZCBpbgogICBbSS1ELmlldGYtZGV0bmV0LWRhdGEtcGxhbmUt ZnJhbWV3b3JrXSwgUy1MYWJlbHMgYXJlIHNpbWlsYXIgdG8gb3RoZXIKICAgTVBMUyBzZXJ2aWNl IGxhYmVscywgc3VjaCBhcyBwc2V1ZG93aXJlLCBMMyBWUE4sIGFuZCBMMiBWUE4gbGFiZWxzLAog ICBhbmQgY291bGQgYmUgZGlzdHJpYnV0ZWQgaW4gYSBzaW1pbGFyIG1hbm5lciwgc3VjaCBhcyB0 aHJvdWdoIHRoZSB1c2UKICAgb2YgdGFyZ2V0ZWQgTERQIG9yIEJHUC4gIElmIHRoZXNlIHdlcmUg dG8gYmUgdXNlZCBmb3IgRGV0TmV0LCB0aGV5CiAgIHdvdWxkIHJlcXVpcmUgZXh0ZW5zaW9ucyB0 byBzdXBwb3J0IERldE5ldC1zcGVjaWZpYyBmZWF0dXJlcyBzdWNoIGFzCiAgIFBSRU9GLCBhZ2dy ZWdhdGlvbiAoQS1MYWJlbHMpLCBub2RlIHJlc291cmNlIGFsbG9jYXRpb24sIGFuZCBxdWV1ZQog ICBwbGFjZW1lbnQuCgogICBIb3dldmVyLCBhcyBkaXNjdXNzZWQgaW4gU2VjdGlvbiAzLjEsIGRp c3RyaWJ1dGVkIHNpZ25hbGluZyBwcm90b2NvbHMKICAgbWF5IGhhdmUgZGlmZmljdWx0eSBtZWV0 aW5nIERldE5ldCdzIHNjYWxhYmlsaXR5IHJlcXVpcmVtZW50cy4gIE1QTFMKICAgYWxzbyBhbGxv d3MgU0ROLWxpa2UgY2VudHJhbGl6ZWQgbGFiZWwgbWFuYWdlbWVudCBhbmQgZGlzdHJpYnV0aW9u IGFzCiAgIGFuIGFsdGVybmF0aXZlIHRvIGRpc3RyaWJ1dGVkIHNpZ25hbGluZyBwcm90b2NvbHMs IHVzaW5nIHByb3RvY29scwogICBzdWNoIGFzIFBDRVAgYW5kIE9wZW5GbG93IFtPUEVORkxPV10u CgogICBQQ0VQLCBwYXJ0aWN1bGFybHkgd2hlbiB1c2VkIGFzIGEgcGFydCBvZiBQQ0UtQ0MsIGlz IGEgcG9zc2libGUKICAgY2FuZGlkYXRlIHByb3RvY29sIHRvIHVzZSBmb3IgY2VudHJhbGl6ZWQg bWFuYWdlbWVudCBvZiB0cmFkaXRpb25hbAogICBNUExTLWJhc2VkIERldE5ldCBkb21haW5zLiAg SG93ZXZlciwgUENFIHBhdGggY2FsY3VsYXRpb24gYWxnb3JpdGhtcwogICB3b3VsZCBuZWVkIHRv IGJlIGV4dGVuZGVkIHRvIGluY2x1ZGUgdGhlIGxvY2F0aW9uIGRldGVybWluYXRpb24gZm9yCiAg IFBSRU9GIG5vZGVzIGluIGEgcGF0aCwgYW5kIHRoZSBtZWFucyB0byBzaWduYWwgdGhlIG5lY2Vz c2FyeSByZXNvdXJjZQogICByZXNlcnZhdGlvbiBhbmQgUFJFT0YgZnVuY3Rpb24gcGxhY2VtZW50 IGluZm9ybWF0aW9uIHRvIG5ldHdvcmsKICAgbm9kZXMuICBTZWUgKCg/SS1ELmlldGYtcGNlLXBj ZXAtZXh0ZW5zaW9uLWZvci1wY2UtY29udHJvbGxlcikpIGZvcgogICBmdXJ0aGVyIGRpc2N1c3Np b24gb2YgUENFLUNDIGFuZCBQQ0VQIGZvciBjZW50cmFsaXplZCBjb250cm9sIG9mIGFuCiAgIE1Q TFMgZG9tYWluLgoKNC41LiAgSVAKCiAgIEluIGEgbGF0ZXIgcmV2aXNpb24gb2YgdGhpcyBkb2N1 bWVudCwgdGhpcyBzZWN0aW9uIHdpbGwgZGlzY3VzcwogICBuZWNlc3NhcnkgcHJvdG9jb2wgZXh0 ZW5zaW9ucyB0byBleGlzdGluZyBJUCByb3V0aW5nIHByb3RvY29scyBzdWNoCiAgIGFzIElTLUlT IGFuZCBCR1AuICBJdCBzaG91bGQgYmUgbm90ZWQgdGhhdCBhIERldE5ldCBJUCBkb21haW4gaXMK ICAgc2ltcGxlciB0aGFuIGEgRGV0TmV0IE1QTFMgZG9tYWluLCBhbmQgZG9lc24ndCBzdXBwb3J0 IFBSRU9GLCBzbyBvbmx5CiAgIG9uZSBwYXRoIHBlciBmbG93IG9yIGZsb3cgYWdncmVnYXRlIGlz IHJlcXVpcmVkLCB3aXRoIG5vIHBhdGgKICAgbWVyZ2luZy4KCjQuNi4gIERldE5ldCB3aXRoIFNl Z21lbnQgUm91dGluZyAoU1IpCgogICBTZWdtZW50IFJvdXRpbmcgW1JGQzg0MDJdIGlzIGEgc2Nh bGFibGUgYXBwcm9hY2ggdG8gYnVpbGRpbmcgbmV0d29yawogICBkb21haW5zIHRoYXQgdXRpbGl6 ZXMgYSBjb21iaW5hdGlvbiBvZiBzb3VyY2Ugcm91dGluZyBpbiBwYWNrZXQKICAgaGVhZGVycyBh bmQgY2VudHJhbGl6ZWQgbmV0d29yayBjb250cm9sIHRvIGNvbXB1dGUgcGF0aHMgdGhyb3VnaCB0 aGUKICAgbmV0d29yayBhbmQgZGlzdHJpYnV0ZSB0aG9zZSBwYXRocyB3aXRoIGFzc29jaWF0ZWQg cG9saWN5IHRvIG5ldHdvcmsKICAgZWRnZSBub2RlcyBmb3IgdXNlIGluIHBhY2tldCBoZWFkZXJz LiAgSXQgZ3JlYXRseSByZWR1Y2VzIHRoZSBhbW91bnQKICAgb2YgbmV0d29yayBzaWduYWxpbmcg YXNzb2NpYXRlZCB3aXRoIGRpc3RyaWJ1dGVkIHNpZ25hbGluZyBwcm90b2NvbHMKCgoKTWFsaXMs IGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDI1LCAyMDIwICAgICAgICAgICAgICAg W1BhZ2UgMTBdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgIERldE5ldCBDb250cm9sbGVyIFBs YW5lICAgICAgICAgICAgICAgSnVseSAyMDE5CgoKICAgc3VjaCBhcyBSU1ZQLVRFLCBhbmQgYWxz byBncmVhdGx5IHJlZHVjZXMgdGhlIGFtb3VudCBvZiBzdGF0ZSBpbiBjb3JlCiAgIG5vZGVzIGNv bXBhcmVkIHdpdGggdGhhdCByZXF1aXJlZCBmb3IgdHJhZGl0aW9uYWwgTVBMUyBhbmQgSVAKICAg cm91dGluZywgYXMgdGhlIHN0YXRlIGlzIG5vdyBpbiB0aGUgcGFja2V0cyByYXRoZXIgdGhhbiBp biB0aGUKICAgcm91dGVycy4gIFRoaXMgaXMgZXNwZWNpYWxseSB1c2VmdWwgZm9yIERldE5ldCwg d2hlcmUgYSB2ZXJ5IGxhcmdlCiAgIG51bWJlciBvZiBmbG93cyB0aHJvdWdoIGEgbmV0d29yayBk b21haW4gYXJlIGV4cGVjdGVkLCB3aGljaCB3b3VsZAogICBvdGhlcndpc2UgcmVxdWlyZSB0aGUg aW5zdGFudGlhdGlvbiBvZiBzdGF0ZSBmb3IgZWFjaCBmbG93IHRyYXZlcnNpbmcKICAgZWFjaCBu b2RlIGluIHRoZSBuZXR3b3JrLgoKICAgVGhlIERldE5ldCBNUExTIGFuZCBJUCBkYXRhIHBsYW5l cyB3ZXJlIHNwZWNpZmljYWxseSBjb25zdHJ1Y3RlZCB0bwogICBhbGxvdyB0aGUgdXNlIG9mIERl dE5ldCB3aXRoIGJvdGggdHlwZXMgb2Ygc2VnbWVudCByb3V0aW5nLCBTUi1NUExTCiAgIFtJLUQu aWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW1wbHNdIGFuZCBTUnY2CiAgIFtJLUQuaWV0Zi02 bWFuLXNlZ21lbnQtcm91dGluZy1oZWFkZXJdLgoKICAgSW4gdGhlIERldE5ldCBjb250ZXh0LCBE ZXROZXQgaW4gYW4gU1ItTVBMUyBvciBTUnY2IGRhdGEgcGxhbmUgY291bGQKICAgYmUgdXNlZCBp biBjb25qdW5jdGlvbiB3aXRoIGNlbnRyYWxpemVkIGZsb3cgbWFuYWdlbWVudCBhbmQgY29tcGxl dGUKICAgbGFiZWwgc3RhY2sgZGlzdHJpYnV0aW9uIHRvIERldG5ldCBkb21haW4gZW50cnkgbm9k ZXMgdmlhIGEKICAgY2VudHJhbGl6ZWQgY29udHJvbGxlci4gIEV4dGVuc2lvbnMgdG8gUENFUCB0 byBhbGxvdyB0aGUgdXNlIG9mIFBDRS0KICAgQ0Mgd2l0aCBTUi1NUExTCgogICBPbmUgcG9zc2li bGUgYXJjaGl0ZWN0dXJlIGlzIFBDRS1DQyBjb21iaW5lZCB3aXRoIFNSLU1QTFMgb3IgU1J2Ni4K ICAgRXh0ZW5zaW9ucyB0byBQQ0VQIHRvIGFsbG93IHRoZSB1c2Ugb2YgUENFLUNDIHdpdGggU1It TVBMUyBhcmUKICAgZGVzY3JpYmVkIGluIFtJLUQuemhhby1wY2UtcGNlcC1leHRlbnNpb24tcGNl LWNvbnRyb2xsZXItc3JdLCB3aXRoCiAgIFNSdjYgaW4gW0ktRC5kaG9keS1wY2UtcGNlcC1leHRl bnNpb24tcGNlLWNvbnRyb2xsZXItc3J2Nl0uCgogICBUaGlzIGFwcHJvYWNoIHdvdWxkIGFsbG93 IHRoZSBkZXRhaWxzIG9mIHBhY2tldCBvciBmbG93IHRyZWF0bWVudCB0bwogICBiZSBlbmNvZGVk IGRpcmVjdGx5IGluIHRoZSBTSURzIG9uIGVhY2ggcGFja2V0IGluIGEgZmxvdyB0byByZWR1Y2UK ICAgdGhlIGFtb3VudCBvZiBzdGF0ZSBpbiBuZXR3b3JrIG5vZGVzLiAgVGhpcyBhcHByb2FjaCBh bHNvIGFsbG93cyB0aGUKICAgaW50ZWdyYXRpb24gb2YgRGV0TmV0IGRvbWFpbnMgd2l0aCBnZW5l cmFsIFNSLWJhc2VkIGJhY2tib25lIG5ldHdvcmtzCiAgIGluIGEgY29udmVyZ2VkIGRvbWFpbi4g IEluIHRoaXMgYXBwcm9hY2gsIGEgbmV3IHNldCBvZiBmdW5jdGlvbnMgZm9yCiAgIERldE5ldCBx dWV1aW5nIHRyZWF0bWVudHMgYXZhaWxhYmxlIGluIHRoZSBEZXROZXQgZG9tYWluIHdvdWxkIG5l ZWQKICAgdG8gYmUgZGVmaW5lZCBmb3IgaW5jbHVzaW9uIGluIHRoZSBTUiBzdGFjay4KCiAgIFRo aXMgaXMgbm90IHRoZSBvbmx5IHBvc3NpYmxlIGFwcHJvYWNoLiAgVGhlcmUgaXMgb25nb2luZyB3 b3JrIG9uIGEKICAgbnVtYmVyIG9mIGFsdGVybmF0aXZlIHNpZ25hbGluZyBtZWNoYW5pc21zIGZv ciBNUExTLVNSIGFuZCBTUnY2LAogICBpbmNsdWRpbmcgZXh0ZW5zaW9ucyB0byBJR1BzIGFuZCBC R1AgdG8gc3VwcG9ydCBkaXN0cmlidXRlZAogICBzaWduYWxpbmcuICBJbiBhZGRpdGlvbiwgQkdQ LUxTIGFuZCBCR1Agcm91dGUgcmVmbGVjdG9ycyBjb3VsZCBiZQogICBhZGRlZCBmb3IgYSBoeWJy aWQgc29sdXRpb24uCgogICBBIHBvc3NpYmxlIG1vc3RseSBjZW50cmFsaXplZCBoeWJyaWQgYXBw cm9hY2ggY291bGQgYmUgdG8gdXNlIGEgUENFLQogICBDQyB0byBwdXNoIHBhdGhzIHJlcHJlc2Vu dGVkIGJ5IFNJRCBsaXN0cyB3aGlsZSB1c2luZyBCR1AtTFMgdG8KICAgY29sbGVjdCBuZXR3b3Jr IHRvcG9sb2d5IGFuZCBsaW5rIHN0YXRlIGluZm9ybWF0aW9uLiAgQW4gSUdQIGlzIHVzZWQKICAg Zm9yIHRoZSB1c3VhbCBsaW5rIHN0YXRlIGZsb29kaW5nIGluIG9yZGVyIHRvIGVzdGFibGlzaCBh ZGphY2VuY2llcywKICAgYnV0IG5vdCBmb3IgRGV0TmV0IGZsb3cgcGF0aCBjYWxjdWxhdGlvbnMs IG9ubHkgZm9yIGJlc3QgZWZmb3J0CiAgIHRyYWZmaWMgYXMgdXN1YWwuCgogICBBIHNpbWlsYXIg YXBwcm9hY2ggZm9yIG5ldHdvcmsgc2xpY2luZyB0aGF0IGNvdWxkIGJlIGxldmVyYWdlZCBmb3IK ICAgRGV0TmV0IGlzIGRlc2NyaWJlZCBpbiBbSS1ELmRvbmctc3ByaW5nLXNyLWZvci1lbmhhbmNl ZC12cG5dLgoKCgoKTWFsaXMsIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDI1LCAy MDIwICAgICAgICAgICAgICAgW1BhZ2UgMTFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgIERl dE5ldCBDb250cm9sbGVyIFBsYW5lICAgICAgICAgICAgICAgSnVseSAyMDE5CgoKICAgQWxzbywg bm90ZSB0aGF0IFNSIGNhbm5vdCBjdXJyZW50bHkgc3VwcG9ydCBEZXROZXQgUFJFT0YKICAgZnVu Y3Rpb25hbGl0eSB3aXRob3V0IGV4dGVuc2lvbnMuICBPbmUgcG9zc2libGUgYXBwcm9hY2ggY291 bGQgYmUgdG8KICAgY29tYmluZSBTUiB3aXRoIEJJRVItVEUsIGFzIGRpc2N1c3NlZCBpbiBbSS1E LmlldGYtYmllci10ZS1hcmNoXS4KICAgQW5vdGhlciBwb3NzaWJsZSBhcHByb2FjaCBzcGVjaWZp YyB0byBTUnY2IGlzIGRpc2N1c3NlZCBpbgogICBbSS1ELmdlbmctZGV0bmV0LWRwLXNvbC1zcnY2 XS4KCjUuICBNYW5hZ2VtZW50IFBsYW5lIE92ZXJ2aWV3CgogICBUaGUgTWFuYWdlbWVudCBQbGFu ZSBpbmNsdWRlcyB0aGUgYWJpbGl0eSB0byBzdGF0aWNhbGx5IHByb3Zpc2lvbgogICBuZXR3b3Jr IG5vZGVzIGFuZCB0byB1c2UgT0FNIHRvIG1vbml0b3IgRGV0TmV0IHBlcmZvcm1hbmNlIGFuZCBk ZXRlY3QKICAgb3V0YWdlcyBvciBvdGhlciBpc3N1ZXMgYXQgdGhlIERldE5ldCBsYXllci4KCjUu MS4gIFByb3Zpc2lvbmluZwoKICAgU3RhdGljIHByb3Zpc2lvbmluZyBpbiBhIERldG5ldCBuZXR3 b3JrIHdpbGwgYmUgcGVyZm9ybWVkIHZpYSB0aGUgdXNlCiAgIG9mIGFwcHJvcHJpYXRlIFlBTkcg bW9kZWxzLCBpbmNsdWRpbmcgW0ktRC5pZXRmLWRldG5ldC15YW5nXSBhbmQKICAgW0ktRC5pZXRm LWRldG5ldC10b3BvbG9neS15YW5nXS4KCjUuMi4gIERldE5ldCBPcGVyYXRpb25zLCBBZG1pbmlz dHJhdGlvbiBhbmQgTWFpbnRlbmFuY2UgKE9BTSkKCiAgIFRoZSBvdmVyYWxsIGZyYW1ld29yayBh bmQgcmVxdWlyZW1lbnRzIGZvciBEZXROZXQgT0FNIGFyZSBkaXNjdXNzZWQKICAgaW4gW0ktRC5t aXJza3ktZGV0bmV0LW9hbV0uICBUaGlzIGRvY3VtZW50IGN1cnJlbnRseSBpbmNsdWRlcwogICBh ZGRpdGlvbmFsIE9BTSBkZXRhaWxzIHRoYXQgbWF5IGV2ZW50dWFsbHkgYmUgbWVyZ2VkIGludG8g dGhhdAogICBkb2N1bWVudC4KCjUuMi4xLiAgT0FNIGZvciBQZXJmb3JtYW5jZSBNb25pdG9yaW5n IChQTSkKCjUuMi4xLjEuICBBY3RpdmUgUE0KCiAgIEFjdGl2ZSBQTSBpcyBwZXJmb3JtZWQgYnkg aW5qZWN0aW5nIE9BTSBwYWNrZXRzIGludG8gdGhlIG5ldHdvcmsgdG8KICAgZXN0aW1hdGUgdGhl IHBlcmZvcm1hbmNlIG9mIHRoZSBuZXR3b3JrIGJ5IG1lYXN1cmluZyB0aGUgcGVyZm9ybWFuY2UK ICAgb2YgdGhlIE9BTSBwYWNrZXRzLiAgQWRkaW5nIGV4dHJhIHRyYWZmaWMgY2FuIGFmZmVjdCB0 aGUgZGVsYXkgYW5kCiAgIHRocm91Z2hwdXQgcGVyZm9ybWFuY2Ugb2YgdGhlIG5ldHdvcmssIGFu ZCBmb3IgdGhpcyByZWFzb24gYWN0aXZlIFBNCiAgIGlzIG5vdCByZWNvbW1lbmRlZCBmb3IgdXNl IGluIG9wZXJhdGlvbmFsIERldE5ldCBkb21haW5zLiAgSG93ZXZlciwKICAgaXQgaXMgYSB1c2Vm dWwgdGVzdCB0b29sIHdoZW4gY29tbWlzc2lvbmluZyBhIG5ldyBuZXR3b3JrLgoKNS4yLjEuMi4g IFBhc3NpdmUgUE0KCiAgIFBhc3NpdmUgUE0gbW9uaXRvcnMgdGhlIGFjdHVhbCBzZXJ2aWNlIHRy YWZmaWMgaW4gYSBuZXR3b3JrIGRvbWFpbiBpbgogICBvcmRlciB0byBtZWFzdXJlIGl0cyBwZXJm b3JtYW5jZSB3aXRob3V0IGhhdmluZyBhIGRldHJpbWVudGFsIGFmZmVjdAogICBvbiB0aGUgbmV0 d29yay4gIEFzIGNvbXBhcmVkIHRvIEFjdGl2ZSBQTSwgUGFzc2l2ZSBQTSBpcyBtdWNoCiAgIHBy ZWZlcnJlZCBmb3IgdXNlIGluIERldE5ldCBkb21haW5zLgoKICAgQSBwcm9wb3NhbCBmb3IgRGV0 TmV0IHBhc3NpdmUgcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnQgaXMgY29udGFpbmVkIGluCiAgIFtJ LUQuY2hlbi1kZXRuZXQtbG9zcy1kZWxheV0uCgoKCgoKCk1hbGlzLCBldCBhbC4gICAgICAgICAg IEV4cGlyZXMgSmFudWFyeSAyNSwgMjAyMCAgICAgICAgICAgICAgIFtQYWdlIDEyXQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgICBEZXROZXQgQ29udHJvbGxlciBQbGFuZSAgICAgICAgICAgICAg IEp1bHkgMjAxOQoKCjUuMi4yLiAgT0FNIGZvciBGYXVsdC9EZWZlY3QgTWFuYWdlbWVudCAoRk0p CgogICBbSS1ELm1pcnNreS1kZXRuZXQtb2FtXSBjb250YWlucyByZXF1aXJlbWVudHMgZm9yIGZh dWx0L2RlZmVjdAogICBkZXRlY3Rpb24gYW5kIG1hbmFnZW1lbnQgaW4gYSBEZXROZXQgZG9tYWlu LgoKNi4gIElBTkEgQ29uc2lkZXJhdGlvbnMKCiAgIFRoaXMgZG9jdW1lbnQgaGFzIG5vIGFjdGlv bnMgZm9yIElBTkEuCgogICBOb3RlIHRvIFJGQyBFZGl0b3I6IHRoaXMgc2VjdGlvbiBtYXkgYmUg cmVtb3ZlZCBvbiBwdWJsaWNhdGlvbiBhcyBhbgogICBSRkMuCgo3LiAgU2VjdXJpdHkgQ29uc2lk ZXJhdGlvbnMKCiAgIFRoZSBvdmVyYWxsIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIG9mIERldE5l dCBhcmUgZGlzY3Vzc2VkIGluCiAgIFtJLUQuaWV0Zi1kZXRuZXQtYXJjaGl0ZWN0dXJlXSBhbmQg W0ktRC5pZXRmLWRldG5ldC1zZWN1cml0eV0uICBGb3IKICAgRGV0TmV0IG5ldHdvcmtzIHRoYXQg bWFrZSB1c2Ugb2YgU2VnbWVudCBSb3V0aW5nICh3aGV0aGVyIFNSLU1QTFMgb3IKICAgU1J2Niks IHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBpbiBbUkZDODQwMl0gYWxzbyBhcHBseS4KCiAg IERldE5ldCBuZXR3b3JrcyB0aGF0IG1ha2UgdXNlIG9mIGEgY2VudHJhbGl6ZWQgY29udHJvbGxl ciBwbGFuZSBtYXkKICAgYmUgdGhyZWF0ZW5lZCBieSB0aGUgbG9zcyBvZiBjb25uZWN0aXZpdHkg KHdoZXRoZXIgYWNjaWRlbnRhbCBvcgogICBtYWxpY2lvdXMpIGJldHdlZW4gdGhlIGNlbnRyYWwg Y29udHJvbGxlciBhbmQgdGhlIG5ldHdvcmsgbm9kZXMsIGFuZC8KICAgb3IgdGhlIHNwb29maW5n IG9mIGNvbnRyb2wgbWVzc2FnZXMgZnJvbSB0aGUgY29udHJvbGxlciB0byB0aGUKICAgbmV0d29y ayBub2Rlcy4gIFRoaXMgaXMgaW1wb3J0YW50IHNpbmNlIHN1Y2ggbmV0d29ya3MgZGVwZW5kIG9u CiAgIGNlbnRyYWxpemVkIGNvbnRyb2xsZXJzIHRvIGNhbGN1bGF0ZSBmbG93IHBhdGhzIGFuZCBp bnN0YW50aWF0ZSBmbG93CiAgIHN0YXRlIGluIHRoZSBuZXR3b3JrIG5vZGVzLiAgRm9yIG5ldHdv cmtzIHRoYXQgdXNlIGJvdGggRGV0TmV0IGFuZAogICBTZWdtZW50IFJvdXRpbmcgd2l0aCBhIGNl bnRyYWxpemVkIGNvbnRyb2xsZXIsIHRoaXMgd291bGQgYWxzbwogICBpbmNsdWRlIHRoZSBjYWxj dWxhdGlvbiBvZiBTSUQgbGlzdHMgYW5kIHRoZWlyIGluc3RhbGxhdGlvbiBpbiBlZGdlLwogICBi b3JkZXIgcm91dGVycy4KCiAgIEluIGJvdGggY2FzZXMsIHN1Y2ggdGhyZWF0cyBtYXkgYmUgbWl0 aWdhdGVkIHRocm91Z2ggcmVkdW5kYW50CiAgIGNvbnRyb2xsZXJzLCB0aGUgdXNlIG9mIGF1dGhl bnRpY2F0aW9uIGJldHdlZW4gdGhlIGNvbnRyb2xsZXIocykgYW5kCiAgIHRoZSBuZXR3b3JrIG5v ZGVzLCBhbmQgb3RoZXIgbWVjaGFuaXNtcyBmb3IgcHJvdGVjdGlvbiBhZ2FpbnN0IERPUwogICBh dHRhY2tzLiAgQSBtZWNoYW5pc20gZm9yIHN1cHBvcnRpbmcgb25lIG9yIG1vcmUgYWx0ZXJuYXRp dmUgY2VudHJhbAogICBjb250cm9sbGVycyBhbmQgdGhlIGFiaWxpdHkgdG8gZmFpbCBvdmVyIHRv IHN1Y2ggYW4gYWx0ZXJuYXRpdmUKICAgY29udHJvbGxlciB3aWxsIGJlIHJlcXVpcmVkLgoKOC4g IEFja25vd2xlZGdtZW50cwoKICAgVGhhbmtzIHRvIEppbSBHdWljaGFyZCwgRG9uYWxkIEVhc3Rs YWtlLCBhbmQgU3Rld2FydCBCcnlhbnQgZm9yIHRoZWlyCiAgIHJldmlldyBjb21tZW50cy4KCjku ICBSZWZlcmVuY2VzCgoKCgoKCgoKTWFsaXMsIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBKYW51 YXJ5IDI1LCAyMDIwICAgICAgICAgICAgICAgW1BhZ2UgMTNdCgwKSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgIERldE5ldCBDb250cm9sbGVyIFBsYW5lICAgICAgICAgICAgICAgSnVseSAyMDE5CgoK OS4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtJLUQuaWV0Zi1kZXRuZXQtYXJjaGl0ZWN0 dXJlXQogICAgICAgICAgICAgIEZpbm4sIE4uLCBUaHViZXJ0LCBQLiwgVmFyZ2EsIEIuLCBhbmQg Si4gRmFya2FzLAogICAgICAgICAgICAgICJEZXRlcm1pbmlzdGljIE5ldHdvcmtpbmcgQXJjaGl0 ZWN0dXJlIiwgZHJhZnQtaWV0Zi0KICAgICAgICAgICAgICBkZXRuZXQtYXJjaGl0ZWN0dXJlLTEz ICh3b3JrIGluIHByb2dyZXNzKSwgTWF5IDIwMTkuCgogICBbSS1ELmlldGYtZGV0bmV0LWRhdGEt cGxhbmUtZnJhbWV3b3JrXQogICAgICAgICAgICAgIFZhcmdhLCBCLiwgRmFya2FzLCBKLiwgQmVy Z2VyLCBMLiwgRmVkeWssIEQuLCBNYWxpcywgQS4sCiAgICAgICAgICAgICAgQnJ5YW50LCBTLiwg YW5kIEouIEtvcmhvbmVuLCAiRGV0TmV0IERhdGEgUGxhbmUKICAgICAgICAgICAgICBGcmFtZXdv cmsiLCBkcmFmdC1pZXRmLWRldG5ldC1kYXRhLXBsYW5lLWZyYW1ld29yay0wMQogICAgICAgICAg ICAgICh3b3JrIGluIHByb2dyZXNzKSwgSnVseSAyMDE5LgoKICAgW0ktRC5pZXRmLWRldG5ldC1m bG93LWluZm9ybWF0aW9uLW1vZGVsXQogICAgICAgICAgICAgIEZhcmthcywgSi4sIFZhcmdhLCBC LiwgQ3VtbWluZ3MsIFIuLCBhbmQgWS4gSmlhbmcsICJEZXROZXQKICAgICAgICAgICAgICBGbG93 IEluZm9ybWF0aW9uIE1vZGVsIiwgZHJhZnQtaWV0Zi1kZXRuZXQtZmxvdy0KICAgICAgICAgICAg ICBpbmZvcm1hdGlvbi1tb2RlbC0wNCAod29yayBpbiBwcm9ncmVzcyksIEp1bHkgMjAxOS4KCiAg IFtJLUQuaWV0Zi1kZXRuZXQtaXBdCiAgICAgICAgICAgICAgVmFyZ2EsIEIuLCBGYXJrYXMsIEou LCBCZXJnZXIsIEwuLCBGZWR5aywgRC4sIE1hbGlzLCBBLiwKICAgICAgICAgICAgICBCcnlhbnQs IFMuLCBhbmQgSi4gS29yaG9uZW4sICJEZXROZXQgRGF0YSBQbGFuZTogSVAiLAogICAgICAgICAg ICAgIGRyYWZ0LWlldGYtZGV0bmV0LWlwLTAxICh3b3JrIGluIHByb2dyZXNzKSwgSnVseSAyMDE5 LgoKICAgW0ktRC5pZXRmLWRldG5ldC1tcGxzXQogICAgICAgICAgICAgIFZhcmdhLCBCLiwgRmFy a2FzLCBKLiwgQmVyZ2VyLCBMLiwgRmVkeWssIEQuLCBNYWxpcywgQS4sCiAgICAgICAgICAgICAg QnJ5YW50LCBTLiwgYW5kIEouIEtvcmhvbmVuLCAiRGV0TmV0IERhdGEgUGxhbmU6IE1QTFMiLAog ICAgICAgICAgICAgIGRyYWZ0LWlldGYtZGV0bmV0LW1wbHMtMDEgKHdvcmsgaW4gcHJvZ3Jlc3Mp LCBKdWx5IDIwMTkuCgogICBbSS1ELmlldGYtZGV0bmV0LXNlY3VyaXR5XQogICAgICAgICAgICAg IE1penJhaGksIFQuLCBHcm9zc21hbiwgRS4sIEhhY2tlciwgQS4sIERhcywgUy4sIERvd2RlbGws CiAgICAgICAgICAgICAgSi4sIEF1c3RhZCwgSC4sIFN0YW50b24sIEsuLCBhbmQgTi4gRmlubiwg IkRldGVybWluaXN0aWMKICAgICAgICAgICAgICBOZXR3b3JraW5nIChEZXROZXQpIFNlY3VyaXR5 IENvbnNpZGVyYXRpb25zIiwgZHJhZnQtaWV0Zi0KICAgICAgICAgICAgICBkZXRuZXQtc2VjdXJp dHktMDQgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBNYXJjaCAyMDE5LgoKICAgW1JGQzIxMTldICBCcmFk bmVyLCBTLiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUKICAgICAgICAg ICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LAogICAgICAgICAgICAg IERPSSAxMC4xNzQ4Ny9SRkMyMTE5LCBNYXJjaCAxOTk3LAogICAgICAgICAgICAgIDxodHRwczov L3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzIxMTk+LgoKICAgW1JGQzc0MjZdICBIYWxlcGxp ZGlzLCBFLiwgRWQuLCBQZW50aWtvdXNpcywgSy4sIEVkLiwgRGVuYXppcywgUy4sCiAgICAgICAg ICAgICAgSGFkaSBTYWxpbSwgSi4sIE1leWVyLCBELiwgYW5kIE8uIEtvdWZvcGF2bG91LCAiU29m dHdhcmUtCiAgICAgICAgICAgICAgRGVmaW5lZCBOZXR3b3JraW5nIChTRE4pOiBMYXllcnMgYW5k IEFyY2hpdGVjdHVyZQogICAgICAgICAgICAgIFRlcm1pbm9sb2d5IiwgUkZDIDc0MjYsIERPSSAx MC4xNzQ4Ny9SRkM3NDI2LCBKYW51YXJ5CiAgICAgICAgICAgICAgMjAxNSwgPGh0dHBzOi8vd3d3 LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNzQyNj4uCgogICBbUkZDODE3NF0gIExlaWJhLCBCLiwg IkFtYmlndWl0eSBvZiBVcHBlcmNhc2UgdnMgTG93ZXJjYXNlIGluIFJGQwogICAgICAgICAgICAg IDIxMTkgS2V5IFdvcmRzIiwgQkNQIDE0LCBSRkMgODE3NCwgRE9JIDEwLjE3NDg3L1JGQzgxNzQs CiAgICAgICAgICAgICAgTWF5IDIwMTcsIDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZv L3JmYzgxNzQ+LgoKCgpNYWxpcywgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgMjUs IDIwMjAgICAgICAgICAgICAgICBbUGFnZSAxNF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg RGV0TmV0IENvbnRyb2xsZXIgUGxhbmUgICAgICAgICAgICAgICBKdWx5IDIwMTkKCgogICBbUkZD ODQwMl0gIEZpbHNmaWxzLCBDLiwgRWQuLCBQcmV2aWRpLCBTLiwgRWQuLCBHaW5zYmVyZywgTC4s CiAgICAgICAgICAgICAgRGVjcmFlbmUsIEIuLCBMaXRrb3dza2ksIFMuLCBhbmQgUi4gU2hha2ly LCAiU2VnbWVudAogICAgICAgICAgICAgIFJvdXRpbmcgQXJjaGl0ZWN0dXJlIiwgUkZDIDg0MDIs IERPSSAxMC4xNzQ4Ny9SRkM4NDAyLAogICAgICAgICAgICAgIEp1bHkgMjAxOCwgPGh0dHBzOi8v d3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjODQwMj4uCgo5LjIuICBJbmZvcm1hdGl2ZSBSZWZl cmVuY2VzCgogICBbSS1ELmNoZW4tZGV0bmV0LWxvc3MtZGVsYXldCiAgICAgICAgICAgICAgQ2hl biwgTS4gYW5kIEEuIE1hbGlzLCAiRGV0TmV0IFBhY2tldCBMb3NzIGFuZCBEZWxheQogICAgICAg ICAgICAgIFBlcmZvcm1hbmNlIE1lYXN1cmVtZW50IiwgZHJhZnQtY2hlbi1kZXRuZXQtbG9zcy1k ZWxheS0wMQogICAgICAgICAgICAgICh3b3JrIGluIHByb2dyZXNzKSwgT2N0b2JlciAyMDE4LgoK ICAgW0ktRC5kaG9keS1wY2UtcGNlcC1leHRlbnNpb24tcGNlLWNvbnRyb2xsZXItc3J2Nl0KICAg ICAgICAgICAgICBOZWdpLCBNLiwgTGksIFouLCBhbmQgWC4gR2VuZywgIlBDRVAgUHJvY2VkdXJl cyBhbmQKICAgICAgICAgICAgICBQcm90b2NvbCBFeHRlbnNpb25zIGZvciBVc2luZyBQQ0UgYXMg YSBDZW50cmFsIENvbnRyb2xsZXIKICAgICAgICAgICAgICAoUENFQ0MpIGZvciBTUnY2IiwgZHJh ZnQtZGhvZHktcGNlLXBjZXAtZXh0ZW5zaW9uLXBjZS0KICAgICAgICAgICAgICBjb250cm9sbGVy LXNydjYtMDEgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBGZWJydWFyeSAyMDE5LgoKICAgW0ktRC5kb25n LXNwcmluZy1zci1mb3ItZW5oYW5jZWQtdnBuXQogICAgICAgICAgICAgIERvbmcsIEouLCBCcnlh bnQsIFMuLCBNaXlhc2FrYSwgVC4sIFpodSwgWS4sIFFpbiwgRi4sIGFuZAogICAgICAgICAgICAg IFouIExpLCAiU2VnbWVudCBSb3V0aW5nIGZvciBFbmhhbmNlZCBWUE4gU2VydmljZSIsIGRyYWZ0 LQogICAgICAgICAgICAgIGRvbmctc3ByaW5nLXNyLWZvci1lbmhhbmNlZC12cG4tMDQgKHdvcmsg aW4gcHJvZ3Jlc3MpLAogICAgICAgICAgICAgIEp1bHkgMjAxOS4KCiAgIFtJLUQuZmlubi1kZXRu ZXQtYm91bmRlZC1sYXRlbmN5XQogICAgICAgICAgICAgIEZpbm4sIE4uLCBCb3VkZWMsIEouLCBN b2hhbW1hZHBvdXIsIEUuLCBaaGFuZywgSi4sIFZhcmdhLAogICAgICAgICAgICAgIEIuLCBhbmQg Si4gRmFya2FzLCAiRGV0TmV0IEJvdW5kZWQgTGF0ZW5jeSIsIGRyYWZ0LWZpbm4tCiAgICAgICAg ICAgICAgZGV0bmV0LWJvdW5kZWQtbGF0ZW5jeS0wNCAod29yayBpbiBwcm9ncmVzcyksIEp1bmUg MjAxOS4KCiAgIFtJLUQuZ2VuZy1kZXRuZXQtZHAtc29sLXNydjZdCiAgICAgICAgICAgICAgR2Vu ZywgWC4sIENoZW4sIE0uLCBhbmQgWS4gWmh1LCAiRGV0TmV0IFNSdjYgRGF0YSBQbGFuZQogICAg ICAgICAgICAgIEVuY2Fwc3VsYXRpb24iLCBkcmFmdC1nZW5nLWRldG5ldC1kcC1zb2wtc3J2Ni0w MSAod29yayBpbgogICAgICAgICAgICAgIHByb2dyZXNzKSwgSnVseSAyMDE5LgoKICAgW0ktRC5p ZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlcl0KICAgICAgICAgICAgICBGaWxzZmlscywg Qy4sIER1a2VzLCBELiwgUHJldmlkaSwgUy4sIExlZGR5LCBKLiwKICAgICAgICAgICAgICBNYXRz dXNoaW1hLCBTLiwgYW5kIGQuIGRhbmllbC52b3llckBiZWxsLmNhLCAiSVB2NiBTZWdtZW50CiAg ICAgICAgICAgICAgUm91dGluZyBIZWFkZXIgKFNSSCkiLCBkcmFmdC1pZXRmLTZtYW4tc2VnbWVu dC1yb3V0aW5nLQogICAgICAgICAgICAgIGhlYWRlci0yMSAod29yayBpbiBwcm9ncmVzcyksIEp1 bmUgMjAxOS4KCiAgIFtJLUQuaWV0Zi1iaWVyLXRlLWFyY2hdCiAgICAgICAgICAgICAgRWNrZXJ0 LCBULiwgQ2F1Y2hpZSwgRy4sIGFuZCBNLiBNZW50aCwgIlRyYWZmaWMKICAgICAgICAgICAgICBF bmdpbmVlcmluZyBmb3IgQml0IEluZGV4IEV4cGxpY2l0IFJlcGxpY2F0aW9uIChCSUVSLVRFKSIs CiAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1iaWVyLXRlLWFyY2gtMDMgKHdvcmsgaW4gcHJvZ3Jl c3MpLCBKdWx5IDIwMTkuCgoKCgoKCgpNYWxpcywgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEph bnVhcnkgMjUsIDIwMjAgICAgICAgICAgICAgICBbUGFnZSAxNV0KDApJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgRGV0TmV0IENvbnRyb2xsZXIgUGxhbmUgICAgICAgICAgICAgICBKdWx5IDIwMTkK CgogICBbSS1ELmlldGYtZGV0bmV0LWlwLW92ZXItbXBsc10KICAgICAgICAgICAgICBWYXJnYSwg Qi4sIEZhcmthcywgSi4sIEJlcmdlciwgTC4sIEZlZHlrLCBELiwgTWFsaXMsIEEuLAogICAgICAg ICAgICAgIEJyeWFudCwgUy4sIGFuZCBKLiBLb3Job25lbiwgIkRldE5ldCBEYXRhIFBsYW5lOiBJ UCBvdmVyCiAgICAgICAgICAgICAgTVBMUyIsIGRyYWZ0LWlldGYtZGV0bmV0LWlwLW92ZXItbXBs cy0wMSAod29yayBpbgogICAgICAgICAgICAgIHByb2dyZXNzKSwgSnVseSAyMDE5LgoKICAgW0kt RC5pZXRmLWRldG5ldC1pcC1vdmVyLXRzbl0KICAgICAgICAgICAgICBWYXJnYSwgQi4sIEZhcmth cywgSi4sIE1hbGlzLCBBLiwgQnJ5YW50LCBTLiwgYW5kIEouCiAgICAgICAgICAgICAgS29yaG9u ZW4sICJEZXROZXQgRGF0YSBQbGFuZTogSVAgb3ZlciBJRUVFIDgwMi4xIFRpbWUKICAgICAgICAg ICAgICBTZW5zaXRpdmUgTmV0d29ya2luZyAoVFNOKSIsIGRyYWZ0LWlldGYtZGV0bmV0LWlwLW92 ZXItCiAgICAgICAgICAgICAgdHNuLTAwICh3b3JrIGluIHByb2dyZXNzKSwgTWF5IDIwMTkuCgog ICBbSS1ELmlldGYtZGV0bmV0LW1wbHMtb3Zlci10c25dCiAgICAgICAgICAgICAgVmFyZ2EsIEIu LCBGYXJrYXMsIEouLCBNYWxpcywgQS4sIEJyeWFudCwgUy4sIGFuZCBKLgogICAgICAgICAgICAg IEtvcmhvbmVuLCAiRGV0TmV0IERhdGEgUGxhbmU6IE1QTFMgb3ZlciBJRUVFIDgwMi4xIFRpbWUK ICAgICAgICAgICAgICBTZW5zaXRpdmUgTmV0d29ya2luZyAoVFNOKSIsIGRyYWZ0LWlldGYtZGV0 bmV0LW1wbHMtb3Zlci0KICAgICAgICAgICAgICB0c24tMDAgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBN YXkgMjAxOS4KCiAgIFtJLUQuaWV0Zi1kZXRuZXQtbXBscy1vdmVyLXVkcC1pcF0KICAgICAgICAg ICAgICBWYXJnYSwgQi4sIEZhcmthcywgSi4sIEJlcmdlciwgTC4sIE1hbGlzLCBBLiwgQnJ5YW50 LCBTLiwKICAgICAgICAgICAgICBhbmQgSi4gS29yaG9uZW4sICJEZXROZXQgRGF0YSBQbGFuZTog TVBMUyBvdmVyIFVEUC9JUCIsCiAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1kZXRuZXQtbXBscy1v dmVyLXVkcC1pcC0wMSAod29yayBpbiBwcm9ncmVzcyksCiAgICAgICAgICAgICAgSnVseSAyMDE5 LgoKICAgW0ktRC5pZXRmLWRldG5ldC10b3BvbG9neS15YW5nXQogICAgICAgICAgICAgIEdlbmcs IFguLCBDaGVuLCBNLiwgTGksIFouLCBhbmQgUi4gUmFobWFuLCAiRGV0ZXJtaW5pc3RpYwogICAg ICAgICAgICAgIE5ldHdvcmtpbmcgKERldE5ldCkgVG9wb2xvZ3kgWUFORyBNb2RlbCIsIGRyYWZ0 LWlldGYtCiAgICAgICAgICAgICAgZGV0bmV0LXRvcG9sb2d5LXlhbmctMDAgKHdvcmsgaW4gcHJv Z3Jlc3MpLCBKYW51YXJ5IDIwMTkuCgogICBbSS1ELmlldGYtZGV0bmV0LXRzbi12cG4tb3Zlci1t cGxzXQogICAgICAgICAgICAgIFZhcmdhLCBCLiwgRmFya2FzLCBKLiwgTWFsaXMsIEEuLCBCcnlh bnQsIFMuLCBhbmQgSi4KICAgICAgICAgICAgICBLb3Job25lbiwgIkRldE5ldCBEYXRhIFBsYW5l OiBJRUVFIDgwMi4xIFRpbWUgU2Vuc2l0aXZlCiAgICAgICAgICAgICAgTmV0d29ya2luZyBvdmVy IE1QTFMiLCBkcmFmdC1pZXRmLWRldG5ldC10c24tdnBuLW92ZXItCiAgICAgICAgICAgICAgbXBs cy0wMCAod29yayBpbiBwcm9ncmVzcyksIE1heSAyMDE5LgoKICAgW0ktRC5pZXRmLWRldG5ldC15 YW5nXQogICAgICAgICAgICAgIEdlbmcsIFguLCBDaGVuLCBNLiwgUnlvbywgWS4sIExpLCBaLiwg YW5kIFIuIFJhaG1hbiwKICAgICAgICAgICAgICAiRGV0ZXJtaW5pc3RpYyBOZXR3b3JraW5nIChE ZXROZXQpIENvbmZpZ3VyYXRpb24gWUFORwogICAgICAgICAgICAgIE1vZGVsIiwgZHJhZnQtaWV0 Zi1kZXRuZXQteWFuZy0wMyAod29yayBpbiBwcm9ncmVzcyksIEp1bHkKICAgICAgICAgICAgICAy MDE5LgoKICAgW0ktRC5pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbXBsc10KICAgICAgICAg ICAgICBCYXNoYW5keSwgQS4sIEZpbHNmaWxzLCBDLiwgUHJldmlkaSwgUy4sIERlY3JhZW5lLCBC LiwKICAgICAgICAgICAgICBMaXRrb3dza2ksIFMuLCBhbmQgUi4gU2hha2lyLCAiU2VnbWVudCBS b3V0aW5nIHdpdGggTVBMUwogICAgICAgICAgICAgIGRhdGEgcGxhbmUiLCBkcmFmdC1pZXRmLXNw cmluZy1zZWdtZW50LXJvdXRpbmctbXBscy0yMgogICAgICAgICAgICAgICh3b3JrIGluIHByb2dy ZXNzKSwgTWF5IDIwMTkuCgoKCgoKTWFsaXMsIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBKYW51 YXJ5IDI1LCAyMDIwICAgICAgICAgICAgICAgW1BhZ2UgMTZdCgwKSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgIERldE5ldCBDb250cm9sbGVyIFBsYW5lICAgICAgICAgICAgICAgSnVseSAyMDE5CgoK ICAgW0ktRC5taXJza3ktZGV0bmV0LW9hbV0KICAgICAgICAgICAgICBNaXJza3ksIEcuIGFuZCBN LiBDaGVuLCAiT3BlcmF0aW9ucywgQWRtaW5pc3RyYXRpb24gYW5kCiAgICAgICAgICAgICAgTWFp bnRlbmFuY2UgKE9BTSkgZm9yIERldGVybWluaXN0aWMgTmV0d29ya3MgKERldE5ldCkiLAogICAg ICAgICAgICAgIGRyYWZ0LW1pcnNreS1kZXRuZXQtb2FtLTAzICh3b3JrIGluIHByb2dyZXNzKSwg TWF5IDIwMTkuCgogICBbSS1ELnpoYW8tcGNlLXBjZXAtZXh0ZW5zaW9uLXBjZS1jb250cm9sbGVy LXNyXQogICAgICAgICAgICAgIFpoYW8sIFEuLCBMaSwgWi4sIE5lZ2ksIE0uLCBhbmQgQy4gWmhv dSwgIlBDRVAgUHJvY2VkdXJlcwogICAgICAgICAgICAgIGFuZCBQcm90b2NvbCBFeHRlbnNpb25z IGZvciBVc2luZyBQQ0UgYXMgYSBDZW50cmFsCiAgICAgICAgICAgICAgQ29udHJvbGxlciAoUENF Q0MpIG9mIFNSLUxTUHMiLCBkcmFmdC16aGFvLXBjZS1wY2VwLQogICAgICAgICAgICAgIGV4dGVu c2lvbi1wY2UtY29udHJvbGxlci1zci0wNSAod29yayBpbiBwcm9ncmVzcyksIEp1bHkKICAgICAg ICAgICAgICAyMDE5LgoKICAgW0lFRUUuODAyLjFRQlZfMjAxNV0KICAgICAgICAgICAgICBJRUVF LCAiSUVFRSBTdGFuZGFyZCBmb3IgTG9jYWwgYW5kIG1ldHJvcG9saXRhbiBhcmVhCiAgICAgICAg ICAgICAgbmV0d29ya3MgLS0gQnJpZGdlcyBhbmQgQnJpZGdlZCBOZXR3b3JrcyAtIEFtZW5kbWVu dCAyNToKICAgICAgICAgICAgICBFbmhhbmNlbWVudHMgZm9yIFNjaGVkdWxlZCBUcmFmZmljIiwg SUVFRSA4MDIuMVFidi0yMDE1LAogICAgICAgICAgICAgIERPSSAxMC4xMTA5L0lFRUVTVEQuMjAx Ni43NTcyODU4LCBNYXJjaCAyMDE2LAogICAgICAgICAgICAgIDxodHRwOi8vaWVlZXhwbG9yZS5p ZWVlLm9yZy9zZXJ2bGV0LwogICAgICAgICAgICAgIG9wYWM/cHVudW1iZXI9NzU3Mjg1OD4uCgog ICBbSUVFRS44MDIuMVFjYy0yMDE4XQogICAgICAgICAgICAgIElFRUUsICJJRUVFIFN0YW5kYXJk IGZvciBMb2NhbCBhbmQgTWV0cm9wb2xpdGFuIEFyZWEKICAgICAgICAgICAgICBOZXR3b3JrcyAt LSBCcmlkZ2VzIGFuZCBCcmlkZ2VkIE5ldHdvcmtzIC0tIEFtZW5kbWVudCAzMToKICAgICAgICAg ICAgICBTdHJlYW0gUmVzZXJ2YXRpb24gUHJvdG9jb2wgKFNSUCkgRW5oYW5jZW1lbnRzIGFuZAog ICAgICAgICAgICAgIFBlcmZvcm1hbmNlIEltcHJvdmVtZW50cyIsIElFRUUgODAyLjFRY2MtMjAx OCwKICAgICAgICAgICAgICBET0kgMTAuMTEwOS9pZWVlc3RkLjIwMTguODUxNDExMiwgT2N0b2Jl ciAyMDE4LAogICAgICAgICAgICAgIDxodHRwOi8vaWVlZXhwbG9yZS5pZWVlLm9yZy9zZXJ2bGV0 LwogICAgICAgICAgICAgIG9wYWM/cHVudW1iZXI9ODUxNDExMD4uCgogICBbT1BFTkZMT1ddCiAg ICAgICAgICAgICAgT3BlbiBOZXR3b3JraW5nIEZvdW5kYXRpb24sICJPcGVuRmxvdyBTd2l0Y2gK ICAgICAgICAgICAgICBTcGVjaWZpY2F0aW9uLCBWZXJzaW9uIDEuNS4xIChQcm90b2NvbCB2ZXJz aW9uIDB4MDYpIiwKICAgICAgICAgICAgICBPTkYgVFMtMDI1LCBNYXJjaCAyMDE1LCA8aHR0cHM6 Ly93d3cub3Blbm5ldHdvcmtpbmcub3JnLwogICAgICAgICAgICAgIHdwLWNvbnRlbnQvdXBsb2Fk cy8yMDE0LzEwL29wZW5mbG93LXN3aXRjaC12MS41LjEucGRmPi4KCiAgIFtSRkMzMjA5XSAgQXdk dWNoZSwgRC4sIEJlcmdlciwgTC4sIEdhbiwgRC4sIExpLCBULiwgU3Jpbml2YXNhbiwgVi4sCiAg ICAgICAgICAgICAgYW5kIEcuIFN3YWxsb3csICJSU1ZQLVRFOiBFeHRlbnNpb25zIHRvIFJTVlAg Zm9yIExTUAogICAgICAgICAgICAgIFR1bm5lbHMiLCBSRkMgMzIwOSwgRE9JIDEwLjE3NDg3L1JG QzMyMDksIERlY2VtYmVyIDIwMDEsCiAgICAgICAgICAgICAgPGh0dHBzOi8vd3d3LnJmYy1lZGl0 b3Iub3JnL2luZm8vcmZjMzIwOT4uCgogICBbUkZDNDM4NF0gIE1leWVyLCBELiwgIkJHUCBDb21t dW5pdGllcyBmb3IgRGF0YSBDb2xsZWN0aW9uIiwgQkNQIDExNCwKICAgICAgICAgICAgICBSRkMg NDM4NCwgRE9JIDEwLjE3NDg3L1JGQzQzODQsIEZlYnJ1YXJ5IDIwMDYsCiAgICAgICAgICAgICAg PGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNDM4ND4uCgogICBbUkZDNTAzNl0g IEFuZGVyc3NvbiwgTC4sIEVkLiwgTWluZWksIEkuLCBFZC4sIGFuZCBCLiBUaG9tYXMsIEVkLiwK ICAgICAgICAgICAgICAiTERQIFNwZWNpZmljYXRpb24iLCBSRkMgNTAzNiwgRE9JIDEwLjE3NDg3 L1JGQzUwMzYsCiAgICAgICAgICAgICAgT2N0b2JlciAyMDA3LCA8aHR0cHM6Ly93d3cucmZjLWVk aXRvci5vcmcvaW5mby9yZmM1MDM2Pi4KCgoKCk1hbGlzLCBldCBhbC4gICAgICAgICAgIEV4cGly ZXMgSmFudWFyeSAyNSwgMjAyMCAgICAgICAgICAgICAgIFtQYWdlIDE3XQoMCkludGVybmV0LURy YWZ0ICAgICAgICAgICBEZXROZXQgQ29udHJvbGxlciBQbGFuZSAgICAgICAgICAgICAgIEp1bHkg MjAxOQoKCiAgIFtSRkM1NDM5XSAgWWFzdWthd2EsIFMuLCBGYXJyZWwsIEEuLCBhbmQgTy4gS29t b2xhZmUsICJBbiBBbmFseXNpcyBvZgogICAgICAgICAgICAgIFNjYWxpbmcgSXNzdWVzIGluIE1Q TFMtVEUgQ29yZSBOZXR3b3JrcyIsIFJGQyA1NDM5LAogICAgICAgICAgICAgIERPSSAxMC4xNzQ4 Ny9SRkM1NDM5LCBGZWJydWFyeSAyMDA5LAogICAgICAgICAgICAgIDxodHRwczovL3d3dy5yZmMt ZWRpdG9yLm9yZy9pbmZvL3JmYzU0Mzk+LgoKICAgW1JGQzU0NDBdICBWYXNzZXVyLCBKUC4sIEVk LiBhbmQgSkwuIExlIFJvdXgsIEVkLiwgIlBhdGggQ29tcHV0YXRpb24KICAgICAgICAgICAgICBF bGVtZW50IChQQ0UpIENvbW11bmljYXRpb24gUHJvdG9jb2wgKFBDRVApIiwgUkZDIDU0NDAsCiAg ICAgICAgICAgICAgRE9JIDEwLjE3NDg3L1JGQzU0NDAsIE1hcmNoIDIwMDksCiAgICAgICAgICAg ICAgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNTQ0MD4uCgogICBbUkZDNTk2 MF0gIEZyb3N0LCBELiwgRWQuLCBCcnlhbnQsIFMuLCBFZC4sIGFuZCBNLiBCb2NjaSwgRWQuLCAi TVBMUwogICAgICAgICAgICAgIFRyYW5zcG9ydCBQcm9maWxlIERhdGEgUGxhbmUgQXJjaGl0ZWN0 dXJlIiwgUkZDIDU5NjAsCiAgICAgICAgICAgICAgRE9JIDEwLjE3NDg3L1JGQzU5NjAsIEF1Z3Vz dCAyMDEwLAogICAgICAgICAgICAgIDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3Jm YzU5NjA+LgoKICAgW1JGQzYwMjBdICBCam9ya2x1bmQsIE0uLCBFZC4sICJZQU5HIC0gQSBEYXRh IE1vZGVsaW5nIExhbmd1YWdlIGZvcgogICAgICAgICAgICAgIHRoZSBOZXR3b3JrIENvbmZpZ3Vy YXRpb24gUHJvdG9jb2wgKE5FVENPTkYpIiwgUkZDIDYwMjAsCiAgICAgICAgICAgICAgRE9JIDEw LjE3NDg3L1JGQzYwMjAsIE9jdG9iZXIgMjAxMCwKICAgICAgICAgICAgICA8aHR0cHM6Ly93d3cu cmZjLWVkaXRvci5vcmcvaW5mby9yZmM2MDIwPi4KCiAgIFtSRkM2MjQxXSAgRW5ucywgUi4sIEVk LiwgQmpvcmtsdW5kLCBNLiwgRWQuLCBTY2hvZW53YWVsZGVyLCBKLiwgRWQuLAogICAgICAgICAg ICAgIGFuZCBBLiBCaWVybWFuLCBFZC4sICJOZXR3b3JrIENvbmZpZ3VyYXRpb24gUHJvdG9jb2wK ICAgICAgICAgICAgICAoTkVUQ09ORikiLCBSRkMgNjI0MSwgRE9JIDEwLjE3NDg3L1JGQzYyNDEs IEp1bmUgMjAxMSwKICAgICAgICAgICAgICA8aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5m by9yZmM2MjQxPi4KCiAgIFtSRkM3NDMyXSAgU2FqYXNzaSwgQS4sIEVkLiwgQWdnYXJ3YWwsIFIu LCBCaXRhciwgTi4sIElzYWFjLCBBLiwKICAgICAgICAgICAgICBVdHRhcm8sIEouLCBEcmFrZSwg Si4sIGFuZCBXLiBIZW5kZXJpY2t4LCAiQkdQIE1QTFMtQmFzZWQKICAgICAgICAgICAgICBFdGhl cm5ldCBWUE4iLCBSRkMgNzQzMiwgRE9JIDEwLjE3NDg3L1JGQzc0MzIsIEZlYnJ1YXJ5CiAgICAg ICAgICAgICAgMjAxNSwgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNzQzMj4u CgogICBbUkZDNzc1Ml0gIEdyZWRsZXIsIEguLCBFZC4sIE1lZHZlZCwgSi4sIFByZXZpZGksIFMu LCBGYXJyZWwsIEEuLCBhbmQKICAgICAgICAgICAgICBTLiBSYXksICJOb3J0aC1Cb3VuZCBEaXN0 cmlidXRpb24gb2YgTGluay1TdGF0ZSBhbmQKICAgICAgICAgICAgICBUcmFmZmljIEVuZ2luZWVy aW5nIChURSkgSW5mb3JtYXRpb24gVXNpbmcgQkdQIiwgUkZDIDc3NTIsCiAgICAgICAgICAgICAg RE9JIDEwLjE3NDg3L1JGQzc3NTIsIE1hcmNoIDIwMTYsCiAgICAgICAgICAgICAgPGh0dHBzOi8v d3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNzc1Mj4uCgogICBbUkZDODI3N10gIFJvc2VuLCBF LiwgIlVzaW5nIEJHUCB0byBCaW5kIE1QTFMgTGFiZWxzIHRvIEFkZHJlc3MKICAgICAgICAgICAg ICBQcmVmaXhlcyIsIFJGQyA4Mjc3LCBET0kgMTAuMTc0ODcvUkZDODI3NywgT2N0b2JlciAyMDE3 LAogICAgICAgICAgICAgIDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzgyNzc+ LgoKICAgW1JGQzgyODNdICBGYXJyZWwsIEEuLCBFZC4sIFpoYW8sIFEuLCBFZC4sIExpLCBaLiwg YW5kIEMuIFpob3UsICJBbgogICAgICAgICAgICAgIEFyY2hpdGVjdHVyZSBmb3IgVXNlIG9mIFBD RSBhbmQgdGhlIFBDRSBDb21tdW5pY2F0aW9uCiAgICAgICAgICAgICAgUHJvdG9jb2wgKFBDRVAp IGluIGEgTmV0d29yayB3aXRoIENlbnRyYWwgQ29udHJvbCIsCiAgICAgICAgICAgICAgUkZDIDgy ODMsIERPSSAxMC4xNzQ4Ny9SRkM4MjgzLCBEZWNlbWJlciAyMDE3LAogICAgICAgICAgICAgIDxo dHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzgyODM+LgoKCgoKCgpNYWxpcywgZXQg YWwuICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgMjUsIDIwMjAgICAgICAgICAgICAgICBbUGFn ZSAxOF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgRGV0TmV0IENvbnRyb2xsZXIgUGxhbmUg ICAgICAgICAgICAgICBKdWx5IDIwMTkKCgpBdXRob3JzJyBBZGRyZXNzZXMKCiAgIEFuZHJldyBH LiBNYWxpcwogICBJbmRlcGVuZGVudAoKICAgRW1haWw6IGFnbWFsaXNAZ21haWwuY29tCgoKICAg WHVlc29uZyBHZW5nCiAgIEh1YXdlaQoKICAgRW1haWw6IGdlbmd4dWVzb25nQGh1YXdlaS5jb20K CgogICBNYWNoIChHdW95aSkgQ2hlbgogICBIdWF3ZWkKCiAgIEVtYWlsOiBtYWNoLmNoZW5AaHVh d2VpLmNvbQoKCiAgIEZlbmd3ZWkgUWluCiAgIENoaW5hIE1vYmlsZQoKICAgRW1haWw6IHFpbmZl bmd3ZWlAY2hpbmFtb2JpbGUuY29tCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCk1hbGlzLCBl dCBhbC4gICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSAyNSwgMjAyMCAgICAgICAgICAgICAgIFtQ YWdlIDE5XQo= --000000000000f495df058efe5cc9 Content-Type: text/markdown; charset="US-ASCII"; name="draft-malis-detnet-controller-plane-framework-02.md" Content-Disposition: attachment; filename="draft-malis-detnet-controller-plane-framework-02.md" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_jyrl88up0 LS0tCnRpdGxlOiBEZXRlcm1pbmlzdGljIE5ldHdvcmtpbmcgKERldE5ldCkgQ29udHJvbGxlciBQ bGFuZSBGcmFtZXdvcmsKYWJicmV2OiBEZXROZXQgQ29udHJvbGxlciBQbGFuZQpkb2NuYW1lOiBk cmFmdC1tYWxpcy1kZXRuZXQtY29udHJvbGxlci1wbGFuZS1mcmFtZXdvcmstMDIKZGF0ZToKY2F0 ZWdvcnk6IGluZm8KCmlwcjogdHJ1c3QyMDA5MDIKa2V5d29yZDogSW50ZXJuZXQtRHJhZnQKCnN0 YW5kX2Fsb25lOiB5ZXMKcGk6IFt0b2MsIHNvcnRyZWZzLCBzeW1yZWZzXQoKYXV0aG9yOgogIC0K ICAgIGluczogQS4gTWFsaXMKICAgIG5hbWU6IEFuZHJldyBHLiBNYWxpcwogICAgb3JnOiBJbmRl cGVuZGVudAogICAgZW1haWw6IGFnbWFsaXNAZ21haWwuY29tCiAgLQogICAgaW5zOiBYLiBHZW5n CiAgICBuYW1lOiBYdWVzb25nIEdlbmcKICAgIG9yZzogSHVhd2VpCiAgICBlbWFpbDogZ2VuZ3h1 ZXNvbmdAaHVhd2VpLmNvbQogIC0KICAgIGluczogTS4gQ2hlbgogICAgbmFtZTogTWFjaCAoR3Vv eWkpIENoZW4KICAgIG9yZzogSHVhd2VpCiAgICBlbWFpbDogbWFjaC5jaGVuQGh1YXdlaS5jb20K ICAtCiAgICBpbnM6IEYuIFFpbgogICAgbmFtZTogRmVuZ3dlaSBRaW4KICAgIG9yZzogQ2hpbmEg TW9iaWxlCiAgICBlbWFpbDogcWluZmVuZ3dlaUBjaGluYW1vYmlsZS5jb20KCm5vcm1hdGl2ZToK CmluZm9ybWF0aXZlOgogIE9QRU5GTE9XOgogICAgdGl0bGU6ICIgT3BlbkZsb3cgU3dpdGNoIFNw ZWNpZmljYXRpb24sIFZlcnNpb24gMS41LjEgKFByb3RvY29sIHZlcnNpb24gMHgwNikiCiAgICBz ZXJpZXNpbmZvOgogICAgICBPTkY6IFRTLTAyNQogICAgZGF0ZTogTWFyY2ggMjAxNQogICAgdGFy Z2V0OiBodHRwczovL3d3dy5vcGVubmV0d29ya2luZy5vcmcvd3AtY29udGVudC91cGxvYWRzLzIw MTQvMTAvb3BlbmZsb3ctc3dpdGNoLXYxLjUuMS5wZGYKICAgIGF1dGhvcjoKICAgICBvcmc6IE9w ZW4gTmV0d29ya2luZyBGb3VuZGF0aW9uCgotLS0gYWJzdHJhY3QKClRoaXMgZG9jdW1lbnQgcHJv dmlkZXMgYSBmcmFtZXdvcmsgb3ZlcnZpZXcgZm9yIHRoZSBEZXRlcm1pbmlzdGljIE5ldHdvcmtp bmcgKERldE5ldCkgY29udHJvbGxlciBwbGFuZS4gSXQgZGlzY3Vzc2VzIGNvbmNlcHRzIGFuZCBy ZXF1aXJlbWVudHMgdGhhdCB3aWxsIGJlIGJhc2lzIGZvciBEZXRuZXQgY29udHJvbGxlciBwbGFu ZSBzb2x1dGlvbiBkb2N1bWVudHMuCgotLS0gbWlkZGxlCgojIEludHJvZHVjdGlvbgoKRGV0ZXJt aW5pc3RpYyBOZXR3b3JraW5nIChEZXROZXQpIHByb3ZpZGVzIHRoZSBjYXBhYmlsaXR5IHRvIGNh cnJ5IHNwZWNpZmllZCB1bmljYXN0IGFuZC9vciBtdWx0aWNhc3QgZGF0YSBmbG93cyBmb3IgcmVh bC10aW1lIGFwcGxpY2F0aW9ucyB3aXRoIGV4dHJlbWVseSBsb3cgZGF0YSBsb3NzIHJhdGVzIGFu ZCBib3VuZGVkIGxhdGVuY3kgd2l0aGluIGEgbmV0d29yayBkb21haW4uIEFzIGRpc2N1c3NlZCBp biB0aGUgRGV0ZXJtaW5pc3RpYyBOZXR3b3JraW5nIEFyY2hpdGVjdHVyZSB7eyFJLUQuaWV0Zi1k ZXRuZXQtYXJjaGl0ZWN0dXJlfX0sIHRlY2huaXF1ZXMgdXNlZCB0byBwcm92aWRlIHRoaXMgY2Fw YWJpbGl0eSBpbmNsdWRlIHJlc2VydmluZyBkYXRhIHBsYW5lIHJlc291cmNlcyBmb3IgaW5kaXZp ZHVhbCAob3IgYWdncmVnYXRlZCkgRGV0TmV0IGZsb3dzIGluIHNvbWUgb3IgYWxsIG9mIHRoZSBp bnRlcm1lZGlhdGUgbm9kZXMgYWxvbmcgdGhlIHBhdGggb2YgdGhlIGZsb3csIHByb3ZpZGluZyBl eHBsaWNpdCByb3V0ZXMgZm9yIERldE5ldCBmbG93cyB0aGF0IGRvIG5vdCBpbW1lZGlhdGVseSBj aGFuZ2Ugd2l0aCB0aGUgbmV0d29yayB0b3BvbG9neSwgYW5kIGRpc3RyaWJ1dGluZyBkYXRhIGZy b20gRGV0TmV0IGZsb3cgcGFja2V0cyBvdmVyIHRpbWUgYW5kL29yIHNwYWNlIHRvIGVuc3VyZSBk ZWxpdmVyeSBvZiBlYWNoIHBhY2tldCdzIGRhdGEgaW4gc3BpdGUgb2YgdGhlIGxvc3Mgb2YgYSBw YXRoLgoKVGhlIERldE5ldCBkYXRhIHBsYW5lIGlzIGRlZmluZWQgaW4gYSBzZXQgb2YgZG9jdW1l bnRzIHRoYXQgYXJlIGFuY2hvcmVkIGJ5IHRoZSBEZXROZXQgRGF0YSBQbGFuZSBGcmFtZXdvcmsg e3shSS1ELmlldGYtZGV0bmV0LWRhdGEtcGxhbmUtZnJhbWV3b3JrfX0gYW5kIHRoZSBhc3NvY2lh dGVkIERldE5ldCBNUExTIHt7IUktRC5pZXRmLWRldG5ldC1tcGxzfX0gYW5kIElQIHt7IUktRC5p ZXRmLWRldG5ldC1pcH19IGRhdGEgcGxhbmUgc3BlY2lmaWNhdGlvbnMsIHdpdGggYWRkaXRpb25h bCBkZXRhaWxzIGFuZCBzdWJuZXQgbWFwcGluZ3MgcHJvdmlkZWQgaW4ge3s/SS1ELmlldGYtZGV0 bmV0LWlwLW92ZXItbXBsc319LCB7ez9JLUQuaWV0Zi1kZXRuZXQtbXBscy1vdmVyLXVkcC1pcH19 LCB7ez9JLUQuaWV0Zi1kZXRuZXQtbXBscy1vdmVyLXRzbn19LCB7ez9JLUQuaWV0Zi1kZXRuZXQt aXAtb3Zlci10c259fSwgYW5kIHt7P0ktRC5pZXRmLWRldG5ldC10c24tdnBuLW92ZXItbXBsc319 LgoKV2hpbGUgdGhlIERldG5ldCBBcmNoaXRlY3R1cmUgYW5kIERhdGEgUGxhbmUgRnJhbWV3b3Jr IGRvY3VtZW50cyBhcmUgcHJpbWFyaWx5IGNvbmNlcm5lZCB3aXRoIGRhdGEgcGxhbmUgb3BlcmF0 aW9ucywgdGhleSBkbyBjb250YWluIHNvbWUgcmVmZXJlbmNlcyBhbmQgcmVxdWlyZW1lbnRzIGZv ciBmdW5jdGlvbnMgdGhhdCB3b3VsZCBiZSByZXF1aXJlZCBpbiBvcmRlciB0byBhdXRvbWF0ZSBE ZXROZXQgc2VydmljZSBwcm92aXNpb25pbmcgYW5kIG1vbml0b3JpbmcgdmlhIGEgRGV0TmV0IGNv bnRyb2xsZXIgcGxhbmUuIFRoZSBwdXJwb3NlIG9mIHRoaXMgZG9jdW1lbnQgaXMgdG8gZ2F0aGVy IHRoZXNlIHJlZmVyZW5jZXMgYW5kIHJlcXVpcmVtZW50cyBpbnRvIGEgc2luZ2xlIGRvY3VtZW50 IGFuZCBkaXNjdXNzIGhvdyB2YXJpb3VzIHBvc3NpYmxlIERldE5ldCBjb250cm9sbGVyIHBsYW5l IGFyY2hpdGVjdHVyZXMgY291bGQgYmUgdXNlZCB0byBzYXRpc2Z5IHRoZXNlIHJlcXVpcmVtZW50 cywgd2hpbGUgbm90IHByb3ZpZGluZyB0aGUgYWN0dWFsIHByb3RvY29sIGRldGFpbHMgZm9yIGEg RGV0TmV0IGNvbnRyb2xsZXIgcGxhbmUgc29sdXRpb24uIFN1Y2ggY29udHJvbGxlciBwbGFuZSBw cm90b2NvbCBzb2x1dGlvbnMgd2lsbCBiZSB0aGUgc3ViamVjdCBvZiBzdWJzZXF1ZW50IGRvY3Vt ZW50cy4KCk5vdGUgdGhhdCBpbiB0aGUgRGV0TmV0IG92ZXJhbGwgYXJjaGl0ZWN0dXJlLCB0aGUg Y29udHJvbGxlciBwbGFuZSBpbmNsdWRlcyB3aGF0IGFyZSBtb3JlIHRyYWRpdGlvbmFsbHkgY29u c2lkZXJlZCBzZXBhcmF0ZSBjb250cm9sIGFuZCBtYW5hZ2VtZW50IHBsYW5lcy4gVHJhZGl0aW9u YWxseSwgdGhlIG1hbmFnZW1lbnQgcGxhbmUgaXMgcHJpbWFyaWx5IGludm9sdmVkIHdpdGggbm9k ZSBhbmQgbmV0d29yayBwcm92aXNpb25pbmcsIG9wZXJhdGlvbmFsIE9BTSBmb3IgcGVyZm9ybWFu Y2UgbW9uaXRvcmluZywgYW5kIHRyb3VibGVzaG9vdGluZyBuZXR3b3JrIGJlaGF2aW9ycyBhbmQg b3V0YWdlcywgd2hpbGUgdGhlIGNvbnRyb2wgcGxhbmUgaXMgcHJpbWFyaWx5IHJlc3BvbnNpYmxl IGZvciB0aGUgaW5zdGFudGlhdGlvbiBhbmQgbWFpbnRlbmFuY2Ugb2YgIGZsb3dzLCBNUExTIGxh YmVsIGFsbG9jYXRpb24gYW5kIGRpc3RyaWJ1dGlvbiwgYW5kIGFjdGl2ZSBpbi1iYW5kIG9yIG91 dC1vZi1iYW5kIHNpZ25hbGluZyB0byBzdXBwb3J0IHRoZXNlIGZ1bmN0aW9ucy4gSW4gdGhlIERl dE5ldCBhcmNoaXRlY3R1cmUsIGFsbCBvZiB0aGlzIGZ1bmN0aW9uYWxpdHkgaXMgY29tYmluZWQg aW50byBhIHNpbmdsZSBDb250cm9sbGVyIFBsYW5lLiBTZWUgU2VjdGlvbiA0LjQuMiBvZiB7eyFJ LUQuaWV0Zi1kZXRuZXQtYXJjaGl0ZWN0dXJlfX0gYW5kIHRoZSBhZ2dyZWdhdGlvbiBvZiBDb250 cm9sIGFuZCBNYW5hZ2VtZW50IHBsYW5lcyBpbiB7eyFSRkM3NDI2fX0gZm9yIGZ1cnRoZXIgZGV0 YWlscy4KCiMjIFRlcm1pbm9sb2d5CgpUaGlzIGRvY3VtZW50IHVzZXMgdGhlIHRlcm1pbm9sb2d5 IGVzdGFibGlzaGVkIGluIHRoZSBEZXROZXQgQXJjaGl0ZWN0dXJlIHt7IUktRC5pZXRmLWRldG5l dC1hcmNoaXRlY3R1cmV9fSwgYW5kIHRoZSByZWFkZXIgaXMgYXNzdW1lZCB0byBiZSBmYW1pbGlh ciB3aXRoIHRoYXQgZG9jdW1lbnQgYW5kIGl0cyB0ZXJtaW5vbG9neS4KClRoZSBrZXkgd29yZHMg Ik1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwgIlNI T1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk5PVCBSRUNPTU1FTkRFRCIsICJN QVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRl ZCBhcyBkZXNjcmliZWQgaW4gQkNQIDE0IHt7IVJGQzIxMTl9fSB7eyFSRkM4MTc0fX0gd2hlbiwg YW5kIG9ubHkgd2hlbiwgdGhleSBhcHBlYXIgaW4gYWxsIGNhcGl0YWxzLCBhcyBzaG93biBoZXJl LgoKIyBEZXROZXQgQ29udHJvbGxlciBQbGFuZSBSZXF1aXJlbWVudHMKCk90aGVyIERldE5ldCBk b2N1bWVudHMsIGluY2x1ZGluZyB7eyFJLUQuaWV0Zi1kZXRuZXQtYXJjaGl0ZWN0dXJlfX0gYW5k IHt7IUktRC5pZXRmLWRldG5ldC1kYXRhLXBsYW5lLWZyYW1ld29ya319LCBjb250YWluIHJlcXVp cmVtZW50cyBmb3IgdGhlIENvbnRyb2xsZXIgUGxhbmUuIEZvciBjb252ZW5pZW5jZSwgdGhlc2Ug cmVxdWlyZW1lbnRzIGhhdmUgYmVlbiBjb21waWxlZCBoZXJlLiBUaGUgcHJpbWFyeSByZXF1aXJl bWVudHMgb2YgdGhlIERldE5ldCBDb250cm9sbGVyIFBsYW5lIGFyZSB0aGF0IGl0IG11c3QgYmUg YWJsZSB0bzoKCi0gU3VwcG9ydCB0aGUgZHluYW1pYyBjcmVhdGlvbiwgbW9kaWZpY2F0aW9uLCBh bmQgZGVsZXRpb24gb2YgRGV0TmV0IGZsb3dzLiBUaGlzIG1heSBpbmNsdWRlIHNvbWUgb3IgYWxs IG9mIGV4cGxpY2l0IHBhdGggZGV0ZXJtaW5hdGlvbiwgbGluayBiYW5kd2lkdGggcmVzZXJ2YXRp b25zLCByZXN0cmljdGluZyBmbG93cyB0byBJRUVFIDgwMi4xIFRpbWUtU2Vuc2l0aXZlIE5ldHdv cmtpbmcgKFRTTikgbGlua3MsIG5vZGUgYnVmZmVyIGFuZCBvdGhlciByZXNvdXJjZSByZXNlcnZh dGlvbnMsIHNwZWNpZmljYXRpb24gb2YgcmVxdWlyZWQgcXVldWluZyBkaXNjaXBsaW5lcyBhbG9u ZyB0aGUgcGF0aCwgYWJpbGl0eSB0byBtYW5hZ2UgYmlkaXJlY3Rpb25hbCBmbG93cywgZXRjLiwg YXMgbmVlZGVkIGZvciBhIGZsb3cuCgotIFN1cHBvcnQgRGV0TmV0IGZsb3cgYWdncmVnYXRpb24g YW5kIGRlLWFnZ3JlZ2F0aW9uIHZpYSB0aGUgYWJpbGl0eSB0byBkeW5hbWljYWxseSBjcmVhdGUg YW5kIGRlbGV0ZSBmbG93IGFnZ3JlZ2F0ZXMgKEZBcyksIGFuZCBiZSBhYmxlIHRvIG1vZGlmeSBl eGlzdGluZyBGQXMgYnkgYWRkaW5nIG9yIGRlbGV0aW5nIG1lbWJlcnMuCgotIE9wZXJhdGUgaW4g YSBjb252ZXJnZWQgbmV0d29yayBkb21haW4gdGhhdCBjb250YWlucyBib3RoIERldE5ldCBhbmQg bm9uLURldE5ldCBmbG93cy4KCi0gQWxsb3cgZmxvdyBpbnN0YW50aWF0aW9uIHJlcXVlc3RzIHRv IG9yaWdpbmF0ZSBpbiBhbiBlbmQgYXBwbGljYXRpb24gKHZpYSBhbiBBcHBsaWNhdGlvbiBQcm9n cmFtbWluZyBJbnRlcmZhY2UgKEFQSSksIHZpYSBzdGF0aWMgcHJvdmlzaW9uaW5nLCBvciB2aWEg YSBkeW5hbWljIGNvbnRyb2wgcGxhbmUsIHN1Y2ggYXMgYSBjZW50cmFsaXplZCBTRE4gY29udHJv bGxlciBvciBkaXN0cmlidXRlZCBzaWduYWxpbmcgcHJvdG9jb2xzLiBTZWUge3tjb250cm9sLXBs YW5lLWFyY2hpdGVjdHVyZX19IGZvciBmdXJ0aGVyIGRpc2N1c3Npb24gb2YgdGhlc2Ugb3B0aW9u cy4KCi0gSW4gdGhlIGNhc2Ugb2YgdGhlIERldE5ldCBNUExTIGRhdGEgcGxhbmUsIG1hbmFnZSBE ZXROZXQgUy1MYWJlbCBhbmQgRi1MYWJlbCBhbGxvY2F0aW9uIGFuZCBkaXN0cmlidXRpb24uCgot IEFsc28gaW4gdGhlIGNhc2Ugb2YgdGhlIERldE5ldCBNUExTIGRhdGEgcGxhbmUsIHN1cHBvcnQg cGFja2V0IHJlcGxpY2F0aW9uLCBkdXBsaWNhdGUgZWxpbWluYXRpb24sIGFuZCBwYWNrZXQgb3Jk ZXJpbmcgZnVuY3Rpb25zIChQUkVPRiksIGFuZCB0byBiZSBhYmxlIHRvIHBsYWNlIHRoZXNlIGZ1 bmN0aW9ucyBhdCBhcHByb3ByaWF0ZSBwbGFjZXMgaW4gdGhlIG5ldHdvcmsuCgotIFN1cHBvcnQg YXBwbGljYXRpb25zIHRoYXQgcmVxdWlyZSB0aGUgYWJpbGl0eSB0byBzeW5jaHJvbml6ZSB0aGUg Y2xvY2tzIGluIGVuZCBzeXN0ZW1zIHRvIHRoZSBleHRlbnQgc3VwcG9ydGVkIGJ5IHRoZSBEZXRO ZXQgZGF0YSBwbGFuZS4KCi0gU3VwcG9ydCBxdWV1ZSBjb250cm9sIHRlY2huaXF1ZXMgZGVmaW5l ZCBpbiBTZWN0aW9uIDQuNSBvZiB7eyFJLUQuaWV0Zi1kZXRuZXQtYXJjaGl0ZWN0dXJlfX0gYW5k IHt7P0ktRC5maW5uLWRldG5ldC1ib3VuZGVkLWxhdGVuY3l9fSB0aGF0IHJlcXVpcmUgdGltZSBz eW5jaHJvbml6YXRpb24gYW1vbmcgbmV0d29yayBub2Rlcy4KCi0gQWR2ZXJ0aXNlIHN0YXRpYyBh bmQgZHluYW1pYyBub2RlIGFuZCBsaW5rIHJlc291cmNlcyBzdWNoIGFzIGNhcGFiaWxpdGllcyBh bmQgYWRqYWNlbmNpZXMgdG8gb3RoZXIgbmV0d29yayBub2RlcyAoZm9yIGR5bmFtaWMgc2lnbmFs aW5nIGFwcHJvYWNoZXMpIG9yIHRvIG5ldHdvcmsgY29udHJvbGxlcnMgKGZvciBjZW50cmFsaXpl ZCBhcHByb2FjaGVzKS4KCi0gQWRhcHQgdG8gbmV0d29yayB0b3BvbG9neSBjaGFuZ2VzIHN1Y2gg YXMgbGlua3Mgb3Igbm9kZXMgZmFpbHVyZXMuCgotIFNjYWxlIHRvIGhhbmRsZSB0aGUgbnVtYmVy IG9mIERldE5ldCBmbG93cyBleHBlY3RlZCBpbiBhIGRvbWFpbiAod2hpY2ggbWF5IHJlcXVpcmUg cGVyLWZsb3cgc2lnbmFsaW5nIG9yIHByb3Zpc2lvbmluZykuIFRoaXMgaXMgc2ltaWxhciB0byBz Y2FsYWJpbGl0eSByZXF1aXJlbWVudHMgYXNzb2NpYXRlZCB3aXRoIG5ldHdvcmsgc2xpY2luZyB7 ez9JLUQuZG9uZy1zcHJpbmctc3ItZm9yLWVuaGFuY2VkLXZwbn19LgoKLSBQcm92aXNpb24gZmxv dyBpZGVudGlmaWNhdGlvbiBpbmZvcm1hdGlvbiBhdCBlYWNoIG9mIHRoZSBub2RlcyBhbG9uZyB0 aGUgcGF0aC4gIEZsb3cgaWRlbnRpZmljYXRpb24gbWF5IGRpZmZlciBkZXBlbmRpbmcgb24gdGhl IGxvY2F0aW9uIGluIHRoZSBuZXR3b3JrIGFuZCB0aGUgRGV0TmV0IGZ1bmN0aW9uYWxpdHkgKGUu Zy4gdHJhbnNpdCBub2RlIHZzLiByZWxheSBub2RlKS4KCi0gTW9uaXRvciB0aGUgcGVyZm9ybWFu Y2Ugb2YgRGV0TmV0IGZsb3dzIHRvIGVuc3VyZSB0aGF0IHRoZXkgYXJlIG1lZXRpbmcgcmVxdWly ZWQgb2JqZWN0aXZlcy4KCiMgRGV0TmV0IENvbnRyb2wgUGxhbmUgQXJjaGl0ZWN0dXJlIHsjY29u dHJvbC1wbGFuZS1hcmNoaXRlY3R1cmV9CgpBcyBub3RlZCBpbiB0aGUgSW50cm9kdWN0aW9uLCB0 aGUgRGV0TmV0IGNvbnRyb2wgcGxhbmUgaXMgcmVzcG9uc2libGUgZm9yIHRoZSBpbnN0YW50aWF0 aW9uIGFuZCBtYWludGVuYW5jZSBvZiAgZmxvd3MsIE1QTFMgbGFiZWwgYWxsb2NhdGlvbiBhbmQg ZGlzdHJpYnV0aW9uLCBhbmQgYWN0aXZlIGluLWJhbmQgb3Igb3V0LW9mLWJhbmQgc2lnbmFsaW5n IHRvIHN1cHBvcnQgdGhlc2UgZnVuY3Rpb25zLgoKVGhlIGZvbGxvd2luZyBzZWN0aW9ucyBkZWZp bmUgdGhyZWUgcG9zc2libGUgY2xhc3NlcyBvZiBEZXROZXQgY29udHJvbCBwbGFuZSBhcmNoaXRl Y3R1cmVzOiBhIGZ1bGx5IGRpc3RyaWJ1dGVkIGNvbnRyb2wgcGxhbmUgdXRpbGl6aW5nIGR5bmFt aWMgc2lnbmFsaW5nIHByb3RvY29scywgYSBmdWxseSBjZW50cmFsaXplZCBTRE4tbGlrZSBjb250 cm9sIHBsYW5lLCBhbmQgYSBoeWJyaWQgY29udHJvbCBwbGFuZS4gVGhleSBkaXNjdXNzIHRoZSB2 YXJpb3VzIGluZm9ybWF0aW9uIGV4Y2hhbmdlcyBiZXR3ZWVuIGVudGl0aWVzIGluIHRoZSBuZXR3 b3JrIGluIGVhY2ggb2YgdGhlc2UgYXJjaGl0ZWN0dXJlcyBhbmQgdGhlIGFkdmFudGFnZXMgYW5k IGRpc2FkdmFudGFnZXMgb2YgZWFjaCBvcHRpb24uCgpJbiBlYWNoIG9mIHRoZSBmb2xsb3dpbmcg c2VjdGlvbnMsIGV4YW1wbGVzIGFyZSB1c2VkIHRvIGlsbHVzdHJhdGUgcG9zc2libGUgbWVjaGFu aXNtcyB0aGF0IGNvdWxkIGJlIHVzZWQgaW4gZWFjaCBvZiB0aGUgYXJjaGl0ZWN0dXJlcy4gVGhl c2UgYXJlIG5vdCBtZWFudCB0byBiZSBleGhhdXN0aXZlIG9yIHRvIHByZWNsdWRlIGFueSBvdGhl ciBwb3NzaWJsZSBtZWNoYW5pc20gdGhhdCBjb3VsZCBiZSB1c2VkIGluIHBsYWNlIG9mIHRob3Nl IHVzZWQgaW4gdGhlIGV4YW1wbGVzLgoKIyMgRGlzdHJpYnV0ZWQgQ29udHJvbCBQbGFuZSBhbmQg U2lnbmFsaW5nIFByb3RvY29scyB7I2Rpc3RyaWJ1dGVkLWNvbnRyb2wtcGxhbmV9CgpJbiBhIGZ1 bGx5IGRpc3RyaWJ1dGVkIGNvbmZpZ3VyYXRpb24gbW9kZWwsIFVzZXItdG8tTmV0d29yayBJbnRl cmZhY2UgKFVOSSkgaW5mb3JtYXRpb24gaXMgdHJhbnNtaXR0ZWQgb3ZlciBhICh0by1iZS1kZWZp bmVkKSBEZXROZXQgVU5JIHByb3RvY29sIGZyb20gdGhlIHVzZXIgc2lkZSB0byB0aGUgbmV0d29y ayBzaWRlLCBhbmQgdGhlbiBVTkkgYW5kIG5ldHdvcmsgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlv biBwcm9wYWdhdGUgaW4gdGhlIG5ldHdvcmsgdmlhIGRpc3RyaWJ1dGVkIGNvbnRyb2wgcGxhbmUg c2lnbmFsaW5nIHByb3RvY29scy4gVXNpbmcgYW4gUlNWUC1URSB0cmFmZmljLWVuZ2luZWVyZWQg TVBMUyBuZXR3b3JrIGFzIGFuIGV4YW1wbGU6CgoxLiBBbiBJR1AgY29sbGVjdHMgdG9wb2xvZ3kg aW5mb3JtYXRpb24gYW5kIERldE5ldCBjYXBhYmlsaXRpZXMgb2YgdGhlIG5ldHdvcmsgXFtkcmFm dC1nZW5nLWRldG5ldC1pbmZvLWRpc3RyaWJ1dGlvblxdOwoKMi4gVGhlIGNvbnRyb2wgcGxhbmUg b2YgdGhlIGluZ3Jlc3MgZWRnZSBub2RlIHJlY2VpdmVzIGEgZmxvdyBlc3RhYmxpc2htZW50IHJl cXVlc3QgZnJvbSB0aGUgVU5JIGFuZCBjYWxjdWxhdGVzIG9uZSBvciBtb3JlIHZhbGlkIHBhdGgo cyk7CgozLiBVc2luZyBSU1ZQLVRFIHt7P1JGQzMyMDl9fSwgdGhlIGluZ3Jlc3MgZWRnZSBub2Rl IHNlbmRzIGEgUEFUSCBtZXNzYWdlIHdpdGggYW4gZXhwbGljaXQgcm91dGUuIEFmdGVyIHJlY2Vp dmluZyB0aGUgUEFUSCBtZXNzYWdlLCB0aGUgZWdyZXNzIGVkZ2Ugbm9kZSBzZW5kcyBhIFJFU1Yg bWVzc2FnZSB3aXRoIHRoZSBkaXN0cmlidXRlZCBsYWJlbCBhbmQgcmVzb3VyY2UgcmVzZXJ2YXRp b24gcmVxdWVzdC4KCkN1cnJlbnQgcmVzZXJ2YXRpb24tb3JpZW50ZWQgZGlzdHJpYnV0ZWQgY29u dHJvbCBwbGFuZSBwcm90b2NvbHMsIGUuZy4gUlNWUC1URSBhbmQgU3RyZWFtIFJlc2VydmF0aW9u IFByb3RvY29sIChTUlApIHt7P0lFRUUuODAyLjFRY2MtMjAxOH19LCBjYW4gb25seSByZXNlcnZl IGJhbmR3aWR0aCBhbG9uZyB0aGUgcGF0aCwgd2hpbGUgdGhlIGNvbmZpZ3VyYXRpb24gb2YgYSBm aW5lLWdyYWluZWQgc2NoZWR1bGUsIGUuZy4sIFRpbWUgQXdhcmUgU2hhcGluZyAoVEFTKSB7ez9J RUVFLjgwMi4xUUJWXzIwMTV9fSwgaXMgbm90IHN1cHBvcnRlZC4gSWYgUlNWUC1URSBvciBTUlAg d2VyZSB0byBiZSB1c2VkIGZvciBhIERldE5ldCBhcHBsaWNhdGlvbiwgaXQgd291bGQgcmVxdWly ZSBleHRlbnNpb25zIGluIG9yZGVyIHRvIHN1cHBvcnQgcXVldWUgYW5kIHNjaGVkdWxlciByZXNl cnZhdGlvbnMgaW4gYWRkaXRpb24gdG8gYmFuZHdpZHRoIHJlc2VydmF0aW9uLgoKQXMgZGlzY3Vz c2VkIGluIFNlY3Rpb24gNC45IG9mIHt7IUktRC5pZXRmLWRldG5ldC1hcmNoaXRlY3R1cmV9fSwg c2NhbGFiaWxpdHkgaXMgYSBwcmltYXJ5IGNvbmNlcm4gZm9yIERldE5ldCwgZ2l2ZW4gdGhlIGxh cmdlIG51bWJlciBvZiBleHBlY3RlZCBmbG93cyBpbiBhIERldE5ldCBkb21haW4uIFRoaXMgY291 bGQgcG90ZW50aWFsbHkgYmUgbXVjaCBsYXJnZXIgdGhhbiwgZm9yIGV4YW1wbGUsIHRoZSBudW1i ZXIgb2YgTVBMUyB0cmFmZmljIHR1bm5lbHMgaW4gYSBuZXR3b3JrIHVzaW5nIE1QTFMgdHJhZmZp YyBlbmdpbmVlcmluZywgd2hpY2ggd291bGQgdHlwaWNhbGx5IGJlIE4qKE4tMSkgdHVubmVscywg d2hlcmUgTiBpcyB0aGUgbnVtYmVyIG9mIGVkZ2Ugcm91dGVycyBpbiB0aGUgZG9tYWluLgoKRXZl biB3aGVuIGZsb3cgYWdncmVnYXRpb24gaXMgdXNlZCwgRGV0TmV0IGRvbWFpbnMgY2FuIGJlIGV4 cGVjdGVkIHRvIHN1cHBvcnQgYSB2ZXJ5IGxhcmdlIG51bWJlciBvZiBmbG93cyB0aGF0IHdpbGwg bmVlZCBwYXJ0aWN1bGFyIHF1ZXVpbmcgZGlzY2lwbGluZXMgYW5kL29yIHJlc291cmNlIGFsbG9j YXRpb24sIGRlcGVuZGluZyBvbiB0aGUgcmVxdWlyZW1lbnRzIGZvciBlYWNoIGZsb3cuIFRoaXMg Y291bGQgcmVxdWlyZSBhIGxhcmdlIGFtb3VudCBvZiBkeW5hbWljIHNpZ25hbGluZywgc3VjaCBh cyBhbiBSU1ZQLVRFIHNlc3Npb24gdG8gZXN0YWJsaXNoIGFuZCBtYWludGFpbiBlYWNoIGZsb3cu IE90aGVyIFJTVlAtVEUgc2NhbGFiaWxpdHkgY29uY2VybnMgYXJlIGZ1cnRoZXIgZGlzY3Vzc2Vk IGluIHt7P1JGQzU0Mzl9fS4KCkFsbCBvZiB0aGUgYWJvdmUgdGVuZHMgdG8gYXJndWUgYWdhaW5z dCBhIHB1cmVseSBkaXN0cmlidXRlZCBjb250cm9sIHBsYW5lIGZvciBEZXROZXQgZG9tYWlucy4K CiMjIFNETi9GdWxseSBDZW50cmFsaXplZCBDb250cm9sIFBsYW5lCgpJbiB0aGUgZnVsbHkgU0RO L2NlbnRyYWxpemVkIGNvbmZpZ3VyYXRpb24gbW9kZWwsIFVOSSBpbmZvcm1hdGlvbiBpcyB0cmFu c21pdHRlZCBmcm9tIGEgQ2VudHJhbGl6ZWQgVXNlciBDb25maWd1cmF0aW9uIChDVUMpIG9yIGZy b20gYXBwbGljYXRpb25zIHZpYSBhbiBBUEkgb3Igbm9ydGhib3VuZCBpbnRlcmZhY2UgdG8gYSBD ZW50cmFsaXplZCBDb250cm9sbGVyLCB3aGljaCBpcyB0aGUgc29sZSBzb3VyY2Ugb2Ygcm91dGlu ZyBhbmQgZm9yd2FyZGluZyBpbmZvcm1hdGlvbiBmb3IgdGhlIGRvbWFpbi4gQ29uZmlndXJhdGlv bnMgb2Ygbm9kZXMgZm9yIERldE5ldCBmbG93cyBhcmUgcGVyZm9ybWVkIGJ5IHRoZSBjb250cm9s bGVyIHVzaW5nIGEgcHJvdG9jb2wgc3VjaCBhcyBORVRDT05GIHt7P1JGQzYyNDF9fS9ZQU5HIHt7 P1JGQzYwMjB9fSBvciBQQ0UtQ0Mge3s/UkZDODI4M319LiBGb3IgZXhhbXBsZToKCjEuIFRoZSBj b250cm9sbGVyIGNvbGxlY3RzIHRvcG9sb2d5IGluZm9ybWF0aW9uIGFuZCBEZXROZXQgY2FwYWJp bGl0aWVzIG9mIHRoZSBuZXR3b3JrIHZpYSBORVRDT05GL1lBTkc7CgoyLiBUaGUgY29udHJvbGxl ciByZWNlaXZlcyBhIGZsb3cgZXN0YWJsaXNobWVudCByZXF1ZXN0IGZyb20gYSBVTkkgYW5kIGNh bGN1bGF0ZXMgb25lIG9yIG1vcmUgdmFsaWQgcGF0aChzKSB0aHJvdWdoIHRoZSBuZXR3b3JrOwoK My4gVGhlIGNvbnRyb2xsZXIgY2hvb3NlcyB0aGUgb3B0aW1hbCBwYXRoIGFuZCBjb25maWd1cmVz IHRoZSBkZXZpY2VzIGFsb25nIHRoYXQgcGF0aCBmb3IgZmxvdyB0cmFuc21pc3Npb24gdmlhIFBD RS1DQy4KCiMjIEh5YnJpZCBDb250cm9sIFBsYW5lCgpJbiB0aGUgaHlicmlkIG1vZGVsLCBhIGNv bnRyb2xsZXIgYW5kIGNvbnRyb2wgcGxhbmUgcHJvdG9jb2xzIHdvcmsgdG9nZXRoZXIgdG8gcHJv dmlkZSBEZXROZXQgc2VydmljZXMsIGFuZCB0aGVyZSBhcmUgYSBudW1iZXIgb2YgcG9zc2libGUg Y29tYmluYXRpb25zLiBGb3IgZXhhbXBsZToKCjEuIEEgQ2VudHJhbGl6ZWQgQ29udHJvbGxlciBj b2xsZWN0cyB0b3BvbG9neSBpbmZvcm1hdGlvbiBhbmQgRGV0TmV0IGNhcGFiaWxpdGllcyBvZiB0 aGUgbmV0d29yayB2aWEgYW4gSUdQIGFuZC9vciBCR1AtTFMge3s/UkZDNzc1Mn19OwoKMi4gVGhl IGNvbnRyb2xsZXIgcmVjZWl2ZXMgYSBmbG93IGVzdGFibGlzaG1lbnQgcmVxdWVzdCBmcm9tIGEg VU5JIGFuZCBjYWxjdWxhdGVzIG9uZSBvciBtb3JlIHZhbGlkIHBhdGgocykgdGhyb3VnaCB0aGUg bmV0d29yazsKCjMuIEJhc2VkIG9uIHRoZSBjYWxjdWxhdGlvbiByZXN1bHQsIHRoZSBDTkMgZGlz dHJpYnV0ZXMgZmxvdyBwYXRoIGluZm9ybWF0aW9uIHRvIHRoZSBpbmdyZXNzIGVkZ2Ugbm9kZSBh bmQgb3RoZXIgaW5mb3JtYXRpb24gKGUuZy4gcmVwbGljYXRpb24vZHVwbGljYXRlIGVsaW1pbmF0 aW9uKSB0byB0aGUgcmVsZXZhbnQgbm9kZXMuCgo0LiBVc2luZyBSU1ZQLVRFLCB0aGUgaW5ncmVz cyBlZGdlIG5vZGUgc2VuZHMgYSBQQVRIIG1lc3NhZ2Ugd2l0aCBhbiBleHBsaWNpdCByb3V0ZS4g QWZ0ZXIgcmVjZWl2aW5nIHRoZSBQQVRIIG1lc3NhZ2UsIHRoZSBlZ3Jlc3MgZWRnZSBub2RlIHNl bmRzIGEgUkVTViBtZXNzYWdlIHdpdGggdGhlIGRpc3RyaWJ1dGVkIGxhYmVsIGFuZCByZXNvdXJj ZSByZXNlcnZhdGlvbiByZXF1ZXN0LgoKb3IKCjEuIFRoZSBjb250cm9sbGVyIGNvbGxlY3RzIHRv cG9sb2d5IGluZm9ybWF0aW9uIGFuZCBEZXROZXQgY2FwYWJpbGl0eSBvZiB0aGUgbmV0d29yayB2 aWEgYW4gSUdQIG9yIEJHUC1MUzsKCjIuIFRoZSBjb250cm9sIHBsYW5lIG9mIHRoZSBpbmdyZXNz IGVkZ2Ugbm9kZSByZWNlaXZlcyBhIGZsb3cgZXN0YWJsaXNobWVudCByZXF1ZXN0IHZpYSBhIFVO STsKCjMuIFRoZSBJbmdyZXNzIGVkZ2Ugbm9kZSBzZW5kcyB0aGUgcGF0aCBlc3RhYmxpc2htZW50 IHJlcXVlc3QgdG8gdGhlIGNvbnRyb2xsZXIgdGhyb3VnaCBQQ0VQIHt7P1JGQzU0NDB9fTsKCjQu IEFmdGVyIHBhdGggY2FsY3VsYXRpb24sIHRoZSBDTkMgc2VuZHMgdGhlIHBhdGggaW5mb3JtYXRp b24gb2YgdGhlIGZsb3cgdG8gdGhlIGluZ3Jlc3MgZWRnZSBub2RlIHZpYSBQQ0VQOwoKNS4gVXNp bmcgUlNWUC1URSwgdGhlIGluZ3Jlc3MgZWRnZSBub2RlIHNlbmRzIGEgUEFUSCBtZXNzYWdlIHdp dGggYW4gZXhwbGljaXQgcm91dGUuIEFmdGVyIHJlY2VpdmluZyB0aGUgUEFUSCBtZXNzYWdlLCB0 aGUgZWdyZXNzIGVkZ2Ugbm9kZSBzZW5kcyBhIFJFU1YgbWVzc2FnZSB3aXRoIHRoZSBkaXN0cmli dXRlZCBsYWJlbCBhbmQgcmVzb3VyY2UgcmVzZXJ2YXRpb24gcmVxdWVzdC4KClRoZXJlIGFyZSBt YW55IG90aGVyIHZhcmlhdGlvbnMgdGhhdCBjb3VsZCBiZSBpbmNsdWRlZCBpbiBhIGh5YnJpZCBj b250cm9sIHBsYW5lLiBUaGlzIGRvY3VtZW50IGNhbm5vdCBkaXNjdXNzIGFsbCB0aGUgcG9zc2li bGUgY29udHJvbCBwbGFuZSBtZWNoYW5pc21zIHRoYXQgY291bGQgYmUgdXNlZCBpbiBoeWJyaWQg Y29uZmlndXJhdGlvbiBtb2RlbHMuIEV2ZXJ5IHNvbHV0aW9uIGhhcyBpdHMgb3duIG1lY2hhbmlz bXMgYW5kIGNvcnJlc3BvbmRpbmcgcGFyYW1ldGVycyB0aGF0IGFyZSByZXF1aXJlZCBmb3IgaXQg dG8gd29yay4KCiMgRGV0TmV0IENvbnRyb2wgUGxhbmUgQWRkaXRpb25hbCBEZXRhaWxzIGFuZCBJ c3N1ZXMKClRoaXMgc2VjdGlvbiBkaXNjdXNzZXMgc29tZSBhZGRpdGlvbmFsIERldE5ldCBjb250 cm9sIHBsYW5lIGRldGFpbHMgYW5kIGlzc3Vlcy4KCiMjIEV4cGxpY2l0IFBhdGhzCgpFeHBsaWNp dCBwYXRocyBhcmUgcmVxdWlyZWQgaW4gRGV0TmV0IHRvIHByb3ZpZGUgYSBzdGFibGUgdHJhbnNw b3J0IHNlcnZpY2UgYW5kIGd1YXJhbnRlZSB0aGF0IERldE5ldCBzZXJ2aWNlIGlzIG5vdCBlZmZl Y3RlZCB3aGVuIHRoZSBuZXR3b3JrIHRvcG9sb2d5IGNoYW5nZXMuIFRoZSBmb2xsb3dpbmcgZmVh dHVyZXMgYXJlIG5lY2Vzc2FyeSB0byBoYXZlIGV4cGxpY2l0IHBhdGhzIGluIERldE5ldDoKCi0g UGF0aCBjb21wdXRhdGlvbjogRGV0TmV0IGV4cGxpY2l0IHBhdGhzIG5lZWQgdG8gbWVldCB0aGUg U0xBIChTZXJ2aWNlIExldmVsIEFncmVlbWVudCkgcmVxdWlyZW1lbnRzIGFuZC9vciByZXNvdXJj ZSBndWFyYW50ZWVzIGZyb20gdGhlIGFwcGxpY2F0aW9uL2NsaWVudCwgd2hpY2ggaW5jbHVkZSBi YW5kd2lkdGgsIG1heGltdW0gZW5kLXRvLWVuZCBkZWxheSwgbWF4aW11bSBlbmQtdG8tZW5kIGRl bGF5IHZhcmlhdGlvbiwgbWF4aW11bSBsb3NzIHJhdGlvLCBldGMuIEluIGFuIGRpc3RyaWJ1dGVk IHN5c3RlbSB3aXRoIElHUC1URSwgQ1NQRiAoQ29uc3RyYWluZWQgU2hvcnRlc3QgUGF0aCBGaXJz dCkgY2FuIGJlIHVzZWQgdG8gY29tcHV0ZSBhIHNldCBvZiBmZWFzaWJsZSBwYXRocyBmb3IgYSBE ZXROZXQgc2VydmljZS4gSW4gYSBzeXN0ZW0gd2l0aCBhIG5ldHdvcmsgY29udHJvbGxlciwgYSBQ Q0UgKFBhdGggQ29tcHV0YXRpb24gRW5naW5lKSBjYW4gY29tcHV0ZSBwYXRocyBzYXRpc2Z5aW5n IHRoZSByZXF1aXJlbWVudHMgb2YgRGV0TmV0IHdpdGggdGhlIG5ldHdvcmsgaW5mb3JtYXRpb24g Y29sbGVjdGVkIGZyb20gdGhlIERldE5ldCBkb21haW4uCgotIFBhdGggZXN0YWJsaXNobWVudDog T25jZSB0aGUgcGF0aCBoYXMgYmVlbiBjb21wdXRlZCwgdGhlIG9wdGlvbnMgZGlzY3Vzc2VkIGlu IHt7Y29udHJvbC1wbGFuZS1hcmNoaXRlY3R1cmV9fSBjYW4gYmUgdXNlZCB0byBlc3RhYmxpc2gg dGhlIHBhdGguIEFsc28gc2VlIHt7dHJhZGl0aW9uYWwtbXBsc319IGFuZCB7e1NSfX0gZm9yIHNv bWUgYWRkaXRpb25hbCBjb25zaWRlcmF0aW9ucyBkZXBlbmRpbmcgb24gdGhlIGRldGFpbHMgb2Yg dGhlIG5ldHdvcmsgaW5mcmFzdHJ1Y3R1cmUuCgotIFN0cmljdCBvciBsb29zZSBwYXRoczogQW4g ZXhwbGljaXQgcGF0aCBpcyBzdHJpY3Qgd2hlbiBldmVyeSBpbnRlcm1lZGlhdGUgaG9wIGlzIHNw ZWNpZmllZCBzbyB0aGF0IGl0cyByb3V0ZSBjYW4ndCBjaGFuZ2UuIEFuIGV4cGxpY2l0IHBhdGgg aXMgbG9vc2Ugd2hlbiBhbnkgSUdQIHJvdXRlIGlzIGFsbG93ZWQgYWxvbmcgdGhlIHBhdGguIEdl bmVyYWxseSwgZW5kLXRvLWVuZCBTTEEgZ3VhcmFudGVlcyByZXF1aXJlIGEgc3RyaWN0IGV4cGxp Y2l0IHBhdGggaW4gRGV0TmV0LiBIb3dldmVyLCB3aGVuIHRoZSBJR1Agcm91dGUgaXMga25vd24g dG8gYmUgYWJsZSB0byBtZWV0IHRoZSBTTEEgcmVxdWlyZW1lbnRzLCBsb29zZSBleHBsaWNpdCBw YXRocyBhcmUgYWxzbyBhY2NlcHRhYmxlLgoKIyMgUmVzb3VyY2UgUmVzZXJ2YXRpb24KCk5ldHdv cmsgY29uZ2VzdGlvbiBjb3VsZCBjYXVzZSB1bmNvbnRyb2xsZWQgZGVsYXkgYW5kL29yIHBhY2tl dCBsb3NzLiBEZXROZXQgZmxvd3MgYXJlIHN1cHBvc2VkIHRvIGJlIHByb3RlY3RlZCBmcm9tIGNv bmdlc3Rpb24sIHNvIHN1ZmZpY2llbnQgcmVzb3VyY2UgcmVzZXJ2YXRpb24gZm9yIERldE5ldCBz ZXJ2aWNlIGlzIG5lY2Vzc2FyeS4gUmVzb3VyY2VzIGluIHRoZSBuZXR3b3JrIGFyZSBjb21wbGV4 IGFuZCBoYXJkIHRvIHF1YW50aXplLCBhbmQgbWF5IGluY2x1ZGUgc3VjaCBlbnRpdGllcyBhcyBw YWNrZXQgcHJvY2Vzc2luZyByZXNvdXJjZXMsIHBhY2tldCBidWZmZXJpbmcsIHBvcnQgYW5kIGxp bmsgYmFuZHdpZHRoLCBhbmQgc28gb24uIFRoZSByZXNvdXJjZXMgYSBwYXJ0aWN1bGFyIGZsb3cg cmVxdWlyZXMgYXJlIGRldGVybWluZWQgYnkgdGhlIGZsb3cncyBjaGFyYWN0ZXJpc3RpY3MgYW5k IFNMQS4KCi0gUmVzb3VyY2UgQWxsb2NhdGlvbjogUG9ydCBiYW5kd2lkdGggaXMgb25lIG9mIHRo ZSBiYXNpYyBhdHRyaWJ1dGVzIG9mIGEgbmV0d29yayBkZXZpY2Ugd2hpY2ggaXMgZWFzeSB0byBv YnRhaW4gb3IgY2FsY3VsYXRlLiBJbiBjdXJyZW50IHRyYWZmaWMgZW5naW5lZXJpbmcgaW1wbGVt ZW50YXRpb25zLCBuZXR3b3JrIHJlc291cmNlIGFsbG9jYXRpb24gaXMgc3lub255bW91cyB3aXRo IGJhbmR3aWR0aCBhbGxvY2F0aW9uLiBBIERldE5ldCBmbG93IGlzIGNoYXJhY3Rlcml6ZWQgd2l0 aCBhIHRyYWZmaWMgc3BlY2lmaWNhdGlvbiBhcyBkZWZpbmVkIGluIHt7IUktRC5pZXRmLWRldG5l dC1mbG93LWluZm9ybWF0aW9uLW1vZGVsfX0sIGluY2x1ZGluZyBhdHRyaWJ1dGVzIHN1Y2ggYXMg SW50ZXJ2YWwsIE1heGltdW0gUGFja2V0cyBQZXIgSW50ZXJ2YWwsIGFuZCBNYXhpbXVtIFBheWxv YWQgU2l6ZS4gVGhlIHRyYWZmaWMgc3BlY2lmaWNhdGlvbiBkZXNjcmliZXMgdGhlIHdvcnN0IGNh c2UsIHJhdGhlciB0aGFuIHRoZSBhdmVyYWdlIGNhc2UsIGZvciB0aGUgdHJhZmZpYywgdG8gZW5z dXJlIHRoYXQgc3VmZmljaWVudCBiYW5kd2lkdGggYW5kIGJ1ZmZlcmluZyByZXNvdXJjZXMgYXJl IHJlc2VydmVkIHRvIHNhdGlzZnkgdGhlIHRyYWZmaWMgc3BlY2lmaWNhdGlvbi4KCi0gRGV2aWNl IGNvbmZpZ3VyYXRpb24gd2l0aCBvciB3aXRob3V0IGZsb3cgZGlzY3JpbWluYXRpb246IFRoZSBy ZXNvdXJjZSBhbGxvY2F0aW9uIGNhbiBiZSBndWFyYW50ZWVkIGJ5IGRldmljZSBjb25maWd1cmF0 aW9uLiBGb3IgZXhhbXBsZSwgYW4gb3V0cHV0IHBvcnQgYmFuZHdpZHRoIHJlc2VydmF0aW9uIGNh biBiZSBjb25maWd1cmVkIGFzIGEgcGFyYW1ldGVyIG9mIHF1ZXVlIG1hbmFnZW1lbnQgYW5kIHRo ZSBwb3J0IHNjaGVkdWxpbmcgYWxnb3JpdGhtLiBXaGVuICBEZXROZXQgZmxvd3MgYXJlIGFnZ3Jl Z2F0ZWQsIGEgZ3JvdXAgb2YgRGV0TmV0IGZsb3dzIHNoYXJlIHRoZSBhbGxvY2F0ZWQgcmVzb3Vy Y2UgaW4gdGhlIG5ldHdvcmsgZGV2aWNlLiBXaGVuIHRoZSBEZXROZXQgZmxvd3MgYXJlIHRyZWF0 ZWQgaW5kZXBlbmRlbnRseSwgdGhlIGRldmljZSBzaG91bGQgbWFpbnRhaW5zIGEgbWFwcGluZyBy ZWxhdGlvbnNoaXAgYmV0d2VlbiBhIERldE5ldCBmbG93IGFuZCBpdHMgY29ycmVzcG9uZGluZyBy ZXNvdXJjZXMuCgojIyBQUkVPRiBTdXBwb3J0CgpEZXROZXQgcGF0aCByZWR1bmRhbmN5IGlzIHN1 cHBvcnRlZCB2aWEgcGFja2V0IHJlcGxpY2F0aW9uIGFuZCBkdXBsaWNhdGUgZWxpbWluYXRpb24g KFBSRU9GKS4gQSBEZXROZXQgZmxvdyBpcyByZXBsaWNhdGVkIGFuZCBnb2VzIHRocm91Z2ggbXVs dGlwbGUgbmV0d29ya3MgcGF0aHMgdG8gYXZvaWQgcGFja2V0IGxvc3MgY2F1c2VkIGJ5IGRldmlj ZSBvciBsaW5rIGZhaWx1cmVzLiAgSW4gZ2VuZXJhbCwgY3VycmVudCBjb250cm9sIHBsYW5lIG1l Y2hhbmlzbXMgdGhhdCBjYW4gYmUgdXNlZCB0byBlc3RhYmxpc2ggYW4gZXhwbGljaXQgcGF0aCwg d2hldGhlciBkaXN0cmlidXRlZCBvciBjZW50cmFsaXplZCwgc3VwcG9ydCBwb2ludC10by1wb2lu dCAoUDJQKSBhbmQgcG9pbnQtdG8tbXVsdGlwb2ludCAoUDJNUCkgcGF0aCBlc3RhYmxpc2htZW50 LiBQUkVPRiByZXF1aXJlcyB0aGUgYWJpbGl0eSB0byBjb21wdXRlIGFuZCBlc3RhYmxpc2ggYSBw b2ludC10by1tdWx0aXBvaW50LXRvLXBvaW50IChQMk1QMlApIHBhdGguIFByb3RvY29sIGV4dGVu c2lvbnMgd2lsbCBiZSByZXF1aXJlZCB0byBzdXBwb3J0IHRoaXMgbmV3IGZlYXR1cmUuCgojIyBE ZXROZXQgaW4gYSBUcmFkaXRpb25hbCBNUExTIERvbWFpbiB7I3RyYWRpdGlvbmFsLW1wbHN9CgpG b3IgdGhlIHB1cnBvc2VzIG9mIHRoaXMgZG9jdW1lbnQsICJ0cmFkaXRpb25hbCBNUExTIiBpcyBk ZWZpbmVkIGFzIE1QTFMgd2l0aG91dCB0aGUgdXNlIG9mIHNlZ21lbnQgcm91dGluZyAoc2VlIHt7 U1J9fSBmb3IgYSBkaXNjdXNzaW9uIG9mIE1QTFMgd2l0aCBzZWdtZW50IHJvdXRpbmcpIG9yIE1Q TFMtVFAge3s/UkZDNTk2MH19LgoKSW4gdHJhZGl0aW9uYWwgTVBMUyBkb21haW5zLCBhIGR5bmFt aWMgY29udHJvbCBwbGFuZSB1c2luZyBkaXN0cmlidXRlZCBzaWduYWxpbmcgcHJvdG9jb2xzIGlz IHR5cGljYWxseSB1c2VkIGZvciB0aGUgZGlzdHJpYnV0aW9uIG9mIE1QTFMgbGFiZWxzIHVzZWQg Zm9yIGZvcndhcmRpbmcgTVBMUyBwYWNrZXRzLiBUaGUgZHluYW1pYyBzaWduYWxpbmcgcHJvdG9j b2xzIG1vc3QgY29tbW9ubHkgdXNlZCBmb3IgbGFiZWwgZGlzdHJpYnV0aW9uIGFyZSBMRFAge3s/ UkZDNTAzNn19LCBSU1ZQLVRFLCBhbmQgQkdQIHt7P1JGQzgyNzd9fSAod2hpY2ggZW5hYmxlcyBC R1AvTVBMUy1iYXNlZCBMYXllciAzIFZQTnMge3s/UkZDNDM4NH19IGFuZCBMYXllciAyIFZQTnMg e3s/UkZDNzQzMn19KS4KCkFueSBvZiB0aGVzZSBwcm90b2NvbHMgY291bGQgYmUgdXNlZCB0byBk aXN0cmlidXRlIERldE5ldCBTZXJ2aWNlIExhYmVscyAoUy1MYWJlbHMpIGFuZCBBZ2dyZWdhdGlv biBMYWJlbHMgKEEtTGFiZWxzKXt7IUktRC5pZXRmLWRldG5ldC1tcGxzfX0uIEFzIGRpc2N1c3Nl ZCBpbiB7eyFJLUQuaWV0Zi1kZXRuZXQtZGF0YS1wbGFuZS1mcmFtZXdvcmt9fSwgUy1MYWJlbHMg YXJlIHNpbWlsYXIgdG8gb3RoZXIgTVBMUyBzZXJ2aWNlIGxhYmVscywgc3VjaCBhcyBwc2V1ZG93 aXJlLCBMMyBWUE4sIGFuZCBMMiBWUE4gbGFiZWxzLCBhbmQgY291bGQgYmUgZGlzdHJpYnV0ZWQg aW4gYSBzaW1pbGFyIG1hbm5lciwgc3VjaCBhcyB0aHJvdWdoIHRoZSB1c2Ugb2YgdGFyZ2V0ZWQg TERQIG9yIEJHUC4gSWYgdGhlc2Ugd2VyZSB0byBiZSB1c2VkIGZvciBEZXROZXQsIHRoZXkgd291 bGQgcmVxdWlyZSBleHRlbnNpb25zIHRvIHN1cHBvcnQgRGV0TmV0LXNwZWNpZmljIGZlYXR1cmVz IHN1Y2ggYXMgUFJFT0YsIGFnZ3JlZ2F0aW9uIChBLUxhYmVscyksIG5vZGUgcmVzb3VyY2UgYWxs b2NhdGlvbiwgYW5kIHF1ZXVlIHBsYWNlbWVudC4KCkhvd2V2ZXIsIGFzIGRpc2N1c3NlZCBpbiB7 e2Rpc3RyaWJ1dGVkLWNvbnRyb2wtcGxhbmV9fSwgZGlzdHJpYnV0ZWQgc2lnbmFsaW5nIHByb3Rv Y29scyBtYXkgaGF2ZSBkaWZmaWN1bHR5IG1lZXRpbmcgRGV0TmV0J3Mgc2NhbGFiaWxpdHkgcmVx dWlyZW1lbnRzLiBNUExTIGFsc28gYWxsb3dzIFNETi1saWtlIGNlbnRyYWxpemVkIGxhYmVsIG1h bmFnZW1lbnQgYW5kIGRpc3RyaWJ1dGlvbiBhcyBhbiBhbHRlcm5hdGl2ZSB0byBkaXN0cmlidXRl ZCBzaWduYWxpbmcgcHJvdG9jb2xzLCB1c2luZyBwcm90b2NvbHMgc3VjaCBhcyBQQ0VQIGFuZCBP cGVuRmxvdyB7e09QRU5GTE9XfX0uCgpQQ0VQLCBwYXJ0aWN1bGFybHkgd2hlbiB1c2VkIGFzIGEg cGFydCBvZiBQQ0UtQ0MsIGlzIGEgcG9zc2libGUgY2FuZGlkYXRlIHByb3RvY29sIHRvIHVzZSBm b3IgY2VudHJhbGl6ZWQgbWFuYWdlbWVudCBvZiB0cmFkaXRpb25hbCBNUExTLWJhc2VkIERldE5l dCBkb21haW5zLiBIb3dldmVyLCBQQ0UgcGF0aCBjYWxjdWxhdGlvbiBhbGdvcml0aG1zIHdvdWxk IG5lZWQgdG8gYmUgZXh0ZW5kZWQgdG8gaW5jbHVkZSB0aGUgbG9jYXRpb24gZGV0ZXJtaW5hdGlv biBmb3IgUFJFT0Ygbm9kZXMgaW4gYSBwYXRoLCBhbmQgdGhlIG1lYW5zIHRvIHNpZ25hbCB0aGUg bmVjZXNzYXJ5IHJlc291cmNlIHJlc2VydmF0aW9uIGFuZCBQUkVPRiBmdW5jdGlvbiBwbGFjZW1l bnQgaW5mb3JtYXRpb24gdG8gbmV0d29yayBub2Rlcy4gU2VlICgoP0ktRC5pZXRmLXBjZS1wY2Vw LWV4dGVuc2lvbi1mb3ItcGNlLWNvbnRyb2xsZXIpKSBmb3IgZnVydGhlciBkaXNjdXNzaW9uIG9m IFBDRS1DQyBhbmQgUENFUCBmb3IgY2VudHJhbGl6ZWQgY29udHJvbCBvZiBhbiBNUExTIGRvbWFp bi4KCiMjIElQCgpJbiBhIGxhdGVyIHJldmlzaW9uIG9mIHRoaXMgZG9jdW1lbnQsIHRoaXMgc2Vj dGlvbiB3aWxsIGRpc2N1c3MgbmVjZXNzYXJ5IHByb3RvY29sIGV4dGVuc2lvbnMgdG8gZXhpc3Rp bmcgSVAgcm91dGluZyBwcm90b2NvbHMgc3VjaCBhcyBJUy1JUyBhbmQgQkdQLiBJdCBzaG91bGQg YmUgbm90ZWQgdGhhdCBhIERldE5ldCBJUCBkb21haW4gaXMgc2ltcGxlciB0aGFuIGEgRGV0TmV0 IE1QTFMgZG9tYWluLCBhbmQgZG9lc24ndCBzdXBwb3J0IFBSRU9GLCBzbyBvbmx5IG9uZSBwYXRo IHBlciBmbG93IG9yIGZsb3cgYWdncmVnYXRlIGlzIHJlcXVpcmVkLCB3aXRoIG5vIHBhdGggbWVy Z2luZy4KCiMjIERldE5ldCB3aXRoIFNlZ21lbnQgUm91dGluZyAoU1IpIHsjU1J9CgpTZWdtZW50 IFJvdXRpbmcge3shUkZDODQwMn19IGlzIGEgc2NhbGFibGUgYXBwcm9hY2ggdG8gYnVpbGRpbmcg bmV0d29yayBkb21haW5zIHRoYXQgdXRpbGl6ZXMgYSBjb21iaW5hdGlvbiBvZiBzb3VyY2Ugcm91 dGluZyBpbiBwYWNrZXQgaGVhZGVycyBhbmQgY2VudHJhbGl6ZWQgbmV0d29yayBjb250cm9sIHRv IGNvbXB1dGUgcGF0aHMgdGhyb3VnaCB0aGUgbmV0d29yayBhbmQgZGlzdHJpYnV0ZSB0aG9zZSBw YXRocyB3aXRoIGFzc29jaWF0ZWQgcG9saWN5IHRvIG5ldHdvcmsgZWRnZSBub2RlcyBmb3IgdXNl IGluIHBhY2tldCBoZWFkZXJzLiBJdCBncmVhdGx5IHJlZHVjZXMgdGhlIGFtb3VudCBvZiBuZXR3 b3JrIHNpZ25hbGluZyBhc3NvY2lhdGVkIHdpdGggZGlzdHJpYnV0ZWQgc2lnbmFsaW5nIHByb3Rv Y29scyBzdWNoIGFzIFJTVlAtVEUsIGFuZCBhbHNvIGdyZWF0bHkgcmVkdWNlcyB0aGUgYW1vdW50 IG9mIHN0YXRlIGluIGNvcmUgbm9kZXMgY29tcGFyZWQgd2l0aCB0aGF0IHJlcXVpcmVkIGZvciB0 cmFkaXRpb25hbCBNUExTIGFuZCBJUCByb3V0aW5nLCBhcyB0aGUgc3RhdGUgaXMgbm93IGluIHRo ZSBwYWNrZXRzIHJhdGhlciB0aGFuIGluIHRoZSByb3V0ZXJzLiBUaGlzIGlzIGVzcGVjaWFsbHkg dXNlZnVsIGZvciBEZXROZXQsIHdoZXJlIGEgdmVyeSBsYXJnZSBudW1iZXIgb2YgZmxvd3MgdGhy b3VnaCBhIG5ldHdvcmsgZG9tYWluIGFyZSBleHBlY3RlZCwgd2hpY2ggd291bGQgb3RoZXJ3aXNl IHJlcXVpcmUgdGhlIGluc3RhbnRpYXRpb24gb2Ygc3RhdGUgZm9yIGVhY2ggZmxvdyB0cmF2ZXJz aW5nIGVhY2ggbm9kZSBpbiB0aGUgbmV0d29yay4KClRoZSBEZXROZXQgTVBMUyBhbmQgSVAgZGF0 YSBwbGFuZXMgd2VyZSBzcGVjaWZpY2FsbHkgY29uc3RydWN0ZWQgdG8gYWxsb3cgdGhlIHVzZSBv ZiBEZXROZXQgd2l0aCBib3RoIHR5cGVzIG9mIHNlZ21lbnQgcm91dGluZywgU1ItTVBMUyB7ez9J LUQuaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW1wbHN9fSBhbmQgU1J2NiB7ez9JLUQuaWV0 Zi02bWFuLXNlZ21lbnQtcm91dGluZy1oZWFkZXJ9fS4KCkluIHRoZSBEZXROZXQgY29udGV4dCwg RGV0TmV0IGluIGFuIFNSLU1QTFMgb3IgU1J2NiBkYXRhIHBsYW5lIGNvdWxkIGJlIHVzZWQgaW4g Y29uanVuY3Rpb24gd2l0aCBjZW50cmFsaXplZCBmbG93IG1hbmFnZW1lbnQgYW5kIGNvbXBsZXRl IGxhYmVsIHN0YWNrIGRpc3RyaWJ1dGlvbiB0byBEZXRuZXQgZG9tYWluIGVudHJ5IG5vZGVzIHZp YSBhIGNlbnRyYWxpemVkIGNvbnRyb2xsZXIuIEV4dGVuc2lvbnMgdG8gUENFUCB0byBhbGxvdyB0 aGUgdXNlIG9mIFBDRS1DQyB3aXRoIFNSLU1QTFMKCk9uZSBwb3NzaWJsZSBhcmNoaXRlY3R1cmUg aXMgUENFLUNDIGNvbWJpbmVkIHdpdGggU1ItTVBMUyBvciBTUnY2LiBFeHRlbnNpb25zIHRvIFBD RVAgdG8gYWxsb3cgdGhlIHVzZSBvZiBQQ0UtQ0Mgd2l0aCBTUi1NUExTIGFyZSBkZXNjcmliZWQg aW4ge3s/SS1ELnpoYW8tcGNlLXBjZXAtZXh0ZW5zaW9uLXBjZS1jb250cm9sbGVyLXNyfX0sIHdp dGggU1J2NiBpbiB7ez9JLUQuZGhvZHktcGNlLXBjZXAtZXh0ZW5zaW9uLXBjZS1jb250cm9sbGVy LXNydjZ9fS4KClRoaXMgYXBwcm9hY2ggd291bGQgYWxsb3cgdGhlIGRldGFpbHMgb2YgcGFja2V0 IG9yIGZsb3cgdHJlYXRtZW50IHRvIGJlIGVuY29kZWQgZGlyZWN0bHkgaW4gdGhlIFNJRHMgb24g ZWFjaCBwYWNrZXQgaW4gYSBmbG93IHRvIHJlZHVjZSB0aGUgYW1vdW50IG9mIHN0YXRlIGluIG5l dHdvcmsgbm9kZXMuIFRoaXMgYXBwcm9hY2ggYWxzbyBhbGxvd3MgdGhlIGludGVncmF0aW9uIG9m IERldE5ldCBkb21haW5zIHdpdGggZ2VuZXJhbCBTUi1iYXNlZCBiYWNrYm9uZSBuZXR3b3JrcyBp biBhIGNvbnZlcmdlZCBkb21haW4uIEluIHRoaXMgYXBwcm9hY2gsIGEgbmV3IHNldCBvZiBmdW5j dGlvbnMgZm9yIERldE5ldCBxdWV1aW5nIHRyZWF0bWVudHMgYXZhaWxhYmxlIGluIHRoZSBEZXRO ZXQgZG9tYWluIHdvdWxkIG5lZWQgdG8gYmUgZGVmaW5lZCBmb3IgaW5jbHVzaW9uIGluIHRoZSBT UiBzdGFjay4KClRoaXMgaXMgbm90IHRoZSBvbmx5IHBvc3NpYmxlIGFwcHJvYWNoLiBUaGVyZSBp cyBvbmdvaW5nIHdvcmsgb24gYSBudW1iZXIgb2YgYWx0ZXJuYXRpdmUgc2lnbmFsaW5nIG1lY2hh bmlzbXMgZm9yIE1QTFMtU1IgYW5kIFNSdjYsIGluY2x1ZGluZyBleHRlbnNpb25zIHRvIElHUHMg YW5kIEJHUCB0byBzdXBwb3J0IGRpc3RyaWJ1dGVkIHNpZ25hbGluZy4gSW4gYWRkaXRpb24sIEJH UC1MUyBhbmQgQkdQIHJvdXRlIHJlZmxlY3RvcnMgY291bGQgYmUgYWRkZWQgZm9yIGEgaHlicmlk IHNvbHV0aW9uLgoKQSBwb3NzaWJsZSBtb3N0bHkgY2VudHJhbGl6ZWQgaHlicmlkIGFwcHJvYWNo IGNvdWxkIGJlIHRvIHVzZSBhIFBDRS1DQyB0byBwdXNoIHBhdGhzIHJlcHJlc2VudGVkIGJ5IFNJ RCBsaXN0cyB3aGlsZSB1c2luZyBCR1AtTFMgdG8gY29sbGVjdCBuZXR3b3JrIHRvcG9sb2d5IGFu ZCBsaW5rIHN0YXRlIGluZm9ybWF0aW9uLiBBbiBJR1AgaXMgdXNlZCBmb3IgdGhlIHVzdWFsIGxp bmsgc3RhdGUgZmxvb2RpbmcgaW4gb3JkZXIgdG8gZXN0YWJsaXNoIGFkamFjZW5jaWVzLCBidXQg bm90IGZvciBEZXROZXQgZmxvdyBwYXRoIGNhbGN1bGF0aW9ucywgb25seSBmb3IgYmVzdCBlZmZv cnQgdHJhZmZpYyBhcyB1c3VhbC4KCkEgc2ltaWxhciBhcHByb2FjaCBmb3IgbmV0d29yayBzbGlj aW5nIHRoYXQgY291bGQgYmUgbGV2ZXJhZ2VkIGZvciBEZXROZXQgaXMgZGVzY3JpYmVkIGluIHt7 P0ktRC5kb25nLXNwcmluZy1zci1mb3ItZW5oYW5jZWQtdnBufX0uCgpBbHNvLCBub3RlIHRoYXQg U1IgY2Fubm90IGN1cnJlbnRseSBzdXBwb3J0IERldE5ldCBQUkVPRiBmdW5jdGlvbmFsaXR5IHdp dGhvdXQgZXh0ZW5zaW9ucy4gT25lIHBvc3NpYmxlIGFwcHJvYWNoIGNvdWxkIGJlIHRvIGNvbWJp bmUgU1Igd2l0aCBCSUVSLVRFLCBhcyBkaXNjdXNzZWQgaW4ge3s/SS1ELmlldGYtYmllci10ZS1h cmNofX0uIEFub3RoZXIgcG9zc2libGUgYXBwcm9hY2ggc3BlY2lmaWMgdG8gU1J2NiBpcyBkaXNj dXNzZWQgaW4ge3s/SS1ELmdlbmctZGV0bmV0LWRwLXNvbC1zcnY2fX0uCgojIE1hbmFnZW1lbnQg UGxhbmUgT3ZlcnZpZXcKClRoZSBNYW5hZ2VtZW50IFBsYW5lIGluY2x1ZGVzIHRoZSBhYmlsaXR5 IHRvIHN0YXRpY2FsbHkgcHJvdmlzaW9uIG5ldHdvcmsgbm9kZXMgYW5kIHRvIHVzZSBPQU0gdG8g bW9uaXRvciBEZXROZXQgcGVyZm9ybWFuY2UgYW5kIGRldGVjdCBvdXRhZ2VzIG9yIG90aGVyIGlz c3VlcyBhdCB0aGUgRGV0TmV0IGxheWVyLgoKIyMgUHJvdmlzaW9uaW5nCgpTdGF0aWMgcHJvdmlz aW9uaW5nIGluIGEgRGV0bmV0IG5ldHdvcmsgd2lsbCBiZSBwZXJmb3JtZWQgdmlhIHRoZSB1c2Ug b2YgYXBwcm9wcmlhdGUgWUFORyBtb2RlbHMsIGluY2x1ZGluZyB7ez9JLUQuaWV0Zi1kZXRuZXQt eWFuZ319IGFuZCB7ez9JLUQuaWV0Zi1kZXRuZXQtdG9wb2xvZ3kteWFuZ319LgoKIyMgRGV0TmV0 IE9wZXJhdGlvbnMsIEFkbWluaXN0cmF0aW9uIGFuZCBNYWludGVuYW5jZSAoT0FNKQoKVGhlIG92 ZXJhbGwgZnJhbWV3b3JrIGFuZCByZXF1aXJlbWVudHMgZm9yIERldE5ldCBPQU0gYXJlIGRpc2N1 c3NlZCBpbiB7ez9JLUQubWlyc2t5LWRldG5ldC1vYW19fS4gVGhpcyBkb2N1bWVudCBjdXJyZW50 bHkgaW5jbHVkZXMgYWRkaXRpb25hbCBPQU0gZGV0YWlscyB0aGF0IG1heSBldmVudHVhbGx5IGJl IG1lcmdlZCBpbnRvIHRoYXQgZG9jdW1lbnQuCgojIyMgT0FNIGZvciBQZXJmb3JtYW5jZSBNb25p dG9yaW5nIChQTSkKCiMjIyMgQWN0aXZlIFBNCgpBY3RpdmUgUE0gaXMgcGVyZm9ybWVkIGJ5IGlu amVjdGluZyBPQU0gcGFja2V0cyBpbnRvIHRoZSBuZXR3b3JrIHRvIGVzdGltYXRlIHRoZSBwZXJm b3JtYW5jZSBvZiB0aGUgbmV0d29yayBieSBtZWFzdXJpbmcgdGhlIHBlcmZvcm1hbmNlIG9mIHRo ZSBPQU0gcGFja2V0cy4gIEFkZGluZyBleHRyYSB0cmFmZmljIGNhbiBhZmZlY3QgdGhlIGRlbGF5 IGFuZCB0aHJvdWdocHV0IHBlcmZvcm1hbmNlIG9mIHRoZSBuZXR3b3JrLCBhbmQgZm9yIHRoaXMg cmVhc29uIGFjdGl2ZSBQTSBpcyBub3QgcmVjb21tZW5kZWQgZm9yIHVzZSBpbiBvcGVyYXRpb25h bCBEZXROZXQgZG9tYWlucy4gSG93ZXZlciwgaXQgaXMgYSB1c2VmdWwgdGVzdCB0b29sIHdoZW4g Y29tbWlzc2lvbmluZyBhIG5ldyBuZXR3b3JrLgoKIyMjIyBQYXNzaXZlIFBNCgpQYXNzaXZlIFBN IG1vbml0b3JzIHRoZSBhY3R1YWwgc2VydmljZSB0cmFmZmljIGluIGEgbmV0d29yayBkb21haW4g aW4gb3JkZXIgdG8gbWVhc3VyZSBpdHMgcGVyZm9ybWFuY2Ugd2l0aG91dCBoYXZpbmcgYSBkZXRy aW1lbnRhbCBhZmZlY3Qgb24gdGhlIG5ldHdvcmsuIEFzIGNvbXBhcmVkIHRvIEFjdGl2ZSBQTSwg UGFzc2l2ZSBQTSBpcyBtdWNoIHByZWZlcnJlZCBmb3IgdXNlIGluIERldE5ldCBkb21haW5zLgoK QSBwcm9wb3NhbCBmb3IgRGV0TmV0IHBhc3NpdmUgcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnQgaXMg Y29udGFpbmVkIGluIHt7P0ktRC5jaGVuLWRldG5ldC1sb3NzLWRlbGF5fX0uCgojIyMgT0FNIGZv ciBGYXVsdC9EZWZlY3QgTWFuYWdlbWVudCAoRk0pCgp7ez9JLUQubWlyc2t5LWRldG5ldC1vYW19 fSBjb250YWlucyByZXF1aXJlbWVudHMgZm9yIGZhdWx0L2RlZmVjdCBkZXRlY3Rpb24gYW5kIG1h bmFnZW1lbnQgaW4gYSBEZXROZXQgZG9tYWluLgoKIyBJQU5BIENvbnNpZGVyYXRpb25zCgpUaGlz IGRvY3VtZW50IGhhcyBubyBhY3Rpb25zIGZvciBJQU5BLgoKTm90ZSB0byBSRkMgRWRpdG9yOiB0 aGlzIHNlY3Rpb24gbWF5IGJlIHJlbW92ZWQgb24gcHVibGljYXRpb24gYXMgYW4gUkZDLgoKIyBT ZWN1cml0eSBDb25zaWRlcmF0aW9ucwoKVGhlIG92ZXJhbGwgc2VjdXJpdHkgY29uc2lkZXJhdGlv bnMgb2YgRGV0TmV0IGFyZSBkaXNjdXNzZWQgaW4ge3shSS1ELmlldGYtZGV0bmV0LWFyY2hpdGVj dHVyZX19IGFuZCB7eyFJLUQuaWV0Zi1kZXRuZXQtc2VjdXJpdHl9fS4gRm9yIERldE5ldCBuZXR3 b3JrcyB0aGF0IG1ha2UgdXNlIG9mIFNlZ21lbnQgUm91dGluZyAod2hldGhlciBTUi1NUExTIG9y IFNSdjYpLCB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgaW4ge3shUkZDODQwMn19IGFsc28g YXBwbHkuCgpEZXROZXQgbmV0d29ya3MgdGhhdCBtYWtlIHVzZSBvZiBhIGNlbnRyYWxpemVkIGNv bnRyb2xsZXIgcGxhbmUgbWF5IGJlIHRocmVhdGVuZWQgYnkgdGhlIGxvc3Mgb2YgY29ubmVjdGl2 aXR5ICh3aGV0aGVyIGFjY2lkZW50YWwgb3IgbWFsaWNpb3VzKSBiZXR3ZWVuIHRoZSBjZW50cmFs IGNvbnRyb2xsZXIgYW5kIHRoZSBuZXR3b3JrIG5vZGVzLCBhbmQvb3IgdGhlIHNwb29maW5nIG9m IGNvbnRyb2wgbWVzc2FnZXMgZnJvbSB0aGUgY29udHJvbGxlciB0byB0aGUgbmV0d29yayBub2Rl cy4gVGhpcyBpcyBpbXBvcnRhbnQgc2luY2Ugc3VjaCBuZXR3b3JrcyBkZXBlbmQgb24gY2VudHJh bGl6ZWQgY29udHJvbGxlcnMgdG8gY2FsY3VsYXRlIGZsb3cgcGF0aHMgYW5kIGluc3RhbnRpYXRl IGZsb3cgc3RhdGUgaW4gdGhlIG5ldHdvcmsgbm9kZXMuIEZvciBuZXR3b3JrcyB0aGF0IHVzZSBi b3RoIERldE5ldCBhbmQgU2VnbWVudCBSb3V0aW5nIHdpdGggYSBjZW50cmFsaXplZCBjb250cm9s bGVyLCB0aGlzIHdvdWxkIGFsc28gaW5jbHVkZSB0aGUgY2FsY3VsYXRpb24gb2YgU0lEIGxpc3Rz IGFuZCB0aGVpciBpbnN0YWxsYXRpb24gaW4gZWRnZS9ib3JkZXIgcm91dGVycy4KCkluIGJvdGgg Y2FzZXMsIHN1Y2ggdGhyZWF0cyBtYXkgYmUgbWl0aWdhdGVkIHRocm91Z2ggcmVkdW5kYW50IGNv bnRyb2xsZXJzLCB0aGUgdXNlIG9mIGF1dGhlbnRpY2F0aW9uIGJldHdlZW4gdGhlIGNvbnRyb2xs ZXIocykgYW5kIHRoZSBuZXR3b3JrIG5vZGVzLCBhbmQgb3RoZXIgbWVjaGFuaXNtcyBmb3IgcHJv dGVjdGlvbiBhZ2FpbnN0IERPUyBhdHRhY2tzLiBBIG1lY2hhbmlzbSBmb3Igc3VwcG9ydGluZyBv bmUgb3IgbW9yZSBhbHRlcm5hdGl2ZSBjZW50cmFsIGNvbnRyb2xsZXJzIGFuZCB0aGUgYWJpbGl0 eSB0byBmYWlsIG92ZXIgdG8gc3VjaCBhbiBhbHRlcm5hdGl2ZSBjb250cm9sbGVyIHdpbGwgYmUg cmVxdWlyZWQuCgojIEFja25vd2xlZGdtZW50cwoKVGhhbmtzIHRvIEppbSBHdWljaGFyZCwgRG9u YWxkIEVhc3RsYWtlLCBhbmQgU3Rld2FydCBCcnlhbnQgZm9yIHRoZWlyIHJldmlldyBjb21tZW50 cy4KCg== --000000000000f495df058efe5cc9-- From nobody Wed Jul 31 13:07:56 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 038B6120094 for ; Wed, 31 Jul 2019 13:07:55 -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=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 DojVjN93fj4h for ; Wed, 31 Jul 2019 13:07:53 -0700 (PDT) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 1603A12008D for ; Wed, 31 Jul 2019 13:07:52 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id w190so50153935qkc.6 for ; Wed, 31 Jul 2019 13:07:52 -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=Nt6yDxy9w4/OAt2r/pS8N8nFuGxmNXyo0wogcoQJOJ0=; b=D3bZP3XGFpZl3DstmMpN4T7yLNEgq/30zC55KotfSwigv9PRqnSuAAhFNAxKiKF+Ez axrZUz5+9fvookG/D1c7MvoIPEitxZ/6eQxlyYGYoej+vjfcZstw9V4GwTnLgG6GeLa6 G8yyKfznAEwyVxJ0R2P6uOBJjx14G4g3zhRcmNsAOHvXYxgkboPrneHpvE1pPhAQq2QP zvItc6K6oNumA3SKw9B6LPWitzXYAtTr4zjlJrz4tWTe1UbtlkKkdBYf9fPEY7m95VQ+ Dn+3yDeAMHEb98TK6jCHTJEP/2V0XQV6wHgvoeAqzhh27xzn/GbeZVw5RaCYOCvt69zP Huow== 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=Nt6yDxy9w4/OAt2r/pS8N8nFuGxmNXyo0wogcoQJOJ0=; b=BWUcblGnkwuTG3jltsJjayXtwJgMQ9CZIms9gDc92I9u6/x7SQ3IdbSvvV3fdRn9Z0 CWXDOgdXnv8wBimXosv/XDHRoeUdq89GaSDHWFf+lNuWUxbOvf/YSzsba2nh3jvfvAzE wXUpLPxqxn5A5XP3vuDJKG7L68hYrS7MNakAgiUlnPZxnfxTChU9E/PtIUeT45ihRPkF OyfKsY/PecYL4FM9y9aD7L3TAEiXutPLwSmcWZAG5JT5Ti0ME3DTrDWG6sRHcwzvkVTO Kkm+zQobemq3cQYG31Gx/V2lBNWZXiO3eTXyRgDkPKnIAPGE6wzJUQE/4lXvxSCfI4L1 2uHQ== X-Gm-Message-State: APjAAAWEjykLoN5VPMsJR0nL4Mj6b2LA3mRCpWbOg+W20Gv0FTxbpuId Jo5moIoSd4GivUi06lcuVoEggx948EXJjdcOG+5XnPel2zk= X-Google-Smtp-Source: APXvYqxUhceQCwQmxcohEBV45aqrJHAyPXtFH3UPQBM66zEI1wE3Aw7Oqg6e4m+e+YkXDoOhvZvAZ1wSq00UKiGed8U= X-Received: by 2002:a05:620a:15a5:: with SMTP id f5mr81758895qkk.45.1564603672048; Wed, 31 Jul 2019 13:07:52 -0700 (PDT) MIME-Version: 1.0 References: <08a2115c-54a4-b049-02ea-340f8e7dce20@htt-consult.com> In-Reply-To: From: "Andrew G. Malis" Date: Wed, 31 Jul 2019 16:07:41 -0400 Message-ID: To: Robert Moskowitz Cc: "xml2rfc@ietf.org" , Carsten Bormann , Scott Mansfield Content-Type: multipart/alternative; boundary="000000000000163a59058effae26" Archived-At: Subject: Re: [xml2rfc] xml to markdown? X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 20:07:55 -0000 --000000000000163a59058effae26 Content-Type: text/plain; charset="UTF-8" Bob, In addition, the QUIC WG's drafts are all in kramdown, and they use lots of great features to check out like drawings, tables, and more. They're also a great source for programming by example. You can find their source files at https://github.com/quicwg/base-drafts . Cheers, Andy On Wed, Jul 31, 2019 at 2:33 PM Andrew G. Malis wrote: > Bob, > > While I don't have such a tool (although Carsten may), I do have a draft > that uses a lot of kramdown features, please feel free to use it as a > template. I use the tools at > https://xml2rfc.tools.ietf.org/experimental.html for converting kramdown > to text. In the top dialog box, "Convert Your XML Source", choose kramdown > rather than xml2rfc as the input type. I go straight to text rather than > generating xml as an intermediate step, although that option is available > further down on that same page. > > I've attached my draft source and output so that you can compare them side > by side. > > Cheers, > Andy > > > On Wed, Jul 31, 2019 at 2:10 PM Robert Moskowitz > wrote: > >> I am having to work with people that prefer markdown for creating their >> IDs. They go the md -> xml -> ID route. >> >> I have yet to figure out how to read markdown drafts let alone work with >> that format. >> >> Is there a tool I can use to convert my xml to markdown so that I can >> see what I have been doing looks like in markdown and see if all the xml >> features I use (like hangtext in defs) are mapped to markdown? >> >> thanks >> >> _______________________________________________ >> xml2rfc mailing list >> xml2rfc@ietf.org >> https://www.ietf.org/mailman/listinfo/xml2rfc >> > --000000000000163a59058effae26 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Bob,

In addition, the QUIC WG's dra= fts are all in kramdown, and they use lots of great features to check out l= ike drawings, tables, and more. They're also a great source for program= ming by example. You can find their source files at=C2=A0https://github.com/quicwg/base-drafts .=

Cheers,
Andy

=
On Wed= , Jul 31, 2019 at 2:33 PM Andrew G. Malis <agmalis@gmail.com> wrote:



On Wed, Jul 31, 2019 at 2:10 PM Robert Moskowitz <= ;rgm@htt-consult.c= om> wrote:
xml2rfc@ietf.org<= br> https://www.ietf.org/mailman/listinfo/xml2rfc
--000000000000163a59058effae26-- From nobody Wed Jul 31 13:24:38 2019 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBEC01200A4 for ; Wed, 31 Jul 2019 13:24:36 -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 r5-nAAxhPGN9 for ; Wed, 31 Jul 2019 13:24:35 -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 EC781120094 for ; Wed, 31 Jul 2019 13:24:34 -0700 (PDT) Received: from client-0158.vpn.uni-bremen.de (client-0158.vpn.uni-bremen.de [134.102.107.158]) (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 45zPzN5NBXzymQ; Wed, 31 Jul 2019 22:24:32 +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, 31 Jul 2019 22:24:32 +0200 Cc: "xml2rfc@ietf.org" X-Mao-Original-Outgoing-Id: 586297470.554103-4bde647f4fcabbd9723944d4a824b3b8 Content-Transfer-Encoding: quoted-printable Message-Id: <8470751D-1091-41BF-A6A2-D610FB33586E@tzi.org> References: <08a2115c-54a4-b049-02ea-340f8e7dce20@htt-consult.com> To: "Andrew G. Malis" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [xml2rfc] xml to markdown? X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 20:24:37 -0000 On Jul 31, 2019, at 20:33, Andrew G. Malis wrote: >=20 > I don't have such a tool (although Carsten may) Actually, I do. This is a bit buggy still, and I need to spend some = time to make it publishable. Until then, just send XML, and I will use = that to further debug the tool (and send you the resulting markdown). Gr=C3=BC=C3=9Fe, Carsten