New Cryptographic Algorithms for HIP

it will create a name and address block, as for authors in the Authors' Addresses section; as a child of it will create an inline name entry, similar to in citations. * Changed the handling of block elements within table cells to re-wrap for better column fit. Fixes issue #454. * Added an error for references without anchor (in v2; in v3 this will be caught by the schema validation step). Fixes issue #412. * Changed error handling in a couple of places so as to result in non-zero command-line exit values on errors. Fixes issue #464. * Tweaked the text renderer to not apply paragraph filling to the content. Fixes an issue raised by resnick@episteme.net. * Changed layout of multiple instances of and to show on separate lines instead of one line, comma-separated. Changed one notice message to warning. * Added an option to silence warnings and notices starting with given strings. * Changed the HTML renderer to not emit email information in both primary and alternative author address blocks. * Added a test case using the new element, and added a couple of email addresses for increased coverage of email address placement when non-ascii address information is present. * Updated the handling of non-latin address information in the text format to follow RFC7997 and the HTML output more closely. * Added generation of v3.rng from v3.rnc to the Makefile, and fixed a schema error in the .rng file * Changed the default content downcoding done for things like 'smart quotes' to only apply to text content, not to XML element attributes. -- Henrik Levkowetz 09 Dec 2019 14:50:54 +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.37.0' Regards, Henrik (via the mkrelease script) From nobody Wed Dec 11 13:32: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 DA67312010F for ; Wed, 11 Dec 2019 13:32:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tBavXeZk2Oe for ; Wed, 11 Dec 2019 13:32:24 -0800 (PST) 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 7D7B412004C for ; Wed, 11 Dec 2019 13:32:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 4553B6211F for ; Wed, 11 Dec 2019 16:32:23 -0500 (EST) 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 rKsx0kiSXPwS for ; Wed, 11 Dec 2019 16:32:20 -0500 (EST) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id D680D62122 for ; Wed, 11 Dec 2019 16:32:19 -0500 (EST) To: "xml2rfc@ietf.org" From: Robert Moskowitz Message-ID: <929ab2b7-da05-f88a-d76d-87d8b12698d7@htt-consult.com> Date: Wed, 11 Dec 2019 16:32:19 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 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] forcing new line in Hanging lists for definitions 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, 11 Dec 2019 21:32:27 -0000 I don't like the way Hanging lists work when you have long names you are defining. I would like the definition to start on a new line below the term. Look at the following:

The family of all sponge functions with a KECCAK-f permutation as the underlying function and multi-rate padding as the padding rule. Extends the SHAKE scheme to allow users to customize their use of the function. A secure hash that allows for an arbitrary output length. A function on bit strings (also called messages) in which the output can be extended to any desired length.

which produces: 2.3. Definitions Keccak (KECCAK Message Authentication Code): The family of all sponge functions with a KECCAK-f permutation as the underlying function and multi-rate padding as the padding rule. cSHAKE (The customizable SHAKE function): Extends the SHAKE scheme to allow users to customize their use of the function. SHAKE (Secure Hash Algorithm KECCAK): A secure hash that allows for an arbitrary output length. XOF (eXtendable-Output Function): A function on bit strings (also called messages) in which the output can be extended to any desired length. I would like to get the content after those : to start on a new line for better readability (at least in my opinion). thanks From nobody Wed Dec 11 13:45:32 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 753F112004C for ; Wed, 11 Dec 2019 13:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0geSqDfaDtz0 for ; Wed, 11 Dec 2019 13:45:28 -0800 (PST) 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 CCD46120025 for ; Wed, 11 Dec 2019 13:45:27 -0800 (PST) Received: from [172.16.42.104] (p548DC893.dip0.t-ipconnect.de [84.141.200.147]) (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 47Y9TL1bqDzysP; Wed, 11 Dec 2019 22:45:26 +0100 (CET) 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: <929ab2b7-da05-f88a-d76d-87d8b12698d7@htt-consult.com> Date: Wed, 11 Dec 2019 22:45:25 +0100 Cc: "xml2rfc@ietf.org" X-Mao-Original-Outgoing-Id: 597793523.9868259-be49818972195988c20a737470c80251 Content-Transfer-Encoding: quoted-printable Message-Id: <8D5BA082-333E-43CF-99DC-ED5A2DE6148B@tzi.org> References: <929ab2b7-da05-f88a-d76d-87d8b12698d7@htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [xml2rfc] forcing new line in Hanging lists for definitions 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, 11 Dec 2019 21:45:30 -0000 Kramdown-rfc (http://rfc.space): > (1.0.2:) An IAL attribute "vspace" can be added to a definition list = to break after the definition term: >=20 > {: vspace=3D"0"} > word: > : definition >=20 > anotherword: > : another definition Translate that to XML to remind me how to do this in RFCXMLv2: $ kramdown-rfc2629 {: vspace=3D"0"} word: : definition anotherword: : another definition =E2=9E=94 definition another definition $ ISTR this was fixed in v3 by introducing proper definition lists with an = attribute to request the usual formatting (

, but I think this is unstable: = https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/38). Gr=C3=BC=C3=9Fe, Carsten > On Dec 11, 2019, at 22:32, Robert Moskowitz = wrote: >=20 > I don't like the way Hanging lists work when you have long names you = are defining. I would like the definition to start on a new line below = the term. >=20 > Look at the following: >=20 >

> > > > The family of all sponge functions with a KECCAK-f > permutation as the underlying function and multi-rate > padding as the padding rule. > > > Extends the SHAKE scheme to allow users to customize their > use of the function. > > > A secure hash that allows for an arbitrary output length. > > > A function on bit strings (also called messages) in which > the output can be extended to any desired length. > > > >

>=20 > which produces: >=20 > 2.3. Definitions >=20 > Keccak (KECCAK Message Authentication Code): The family of all > sponge functions with a KECCAK-f permutation as the underlying > function and multi-rate padding as the padding rule. >=20 > cSHAKE (The customizable SHAKE function): Extends the SHAKE scheme > to allow users to customize their use of the function. >=20 > SHAKE (Secure Hash Algorithm KECCAK): A secure hash that allows = for > an arbitrary output length. >=20 > XOF (eXtendable-Output Function): A function on bit strings (also > called messages) in which the output can be extended to any > desired length. >=20 > I would like to get the content after those : to start on a new line = for better readability (at least in my opinion). >=20 > thanks >=20 > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc From nobody Wed Dec 11 15:01: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 D1EBD120178 for ; Wed, 11 Dec 2019 15:01:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 tXPVdiTNQCFS for ; Wed, 11 Dec 2019 15:01:33 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1BF412012A for ; Wed, 11 Dec 2019 15:01:33 -0800 (PST) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:56239 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 1ifAz4-0004o2-JK; Wed, 11 Dec 2019 15:01:32 -0800 To: Carsten Bormann , Robert Moskowitz References: <929ab2b7-da05-f88a-d76d-87d8b12698d7@htt-consult.com> <8D5BA082-333E-43CF-99DC-ED5A2DE6148B@tzi.org> Cc: "xml2rfc@ietf.org" From: Henrik Levkowetz Message-ID: Date: Thu, 12 Dec 2019 00:01:22 +0100 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: <8D5BA082-333E-43CF-99DC-ED5A2DE6148B@tzi.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9E6b2Pr8p4OQo1R4jqmVgmQaHiK2sEo7n" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, rgm@htt-consult.com, 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] forcing new line in Hanging lists for definitions 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, 11 Dec 2019 23:01:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9E6b2Pr8p4OQo1R4jqmVgmQaHiK2sEo7n Content-Type: multipart/mixed; boundary="FWTh3AcxIJOk7TAHU8XRtGvpPXGhm0Aju"; protected-headers="v1" From: Henrik Levkowetz To: Carsten Bormann , Robert Moskowitz Cc: "xml2rfc@ietf.org" Message-ID: Subject: Re: [xml2rfc] forcing new line in Hanging lists for definitions References: <929ab2b7-da05-f88a-d76d-87d8b12698d7@htt-consult.com> <8D5BA082-333E-43CF-99DC-ED5A2DE6148B@tzi.org> In-Reply-To: <8D5BA082-333E-43CF-99DC-ED5A2DE6148B@tzi.org> --FWTh3AcxIJOk7TAHU8XRtGvpPXGhm0Aju Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The attribute in v3 is is newline=3D"true" (default: "false"). In v2 you= need to use . Henrik On 2019-12-11 22:45, Carsten Bormann wrote: > Kramdown-rfc (http://rfc.space): >=20 >> (1.0.2:) An IAL attribute "vspace" can be added to a definition list t= o break after the definition term: >>=20 >> {: vspace=3D"0"} >> word: >> : definition >>=20 >> anotherword: >> : another definition >=20 > Translate that to XML to remind me how to do this in RFCXMLv2: >=20 > $ kramdown-rfc2629 > {: vspace=3D"0"} > word: > : definition >=20 > anotherword: > : another definition > =E2=9E=94 > > > definition > > another definition > > $ >=20 > ISTR this was fixed in v3 by introducing proper definition lists with a= n attribute to request the usual formatting (

, but I think this is unstable: https://github.com/rfc-format/d= raft-iab-xml2rfc-v3-bis/issues/38). >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 >> On Dec 11, 2019, at 22:32, Robert Moskowitz wrot= e: >>=20 >> I don't like the way Hanging lists work when you have long names you a= re defining. I would like the definition to start on a new line below th= e term. >>=20 >> Look at the following: >>=20 >>

>> >> >> >> The family of all sponge functions with a KECCAK-f >> permutation as the underlying function and multi-rate >> padding as the padding rule. >> >> >> Extends the SHAKE scheme to allow users to customize their= >> use of the function. >> >> >> A secure hash that allows for an arbitrary output length. >> >> >> A function on bit strings (also called messages) in which >> the output can be extended to any desired length. >> >> >> >>

>>=20 >> which produces: >>=20 >> 2.3. Definitions >>=20 >> Keccak (KECCAK Message Authentication Code): The family of all >> sponge functions with a KECCAK-f permutation as the underlying >> function and multi-rate padding as the padding rule. >>=20 >> cSHAKE (The customizable SHAKE function): Extends the SHAKE scheme= >> to allow users to customize their use of the function. >>=20 >> SHAKE (Secure Hash Algorithm KECCAK): A secure hash that allows fo= r >> an arbitrary output length. >>=20 >> XOF (eXtendable-Output Function): A function on bit strings (also >> called messages) in which the output can be extended to any >> desired length. >>=20 >> I would like to get the content after those : to start on a new line f= or better readability (at least in my opinion). >>=20 >> thanks >>=20 >> _______________________________________________ >> xml2rfc mailing list >> xml2rfc@ietf.org >> https://www.ietf.org/mailman/listinfo/xml2rfc >=20 > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc >=20 --FWTh3AcxIJOk7TAHU8XRtGvpPXGhm0Aju-- --9E6b2Pr8p4OQo1R4jqmVgmQaHiK2sEo7n Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl3xdUIACgkQTptXS4+7 Fxq6yA/+MBxDGmWhpZY3rB2+aRgQQcSSQ7sXn2k+0QborLfPkZdnlV0CPk4Jvk1F ad0vQP/71ZiZADDGfjcD3Tc5aqeYIf+VLzj4NYLrFOkJGIcHU9qWpS17odytBO4b sVlNv5Opyvn8NDD0mgNp2yyBpITouIXXg/044etzw/JbdDtRqOUyaWYerVVKwKMn Yc87eov/EyNu+yQua4xr9fp+4DD+rccRZrE3uhywENFvEYK1N5mhLyI+8zytgZ4z knI60Q5ascKR1RJTzLhATRLsTVg5YJBl3ZWxnDjhCadFk01mdIcSCpboE76vT9bw i6BFv9h2OYFBf7WfEb/ylab+binL6EuSD8ylZlUa+u2NrtL70CS6ehWF6Mdu3Bqj fVoPieR0Fad/aCAPWGIMTPlEVYeD5jSVh+qrtM0BNGIJpzEQ4maoWlS9EVdEblxK ZANCBgMAFNMSuWGE0f6LsPqhoV6W/hsln6sQrWk52BMcBPL3r4q41VlA00sJXmm0 DN/ehMZkViBoEuTQfHPLicCr8sZEmpVZ/J9dGrSMaB+qEsIJRpi19gmHuDLoj77S AcfqpBNPvrcKSLLGelEnTelBbZ1S21/UaFPNRYTCwnqUlod02WIBlAKkC8kQVtg1 8VZegL3obXRq6eX/xBzPG6Ytw1iW6hpfetiNKSBwAvNSzsgBzEE= =sUgU -----END PGP SIGNATURE----- --9E6b2Pr8p4OQo1R4jqmVgmQaHiK2sEo7n-- From nobody Wed Dec 11 16:35: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 6459F1201DE for ; Wed, 11 Dec 2019 16:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBWZjdYJDT3L for ; Wed, 11 Dec 2019 16:35:30 -0800 (PST) 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 E8DFC1200F4 for ; Wed, 11 Dec 2019 16:35:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 5241762122; Wed, 11 Dec 2019 19:35:28 -0500 (EST) 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 v4OQZAo5I2yv; Wed, 11 Dec 2019 19:35:23 -0500 (EST) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 907466211F; Wed, 11 Dec 2019 19:35:21 -0500 (EST) To: Henrik Levkowetz , Carsten Bormann Cc: "xml2rfc@ietf.org" References: <929ab2b7-da05-f88a-d76d-87d8b12698d7@htt-consult.com> <8D5BA082-333E-43CF-99DC-ED5A2DE6148B@tzi.org> From: Robert Moskowitz Message-ID: <704ac605-c23e-88e3-bfde-16720509a108@htt-consult.com> Date: Wed, 11 Dec 2019 19:35:14 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [xml2rfc] forcing new line in Hanging lists for definitions 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, 12 Dec 2019 00:35:32 -0000 On 12/11/19 6:01 PM, Henrik Levkowetz wrote: > The attribute in v3 is is newline="true" (default: "false"). In v2 you > need to use . Where/how is newline= used? I tried a couple things, but the parser did not like my attempts. thanks > On 2019-12-11 22:45, Carsten Bormann wrote: >> Kramdown-rfc (http://rfc.space): >> >>> (1.0.2:) An IAL attribute "vspace" can be added to a definition list to break after the definition term: >>> >>> {: vspace="0"} >>> word: >>> : definition >>> >>> anotherword: >>> : another definition >> Translate that to XML to remind me how to do this in RFCXMLv2: >> >> $ kramdown-rfc2629 >> {: vspace="0"} >> word: >> : definition >> >> anotherword: >> : another definition >> ➔ >> >> >> definition >> >> another definition >> >> $ >> >> ISTR this was fixed in v3 by introducing proper definition lists with an attribute to request the usual formatting (

, but I think this is unstable: https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/38). >> >> Grüße, Carsten >> >> >>> On Dec 11, 2019, at 22:32, Robert Moskowitz wrote: >>> >>> I don't like the way Hanging lists work when you have long names you are defining. I would like the definition to start on a new line below the term. >>> >>> Look at the following: >>> >>>

>>> >>> >>> >>> The family of all sponge functions with a KECCAK-f >>> permutation as the underlying function and multi-rate >>> padding as the padding rule. >>> >>> >>> Extends the SHAKE scheme to allow users to customize their >>> use of the function. >>> >>> >>> A secure hash that allows for an arbitrary output length. >>> >>> >>> A function on bit strings (also called messages) in which >>> the output can be extended to any desired length. >>> >>> >>> >>>

>>> >>> which produces: >>> >>> 2.3. Definitions >>> >>> Keccak (KECCAK Message Authentication Code): The family of all >>> sponge functions with a KECCAK-f permutation as the underlying >>> function and multi-rate padding as the padding rule. >>> >>> cSHAKE (The customizable SHAKE function): Extends the SHAKE scheme >>> to allow users to customize their use of the function. >>> >>> SHAKE (Secure Hash Algorithm KECCAK): A secure hash that allows for >>> an arbitrary output length. >>> >>> XOF (eXtendable-Output Function): A function on bit strings (also >>> called messages) in which the output can be extended to any >>> desired length. >>> >>> I would like to get the content after those : to start on a new line for better readability (at least in my opinion). >>> >>> thanks >>> >>> _______________________________________________ >>> xml2rfc mailing list >>> xml2rfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/xml2rfc >> _______________________________________________ >> xml2rfc mailing list >> xml2rfc@ietf.org >> https://www.ietf.org/mailman/listinfo/xml2rfc >> From nobody Wed Dec 11 22:04: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 540101200FF for ; Wed, 11 Dec 2019 22:04:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 9Qk1hgaMtWso for ; Wed, 11 Dec 2019 22:04:47 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A1C41200FD for ; Wed, 11 Dec 2019 22:04:47 -0800 (PST) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:62058 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 1ifHaf-0005Cp-Qb; Wed, 11 Dec 2019 22:04:46 -0800 To: Robert Moskowitz , Carsten Bormann References: <929ab2b7-da05-f88a-d76d-87d8b12698d7@htt-consult.com> <8D5BA082-333E-43CF-99DC-ED5A2DE6148B@tzi.org> <704ac605-c23e-88e3-bfde-16720509a108@htt-consult.com> Cc: "xml2rfc@ietf.org" From: Henrik Levkowetz Message-ID: <65c7cd21-3b27-4205-cf4a-7b56288be875@levkowetz.com> Date: Thu, 12 Dec 2019 07:04:36 +0100 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: <704ac605-c23e-88e3-bfde-16720509a108@htt-consult.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="DK20rN59qwd9qU751d6vnJxLHGWOSmqNd" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, cabo@tzi.org, rgm@htt-consult.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc] forcing new line in Hanging lists for definitions 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, 12 Dec 2019 06:04:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DK20rN59qwd9qU751d6vnJxLHGWOSmqNd Content-Type: multipart/mixed; boundary="fADv0D4MOdvKt3pfEuF2w0tl1hQplBTla"; protected-headers="v1" From: Henrik Levkowetz To: Robert Moskowitz , Carsten Bormann Cc: "xml2rfc@ietf.org" Message-ID: <65c7cd21-3b27-4205-cf4a-7b56288be875@levkowetz.com> Subject: Re: [xml2rfc] forcing new line in Hanging lists for definitions References: <929ab2b7-da05-f88a-d76d-87d8b12698d7@htt-consult.com> <8D5BA082-333E-43CF-99DC-ED5A2DE6148B@tzi.org> <704ac605-c23e-88e3-bfde-16720509a108@htt-consult.com> In-Reply-To: <704ac605-c23e-88e3-bfde-16720509a108@htt-consult.com> --fADv0D4MOdvKt3pfEuF2w0tl1hQplBTla Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Bob, On 2019-12-12 01:35, Robert Moskowitz wrote: >=20 > On 12/11/19 6:01 PM, Henrik Levkowetz wrote: >> The attribute in v3 is is newline=3D"true" (default: "false"). In v2 = you >> need to use . >=20 > Where/how is newline=3D used? I tried a couple things, but the parser = did=20 > not like my attempts. This should do the trick, using v3 elements:

word:: definition
anotherword:: another definition

Regards, Henrik >=20 > thanks >=20 >> On 2019-12-11 22:45, Carsten Bormann wrote: >>> Kramdown-rfc (http://rfc.space): >>> >>>> (1.0.2:) An IAL attribute "vspace" can be added to a definition list= to break after the definition term: >>>> >>>> {: vspace=3D"0"} >>>> word: >>>> : definition >>>> >>>> anotherword: >>>> : another definition >>> Translate that to XML to remind me how to do this in RFCXMLv2: >>> >>> $ kramdown-rfc2629 >>> {: vspace=3D"0"} >>> word: >>> : definition >>> >>> anotherword: >>> : another definition >>> =E2=9E=94 >>> >>> >>> definition >>> >>> another definition >>> >>> $ >>> >>> ISTR this was fixed in v3 by introducing proper definition lists with= an attribute to request the usual formatting (

, but I think this is unstable: https://github.com/rfc-format= /draft-iab-xml2rfc-v3-bis/issues/38). >>> >>> Gr=C3=BC=C3=9Fe, Carsten >>> >>> >>>> On Dec 11, 2019, at 22:32, Robert Moskowitz wr= ote: >>>> >>>> I don't like the way Hanging lists work when you have long names you= are defining. I would like the definition to start on a new line below = the term. >>>> >>>> Look at the following: >>>> >>>>

>>>> >>>> >>>> >>>> Extends the SHAKE scheme to allow users to customize th= eir >>>> use of the function. >>>> >>>> >>>> A secure hash that allows for an arbitrary output lengt= h. >>>> >>>> >>>> A function on bit strings (also called messages) in whi= ch >>>> the output can be extended to any desired length. >>>> >>>> >>>> >>>>

>>>> >>>> which produces: >>>> >>>> 2.3. Definitions >>>> >>>> Keccak (KECCAK Message Authentication Code): The family of all >>>> sponge functions with a KECCAK-f permutation as the underlyin= g >>>> function and multi-rate padding as the padding rule. >>>> >>>> cSHAKE (The customizable SHAKE function): Extends the SHAKE sch= eme >>>> to allow users to customize their use of the function. >>>> >>>> SHAKE (Secure Hash Algorithm KECCAK): A secure hash that allows= for >>>> an arbitrary output length. >>>> >>>> XOF (eXtendable-Output Function): A function on bit strings (al= so >>>> called messages) in which the output can be extended to any >>>> desired length. >>>> >>>> I would like to get the content after those : to start on a new line= for better readability (at least in my opinion). >>>> >>>> thanks >>>> >>>> _______________________________________________ >>>> xml2rfc mailing list >>>> xml2rfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/xml2rfc >>> _______________________________________________ >>> xml2rfc mailing list >>> xml2rfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/xml2rfc >>> >=20 >=20 --fADv0D4MOdvKt3pfEuF2w0tl1hQplBTla-- --DK20rN59qwd9qU751d6vnJxLHGWOSmqNd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl3x2HQACgkQTptXS4+7 FxqW2A//ZlA5l3A/nEboOT6JpCeRrHMOe23dhSdaIA9ILdEYHepu7e/iCMXSmTwd hGXE1SoHFwUfQFHer2AB+bP77K+Z25tstjUBH76DR/0Kti9lYtkYyyXSjnpUJea7 t91/NJpYeso5fydgLE1EGp47lmJBTDVXrN9kkHovFnCwmBmPT68sM+/qfCXXjwLX wWuWMiRz/Bau7+tkbCycAg/91Je9Au+FgreN8wlE2UI7Fu4Ks+lQpAbx1ZK269As txKtsVb3mEWgYehNuJWyvTDDaZLuDiIfL00JlReVKVMoJ1R+eJwybsavRAIHZOfz Y7KJ656KLJkzOaKHbeNgcdXEKLn5PinaGahw9+sHeomsHOKx0iHVBY8BkegqfTKp WOkV+FUPMUgU60RztISZ1jh1g2duow5GYvB7yz6j4kn4vkkqctfjBwN0zdopTKHG WzG5F6faceAw69LUauZ7UZCSK0gl0x6lCnP9KiV9MtSb1+v6EoTNq9xsnIcjMM1q H9N3LMd5sVj7VgQJJj9ipMt66EkLtb9YTX4FfH7hXOcfTHNhEUJEiBqSPmRs/v/b Z1dP7WpgYzuI0axyMdDVau+/hKjxyo+oZ7BZ8sAKdsqLzROZ+c+10xAvMyl3h9F1 GIyR7p2WnDi2zv4EzHGy1lwOW79HNDRwzDSmLV1pUuoz2nc4bKk= =OmXT -----END PGP SIGNATURE----- --DK20rN59qwd9qU751d6vnJxLHGWOSmqNd-- From nobody Thu Dec 12 03:06:31 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 BAE9212087C for ; Thu, 12 Dec 2019 03:06:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oly8F-PR47e for ; Thu, 12 Dec 2019 03:06:27 -0800 (PST) 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 E2052120877 for ; Thu, 12 Dec 2019 03:06:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 8184962122; Thu, 12 Dec 2019 06:06:25 -0500 (EST) 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 cHhesMP1K5g0; Thu, 12 Dec 2019 06:06:19 -0500 (EST) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 3997260D1B; Thu, 12 Dec 2019 06:06:19 -0500 (EST) To: Henrik Levkowetz , Carsten Bormann Cc: "xml2rfc@ietf.org" References: <929ab2b7-da05-f88a-d76d-87d8b12698d7@htt-consult.com> <8D5BA082-333E-43CF-99DC-ED5A2DE6148B@tzi.org> <704ac605-c23e-88e3-bfde-16720509a108@htt-consult.com> <65c7cd21-3b27-4205-cf4a-7b56288be875@levkowetz.com> From: Robert Moskowitz Message-ID: <65df3bed-dfe2-c342-2b62-eade021f2332@htt-consult.com> Date: Thu, 12 Dec 2019 06:06:11 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <65c7cd21-3b27-4205-cf4a-7b56288be875@levkowetz.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [xml2rfc] forcing new line in Hanging lists for definitions 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, 12 Dec 2019 11:06:30 -0000 On 12/12/19 1:04 AM, Henrik Levkowetz wrote: > Hi Bob, > > On 2019-12-12 01:35, Robert Moskowitz wrote: >> On 12/11/19 6:01 PM, Henrik Levkowetz wrote: >>> The attribute in v3 is is newline="true" (default: "false"). In v2 you >>> need to use . >> Where/how is newline= used? I tried a couple things, but the parser did >> not like my attempts. > This should do the trick, using v3 elements: > >

word:: definition
anotherword:: another definition

The

tag is new to me. Shows how much of this stuff I do. I will read up on it and give it a try instead of my old standby ... thanks > >> thanks >> >>> On 2019-12-11 22:45, Carsten Bormann wrote: >>>> Kramdown-rfc (http://rfc.space): >>>> >>>>> (1.0.2:) An IAL attribute "vspace" can be added to a definition list to break after the definition term: >>>>> >>>>> {: vspace="0"} >>>>> word: >>>>> : definition >>>>> >>>>> anotherword: >>>>> : another definition >>>> Translate that to XML to remind me how to do this in RFCXMLv2: >>>> >>>> $ kramdown-rfc2629 >>>> {: vspace="0"} >>>> word: >>>> : definition >>>> >>>> anotherword: >>>> : another definition >>>> ➔ >>>> >>>> >>>> definition >>>> >>>> another definition >>>> >>>> $ >>>> >>>> ISTR this was fixed in v3 by introducing proper definition lists with an attribute to request the usual formatting (

, but I think this is unstable: https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/38). >>>> >>>> Grüße, Carsten >>>> >>>> >>>>> On Dec 11, 2019, at 22:32, Robert Moskowitz wrote: >>>>> >>>>> I don't like the way Hanging lists work when you have long names you are defining. I would like the definition to start on a new line below the term. >>>>> >>>>> Look at the following: >>>>> >>>>>

>>>>> >>>>> >>>>> >>>>> The family of all sponge functions with a KECCAK-f >>>>> permutation as the underlying function and multi-rate >>>>> padding as the padding rule. >>>>> >>>>> >>>>> Extends the SHAKE scheme to allow users to customize their >>>>> use of the function. >>>>> >>>>> >>>>> A secure hash that allows for an arbitrary output length. >>>>> >>>>> >>>>> A function on bit strings (also called messages) in which >>>>> the output can be extended to any desired length. >>>>> >>>>> >>>>> >>>>>

>>>>> >>>>> which produces: >>>>> >>>>> 2.3. Definitions >>>>> >>>>> Keccak (KECCAK Message Authentication Code): The family of all >>>>> sponge functions with a KECCAK-f permutation as the underlying >>>>> function and multi-rate padding as the padding rule. >>>>> >>>>> cSHAKE (The customizable SHAKE function): Extends the SHAKE scheme >>>>> to allow users to customize their use of the function. >>>>> >>>>> SHAKE (Secure Hash Algorithm KECCAK): A secure hash that allows for >>>>> an arbitrary output length. >>>>> >>>>> XOF (eXtendable-Output Function): A function on bit strings (also >>>>> called messages) in which the output can be extended to any >>>>> desired length. >>>>> >>>>> I would like to get the content after those : to start on a new line for better readability (at least in my opinion). >>>>> >>>>> thanks >>>>> >>>>> _______________________________________________ >>>>> xml2rfc mailing list >>>>> xml2rfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/xml2rfc >>>> _______________________________________________ >>>> xml2rfc mailing list >>>> xml2rfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/xml2rfc >>>> >> From nobody Thu Dec 12 05:23: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 99490120131; Thu, 12 Dec 2019 05:23:57 -0800 (PST) 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 qHM_1D86r8eV; Thu, 12 Dec 2019 05:23:55 -0800 (PST) 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 A9C85120013; Thu, 12 Dec 2019 05:23:55 -0800 (PST) Received: from henrik by durif.tools.ietf.org with local (Exim 4.80) (envelope-from ) id 1ifORf-0005KZ-EH; Thu, 12 Dec 2019 05:23:55 -0800 To: xml2rfc-dev@ietf.org, xml2rfc@ietf.org Cc: rfc-markdown@ietf.org Message-Id: From: Henrik Levkowetz Date: Thu, 12 Dec 2019 05:23:55 -0800 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.37.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: Thu, 12 Dec 2019 13:23:57 -0000 Hi, This is an automatic notification about a new xml2rfc release, v2.37.1, generated when running the mkrelease script. Release notes: xml2rfc (2.37.1) ietf; urgency=medium * Fixed a bug in the text formatter pagination code where it incorrectly tried to annotate Comment and PI nodes with page number information. * Updated the v2v3 converter to do essentially what it did before v2.37 with respect to unicode downcoding, but with more explicit calls. * Added a base writer method to downcode reference punctuation. * Moved the list of (tag, attr) combinations that permit unicode values into util.unicode. Rewrote docwncode_punctuation() to only touch punctuation. * Restored lost trailing text after in context for text output. -- Henrik Levkowetz 12 Dec 2019 12:42:15 +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.37.1' Regards, Henrik (via the mkrelease script) From nobody Thu Dec 12 07:01:29 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 AA88E120907 for ; Thu, 12 Dec 2019 07:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, 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 4HrTRJ7L-s9L for ; Thu, 12 Dec 2019 07:01:24 -0800 (PST) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 3F476120914 for ; Thu, 12 Dec 2019 07:01:24 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xBCF1MdS038861 for ; Thu, 12 Dec 2019 16:01:22 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 792A3205CA7 for ; Thu, 12 Dec 2019 16:01:22 +0100 (CET) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 6FA82205D11 for ; Thu, 12 Dec 2019 16:01:22 +0100 (CET) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xBCF1MVC024462 for ; Thu, 12 Dec 2019 16:01:22 +0100 To: xml2rfc@ietf.org References: From: Alexandre Petrescu Message-ID: Date: Thu, 12 Dec 2019 16:01:22 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [xml2rfc] New xml2rfc release: v2.37.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: Thu, 12 Dec 2019 15:01:28 -0000 Thank you for the great work. I depend on its well working. Alex Le 12/12/2019 à 14:23, Henrik Levkowetz a écrit : > > Hi, > > This is an automatic notification about a new xml2rfc release, > v2.37.1, generated when running the mkrelease script. > > Release notes: > > xml2rfc (2.37.1) ietf; urgency=medium > > * Fixed a bug in the text formatter pagination code where it incorrectly > tried to annotate Comment and PI nodes with page number information. > > * Updated the v2v3 converter to do essentially what it did before v2.37 > with respect to unicode downcoding, but with more explicit calls. > > * Added a base writer method to downcode reference punctuation. > > * Moved the list of (tag, attr) combinations that permit unicode values > into util.unicode. Rewrote docwncode_punctuation() to only touch > punctuation. > > * Restored lost trailing text after in context for text > output. > > -- Henrik Levkowetz 12 Dec 2019 12:42:15 +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.37.1' > > Regards, > > Henrik > (via the mkrelease script) > > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc > From nobody Thu Dec 12 07:09: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 B337B1208FB for ; Thu, 12 Dec 2019 07:09:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.231 X-Spam-Level: X-Spam-Status: No, score=-1.231 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, 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 z-_-erkkr8r5 for ; Thu, 12 Dec 2019 07:09:07 -0800 (PST) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 2B13D12087F for ; Thu, 12 Dec 2019 07:09:07 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xBCF95h1031725 for ; Thu, 12 Dec 2019 16:09:05 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 63C38205D07 for ; Thu, 12 Dec 2019 16:09:05 +0100 (CET) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 4FD13205CAC for ; Thu, 12 Dec 2019 16:09:05 +0100 (CET) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xBCF95QP030767 for ; Thu, 12 Dec 2019 16:09:05 +0100 From: Alexandre Petrescu To: xml2rfc@ietf.org References: Message-ID: <9613cff6-0a7d-02a6-ec39-b0bcd8b23f22@gmail.com> Date: Thu, 12 Dec 2019 16:09:05 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 7bit Archived-At: Subject: [xml2rfc] draft-name-blah.pdf instead of draft-name-blah.txt.pdf at the output of xml2rfc.tools.ietf.org 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, 12 Dec 2019 15:09:12 -0000 Hello, I would like xml2rfc.tools.ietf.org to generate a pdf file with the filename: draft-name-blah.pdf instead of draft-name-blah.txt.pdf I need this in order to talk about it to colleagues, by employing terms such as "please generate the txt file", or "please read the pdf file". The txt and pdf files are two different files, but their extensions are concatenated into one. On windows it is displayed as: "draft-name-blah.txt Adobe Acrobat Document" It is a contradiction in terms. Alex From nobody Thu Dec 12 12:52: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 6352D1200BA for ; Thu, 12 Dec 2019 12:52:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jxiuo1H_lD9 for ; Thu, 12 Dec 2019 12:52:06 -0800 (PST) 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 8159E120024 for ; Thu, 12 Dec 2019 12:52:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 668E762122 for ; Thu, 12 Dec 2019 15:52:05 -0500 (EST) 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 A4GjZ-whqyOH for ; Thu, 12 Dec 2019 15:51:59 -0500 (EST) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 485B16211D for ; Thu, 12 Dec 2019 15:51:57 -0500 (EST) To: "xml2rfc@ietf.org" From: Robert Moskowitz Message-ID: Date: Thu, 12 Dec 2019 15:51:49 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 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] tag DL errors on draft submission 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, 12 Dec 2019 20:52:08 -0000 I got one draft submitted with the change to

tags, but on the second, the txt built with xml2rfc --v3, but when I did the submit I got errors: One or more XML validation errors occurred when processing the XML file: draft-moskowitz-hip-new-crypto-03.xml: Line 124: Element dl is not declared in t list of possible children draft-moskowitz-hip-new-crypto-03.xml: Line 125: No declaration for element dl draft-moskowitz-hip-new-crypto-03.xml: Line 125: No declaration for attribute newline of element dl draft-moskowitz-hip-new-crypto-03.xml: Line 126: No declaration for element dt draft-moskowitz-hip-new-crypto-03.xml: Line 127: No declaration for element dd draft-moskowitz-hip-new-crypto-03.xml: Line 132: No declaration for element dt draft-moskowitz-hip-new-crypto-03.xml: Line 133: No declaration for element dd draft-moskowitz-hip-new-crypto-03.xml: Line 136: No declaration for element dt draft-moskowitz-hip-new-crypto-03.xml: Line 137: No declaration for element dd draft-moskowitz-hip-new-crypto-03.xml: Line 141: No declaration for element dt draft-moskowitz-hip-new-crypto-03.xml: Line 142: No declaration for element dd draft-moskowitz-hip-new-crypto-03.xml: Line 145: No declaration for element dt draft-moskowitz-hip-new-crypto-03.xml: Line 146: No declaration for element dd draft-moskowitz-hip-new-crypto-03.xml: Line 151: No declaration for element dt draft-moskowitz-hip-new-crypto-03.xml: Line 152: No declaration for element dd draft-moskowitz-hip-new-crypto-03.xml: Line 156: No declaration for element dt draft-moskowitz-hip-new-crypto-03.xml: Line 157: No declaration for element dd draft-moskowitz-hip-new-crypto-03.xml: Line 161: No declaration for element dt draft-moskowitz-hip-new-crypto-03.xml: Line 162: No declaration for element dd Line 124 through 167 is:

Keccak (KECCAK Message Authentication Code):: The family of all sponge functions with a KECCAK-f permutation as the underlying function and multi-rate padding as the padding rule.
KMAC (KECCAK Message Authentication Code):: A PRF and keyed hash function based on KECCAK.
cSHAKE (The customizable SHAKE function):: Extends the SHAKE scheme to allow users to customize their use of the function.
SHAKE (Secure Hash Algorithm KECCAK):: A secure hash that allows for an arbitrary output length.
PRF (Pseudorandom Function):: A function that can be used to generate output from a random seed such that the output is computationally indistinguishable from truly random output.
capacity:: In the sponge construction, the width of the underlying function minus the rate.
rate:: In the sponge construction, the number of input bits processed per invocation of the underlying function.
XOF (eXtendable-Output Function):: A function on bit strings (also called messages) in which the output can be extended to any desired length.

What am I missing? thanks From nobody Thu Dec 12 21:12: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 600C81200F4 for ; Thu, 12 Dec 2019 21:12:49 -0800 (PST) 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 sTOmBRQSaULO for ; Thu, 12 Dec 2019 21:12:47 -0800 (PST) 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 F0D72120086 for ; Thu, 12 Dec 2019 21:12:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1576213956; bh=U/SM3GwLBojxw4UNh538ZPhrBtpytNU4I9CAXv/ftIc=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=LY+autkF1WbeFqMaOc9kzzqDFZnVGNE1XhKLgideQZrEyVcJ4mmeR7zoMlq4x9FJN EmluaLkFLVXXyLPuvkyWPCkypV4oqx8XeuHIp05dMbR5N7t0cAD6EirE2pK0fQ4YaJ Y5ezB5Utv6ek1osfATVjHD80Q0SokcPfSC9z0Y2Y= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([217.251.133.26]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N3bWr-1hfS5v2DJb-010Yih; Fri, 13 Dec 2019 06:12:36 +0100 To: Robert Moskowitz , "xml2rfc@ietf.org" References: From: Julian Reschke Message-ID: Date: Fri, 13 Dec 2019 06:12:34 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 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:j17QQXCkoZq75+HrNJiY8IKply3Gc1hTrKvLTsvWUp2DBnsiTHD IB3XtYnA/9u2dU9q6Lk9HzbOxtcIJDqV+UqBvwTJlKU7zN5Om0ECCww8fYYS2lwSgK/6zqP hMuJjZ73cFp70o+AJcqOxmPEIIvy+Z+nzN3TEFe5zDtuauHYib2AW6lRySu0W7SQM3d5++t D4HxAj+43IbmVBtHIKxnw== X-UI-Out-Filterresults: notjunk:1;V03:K0:wFdQmxpWI20=:b5/NNVDEFPifeASNGmPyc0 a70ycG5aBK6mVu9GFYr2rqF4QOZY2k5pbBOUmzuwHms4uyO1WmHPrW8+oKN3igjFtfk4cAhaN TlDk6uB5dt3gBSmbF6cLFS+ATJkhZGCQXoBYHtuDcBOM9+iY4H1JyIXzZbU2kbEm+8F2/yvCy 92X8IMt6eyoyJdAeq2Uqfh7ZsuRSg+BxhhFj0gjuH5/K6daX8q9de3xJTEaaf9aRycYXn9TtI lcQvfqgfcGKh196afn2DyUovDPm8AV1+XpAEvQG7JU3sTrO4MfGr3pcJ9aClEhRDGWSRg1dXd Lu1GOUt2d9ePOXA4Wd3z46xNLOmYd1vVkB8aL0Ke2S+dYPJNtfcOlPldRo2EFMuoiRQt31685 zLBH75UxtXZDP9S3Sqtc2AHtvTK/UXi12P8QqM/bZV0UjUqaDWIt0tJWE4c00ks45fD0afCKB pX4bcHRlJEy+YIWUl7oxzEX3jwES9a76bRCxz7GYo0am7pmFnmEDU4sMqiOhqGnj9I4z/Dup8 JbkpV7R+s1TCIe36W0ympa31U3GphIpnFZ5CmW/BjxYAAe+0LQMkxDaAi61arrxf3YXBdhw9f 45hLW7WmryxOH49dj/5poQkLbOu/WGJs2ZoYUMqsevyrne7d90P1lPVKrlBelYWvuiiVgknOr AUZdr55TnuAR6h0UJp6+6GhxB1v8hfpFTudHvPTK4JS2W43MGTl2PkPvTvLtxMzgUQeqsxwrR +gDlZppivyqaChc1dERjRowQ1PViLxk56o7MBpHHuwJswQoRcHijkRUiymDGskbMhASl/+rRW +nLd19oKjzEbsHMTbqbHYuOylwxirzj1/MiXpgP6XqPb8gh/jd6RjwBAa6GqJNHWKyaa9Xm8b Ee9Ss3NrX6xCHrIj8O/2GE6NtfyoJAbAKwZwjElSeJ79ltwgMlZe4xZYAs0QD7cbvqYu7qUfD ZOuSwcVcYcHNr3CHG+fdbSY5bvTyJh0khbo0h7eC+6NhU17i0jqvJPoDFdkulMW7CQoxlGvMq qUzDcaJfEiHVDRdDJ7AM0TTK/GYRwJ+wKA/igCkNDjX3oAncMNVGOU1xHIPDLv2h2ODWEQO8l k4ZV90e2lQI6l9N1RR492wp5xyotSbNo8ZQrgp8oJCKQle/U5Pyi/WmX19dMQOBNJgZmwwBa9 BylzE/8/wwEWNS4gp/NpJArFFKc+NVc9sdVJn6nCHfbHsDpODRIeRkbxwF0OOr2BPhWZycFvW gsW/dClMO4SgJugkkg0fY+9/ubQKEbhwZLic/IoO20LHSGX1qpxdi9y5kBvU= Archived-At: Subject: Re: [xml2rfc] tag DL errors on draft submission 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, 13 Dec 2019 05:12:49 -0000 On 12.12.2019 21:51, Robert Moskowitz wrote: > I got one draft submitted with the change to

tags, but on the > second, the txt built with xml2rfc --v3, but when I did the submit I got > errors: > > One or more XML validation errors occurred when processing the XML file: > draft-moskowitz-hip-new-crypto-03.xml: Line 124: Element dl is not > declared in t list of possible children > draft-moskowitz-hip-new-crypto-03.xml: Line 125: No declaration for > element dl > draft-moskowitz-hip-new-crypto-03.xml: Line 125: No declaration for > attribute newline of element dl > draft-moskowitz-hip-new-crypto-03.xml: Line 126: No declaration for > element dt > draft-moskowitz-hip-new-crypto-03.xml: Line 127: No declaration for > element dd > draft-moskowitz-hip-new-crypto-03.xml: Line 132: No declaration for > element dt > draft-moskowitz-hip-new-crypto-03.xml: Line 133: No declaration for > element dd > draft-moskowitz-hip-new-crypto-03.xml: Line 136: No declaration for > element dt > draft-moskowitz-hip-new-crypto-03.xml: Line 137: No declaration for > element dd > draft-moskowitz-hip-new-crypto-03.xml: Line 141: No declaration for > element dt > draft-moskowitz-hip-new-crypto-03.xml: Line 142: No declaration for > element dd > draft-moskowitz-hip-new-crypto-03.xml: Line 145: No declaration for > element dt > draft-moskowitz-hip-new-crypto-03.xml: Line 146: No declaration for > element dd > draft-moskowitz-hip-new-crypto-03.xml: Line 151: No declaration for > element dt > draft-moskowitz-hip-new-crypto-03.xml: Line 152: No declaration for > element dd > draft-moskowitz-hip-new-crypto-03.xml: Line 156: No declaration for > element dt > draft-moskowitz-hip-new-crypto-03.xml: Line 157: No declaration for > element dd > draft-moskowitz-hip-new-crypto-03.xml: Line 161: No declaration for > element dt > draft-moskowitz-hip-new-crypto-03.xml: Line 162: No declaration for > element dd > > Line 124 through 167 is: > > =C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0 =C2=A0

Keccak (KECCAK Message Authen= tication Code):: > =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 The family of = all sponge functions with a KECCAK-f > =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 permutation as= the underlying function and multi-rate > =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 padding as the= padding rule. > =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0
KMAC (KECCAK Message Authenti= cation Code):: > =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 A PRF and keye= d hash function based on KECCAK. > =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0
cSHAKE (The customizable SHAK= E function):: > =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Extends the SH= AKE scheme to allow users to customize their > =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 use of the fun= ction. > =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0
SHAKE (Secure Hash Algorithm = KECCAK):: > =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 A secure hash = that allows for an arbitrary output length. > =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0
PRF (Pseudorandom Function):<= /dt> > =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0: > =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 A function tha= t can be used to generate output from a > =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 random seed su= ch that the output is computationally > =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 indistinguisha= ble from truly random output. > =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0
capacity:: > =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 In the sponge = construction, the width of the underlying > =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 function minus= the rate. > =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0
rate:: > =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 In the sponge = construction, the number of input bits > =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 processed per = invocation of the underlying function. > =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0
XOF (eXtendable-Output Functi= on):: > =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 A function on = bit strings (also called messages) in which > =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 the output can= be extended to any desired length. > =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0

> =C2=A0=C2=A0=C2=A0 > > What am I missing?

is a section-level element, so it can not appear inside . See . Best regards, Julian From nobody Fri Dec 13 02:31: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 56DC1120839 for ; Fri, 13 Dec 2019 02:31:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttxSZJdGHSAf for ; Fri, 13 Dec 2019 02:31:01 -0800 (PST) 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 A824B12026E for ; Fri, 13 Dec 2019 02:31:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id D165C62122; Fri, 13 Dec 2019 05:30:59 -0500 (EST) 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 gYvMQiun7baT; Fri, 13 Dec 2019 05:30:53 -0500 (EST) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 1CDDD6211F; Fri, 13 Dec 2019 05:30:53 -0500 (EST) To: Julian Reschke , "xml2rfc@ietf.org" References:

From: Robert Moskowitz Message-ID: Date: Fri, 13 Dec 2019 05:30:45 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [xml2rfc] tag DL errors on draft submission 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, 13 Dec 2019 10:31:04 -0000 On 12/13/19 12:12 AM, Julian Reschke wrote: > On 12.12.2019 21:51, Robert Moskowitz wrote: >> I got one draft submitted with the change to

tags, but on the >> second, the txt built with xml2rfc --v3, but when I did the submit I got >> errors: >> >> One or more XML validation errors occurred when processing the XML file: >> draft-moskowitz-hip-new-crypto-03.xml: Line 124: Element dl is not >> declared in t list of possible children >> draft-moskowitz-hip-new-crypto-03.xml: Line 125: No declaration for >> element dl >> draft-moskowitz-hip-new-crypto-03.xml: Line 125: No declaration for >> attribute newline of element dl >> draft-moskowitz-hip-new-crypto-03.xml: Line 126: No declaration for >> element dt >> draft-moskowitz-hip-new-crypto-03.xml: Line 127: No declaration for >> element dd >> draft-moskowitz-hip-new-crypto-03.xml: Line 132: No declaration for >> element dt >> draft-moskowitz-hip-new-crypto-03.xml: Line 133: No declaration for >> element dd >> draft-moskowitz-hip-new-crypto-03.xml: Line 136: No declaration for >> element dt >> draft-moskowitz-hip-new-crypto-03.xml: Line 137: No declaration for >> element dd >> draft-moskowitz-hip-new-crypto-03.xml: Line 141: No declaration for >> element dt >> draft-moskowitz-hip-new-crypto-03.xml: Line 142: No declaration for >> element dd >> draft-moskowitz-hip-new-crypto-03.xml: Line 145: No declaration for >> element dt >> draft-moskowitz-hip-new-crypto-03.xml: Line 146: No declaration for >> element dd >> draft-moskowitz-hip-new-crypto-03.xml: Line 151: No declaration for >> element dt >> draft-moskowitz-hip-new-crypto-03.xml: Line 152: No declaration for >> element dd >> draft-moskowitz-hip-new-crypto-03.xml: Line 156: No declaration for >> element dt >> draft-moskowitz-hip-new-crypto-03.xml: Line 157: No declaration for >> element dd >> draft-moskowitz-hip-new-crypto-03.xml: Line 161: No declaration for >> element dt >> draft-moskowitz-hip-new-crypto-03.xml: Line 162: No declaration for >> element dd >> >> Line 124 through 167 is: >> >> >>

Keccak (KECCAK Message Authentication Code):: >> The family of all sponge functions with a KECCAK-f >> permutation as the underlying function and multi-rate >> padding as the padding rule. >>
KMAC (KECCAK Message Authentication Code):: >> A PRF and keyed hash function based on KECCAK. >>
cSHAKE (The customizable SHAKE function):: >> Extends the SHAKE scheme to allow users to customize their >> use of the function. >>
SHAKE (Secure Hash Algorithm KECCAK):: >> A secure hash that allows for an arbitrary output length. >>
PRF (Pseudorandom Function):: >> A function that can be used to generate output from a >> random seed such that the output is computationally >> indistinguishable from truly random output. >>
capacity:: >> In the sponge construction, the width of the underlying >> function minus the rate. >>
rate:: >> In the sponge construction, the number of input bits >> processed per invocation of the underlying function. >>
XOF (eXtendable-Output Function):: >> A function on bit strings (also called messages) in which >> the output can be extended to any desired length. >>

>> >> >> What am I missing? > >

is a section-level element, so it can not appear inside . See > . > > Best regards, Julian OK. I will make the change, but it worked just fine in: draft-moskowitz-orchid-cshake-01 And in both cases xml2rfc --v3 had no problem with it. From nobody Fri Dec 13 03:09:21 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 94D9E120271 for ; Fri, 13 Dec 2019 03:09:20 -0800 (PST) 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 76EpvJB9I6Qy for ; Fri, 13 Dec 2019 03:09:19 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5CEE120108 for ; Fri, 13 Dec 2019 03:09:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1576235355; bh=r2G8aT3M5YilwLdqd7hkUiqsn1EH8oj5H2kigBahSYs=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=azV2eF7tuFsapNjUUQfIdu5Ynhs6eiuv0wOKJnIZXk155W4hoS5K8mCpkzj1IJPh1 tLg6G2JYaaDMysiZkrGItrKD05gffp9wvyHQO+uaCAtc5cDzjyQZPHaSqMZSpJ6qoQ XwKxbQzWaU+/XKGwFm7BoG+4WboXQp6f3qgykjK0= 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 1MrhQC-1huVwy2jbQ-00ng3L; Fri, 13 Dec 2019 12:04:00 +0100 To: Robert Moskowitz , "xml2rfc@ietf.org" References:

From: Julian Reschke Message-ID: <10d33dfd-411c-14cf-51ae-79e28b91fa0c@gmx.de> Date: Fri, 13 Dec 2019 12:03:59 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 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:6u7Q9owqAXiDlKj07GKhQyloSW4fMR2CTHrXAY2HnMKt35zIM3f B+4de1fsyIRZ5vRAa7F2fRvsrlJDJXq2+EXnyKZb5XkbwjRsWCPBVwkuUx0uJzJH0F7Fqq+ 7a+kKnCs0+4SYbEoQBuAMlOud21TJ2qHKBxG5Gf667qd3LVdyX2W3nwepJoSWMHBKIDxOuP qpU3kExqg5q+OPftgf+fA== X-UI-Out-Filterresults: notjunk:1;V03:K0:yqMEBIjkDE4=:LPn/fDQ6eG4OOlqmTX7mZv b0zkPCPxzJnyCN2hCGg0oRoI1Y7b13RUQAA+Ti5Uwrzwd/qip63Jcrkz3it2aCfOSZJqpSDmL h4mglfO7KEkarsMZkCbC+5KiIYdCbXhAQnLXmJrnsqos2TZ3x7oG49mDOuOc7ID2zD9Xenggm UFqxLGkHqw2pRI2njLqehUqeWGXhXSRhg+eObm3wZB3fUTZJodO3PT0coGAex+q4lqJ57CaMt jTDZRZZHrRsRT541lHvUHyZJx0UDZTmEO09nq6ortBwq/oXDjljT/khP211Zi0xJbqsrjPC8k JDoI+djlFREFEr7KcGozNQ2yjW4d5qPniekT4t0Pu5oS0sKxYu4RrMpUWMARg+dOj1aAdm8kL 9kOagP9H+ykNaXKB+fVZikUyUGeyJNsY4sNx8alwORDfLtA48CBasj7PvwMXpmVErSTLY6LRx dPtj9vnyaw9dnugx2codeNygpQVWrrhWMm/cFX23M1zfxpRsNtc7gi9MN/Tkyuftc1fYnk6ex ewMiy4CFsFBNPvL1AK0OK2T0R9waFOJWcsedtbgf9K9WrfzHeqB3Gy8CdAHiOj6FyN/weu8zt 7ASjSRLrJ7+pJz6oT743EfNUHOTkPAxLdkldf9dSINeZpgqNTj9fn8eFE3N2iw9OE2stJPl/m H4ROlCFYO45A5eYZD4WSazi5yn62DX5WWZfEd/8z7/okzncep++B4kHHWj3zcxDKaggNEus8M T88Kj7Y7Ftv/OTXSAswTV+rzB3z2EY7QxoZRYJwHX3eLj3h/u/CQbPjSOKaJ91mwdH8Tr3JUb BNlxHpmHTfOHmauxdoz8AI7r5XK53o6FaRSqtyP7bkQdZlYg4OCJiCeX/AUwzkJ0WIraoJ4Ge izr0TMWozMxNl6Rf5lgdGqqmi1mLLdRJKLFM21wNTspZwFJJed7BIoTKRs6+udoi/wKFJRPpa dZpdpBGdcrDUX+zPAnpmKJbFdyVMGP3S27nch+58WnRtexMvYo8deQfomydivBomzPls9nPbL FOsHhpbqjVMd6eF75TTdwIj59U8hSu9lFOyDe4vbi3QW3PdMQA9Vc8bdgWwDsKiYWLOk70uap 9zAz9ElPtoV2xPH7Y6lOOqfNo5Ix0kufVwUU/blxTiFvSOxhf4xaRcK2kIJBsJJgTUo3ckxV6 ptEmn2TeOlJivYmmDq7vnNVAdrGseWmUDu5pXIaWmRlWaePxmWY2Ko4rBjhZq0bbaTPXiVD7r s8kbLhmgEYiXXRn96TNVo14yIsFsDQwsquhQFGaKTzO2+DT+0oOY9JVktX7M= Archived-At: Subject: Re: [xml2rfc] tag DL errors on draft submission 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, 13 Dec 2019 11:09:20 -0000 On 13.12.2019 11:30, Robert Moskowitz wrote: > ... > OK. I will make the change, but it worked just fine in: > > draft-moskowitz-orchid-cshake-01 > > And in both cases xml2rfc --v3 had no problem with it. > ... Please provide the sources for both files, and I can have a look what's different. Best regards, Julian From nobody Fri Dec 13 05:46: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 4C5351200FE for ; Fri, 13 Dec 2019 05:46:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RNL2PkCF8Kn for ; Fri, 13 Dec 2019 05:46:00 -0800 (PST) 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 B4B6D120104 for ; Fri, 13 Dec 2019 05:46:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 14F8062122; Fri, 13 Dec 2019 08:45:59 -0500 (EST) 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 xanTKpI+nLiP; Fri, 13 Dec 2019 08:45:37 -0500 (EST) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id D44CC6211F; Fri, 13 Dec 2019 08:45:36 -0500 (EST) To: Julian Reschke , "xml2rfc@ietf.org" References:

<10d33dfd-411c-14cf-51ae-79e28b91fa0c@gmx.de> From: Robert Moskowitz Message-ID: Date: Fri, 13 Dec 2019 08:45:28 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <10d33dfd-411c-14cf-51ae-79e28b91fa0c@gmx.de> Content-Type: multipart/mixed; boundary="------------8D2C7DD5D4E7A8D3C5ED74D1" Content-Language: en-US Archived-At: Subject: Re: [xml2rfc] tag DL errors on draft submission 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, 13 Dec 2019 13:46:05 -0000 This is a multi-part message in MIME format. --------------8D2C7DD5D4E7A8D3C5ED74D1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Here they are. On 12/13/19 6:03 AM, Julian Reschke wrote: > On 13.12.2019 11:30, Robert Moskowitz wrote: >> ... >> OK. I will make the change, but it worked just fine in: >> >> draft-moskowitz-orchid-cshake-01 >> >> And in both cases xml2rfc --v3 had no problem with it. >> ... > > Please provide the sources for both files, and I can have a look what's > different. > > Best regards, Julian --------------8D2C7DD5D4E7A8D3C5ED74D1 Content-Type: text/xml; charset=UTF-8; name="draft-moskowitz-hip-new-crypto-03.xml" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="draft-moskowitz-hip-new-crypto-03.xml" New Cryptographic Algorithms for HIP HTT Consulting

Oak Park MI 48237 USA rgm@labs.htt-consult.com

AX Enterprize

4947 Commercial Drive Yorkville NY 13495 USA stu.card@axenterprize.com

AX Enterprize

4947 Commercial Drive Yorkville NY 13495 USA adam.wiethuechter@axenterprize.com

Internet HIP RFC Request for Comments I-D Internet-Draft HIP This document provides new cryptographic algorithms to be used with HIP. The Edwards Elliptic Curve and the Keccak sponge functions are the main focus. The HIP parameters and processing instructions impacted by these algorithms are defined.

This document adds new cryptographic algorithms for HIPv2. This includes: New elliptic curves for ECDH. The Edwards Elliptic Curve Digital Signature Algorithm (EdDSA) used in Host Identities (HI) and for Base Exchange (BEX) signatures. Hashes used in Host Identity Tag (HIT) generation, and wherever else hashes are needed. Keyed hashes used for KEYMAT generation and packet MACing operations. AEAD and stream ciphers to use in HIP and HIP enabled secure communication protocols. The hashes and encryption are all built on the Keccak sponge function. These additions reflect selection of advances in the field of cryptography that would best benefit HIP, particularly in constrained devices and communications.

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

Keccak (KECCAK Message Authentication Code):: The family of all sponge functions with a KECCAK-f permutation as the underlying function and multi-rate padding as the padding rule.
KMAC (KECCAK Message Authentication Code):: A PRF and keyed hash function based on KECCAK.
cSHAKE (The customizable SHAKE function):: Extends the SHAKE scheme to allow users to customize their use of the function.
SHAKE (Secure Hash Algorithm KECCAK):: A secure hash that allows for an arbitrary output length.
PRF (Pseudorandom Function):: A function that can be used to generate output from a random seed such that the output is computationally indistinguishable from truly random output.
capacity:: In the sponge construction, the width of the underlying function minus the rate.
rate:: In the sponge construction, the number of input bits processed per invocation of the underlying function.
XOF (eXtendable-Output Function):: A function on bit strings (also called messages) in which the output can be extended to any desired length.

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.

Elliptic curves Curve25519 and Curve448 RFC 7748) are specified here for use in the HIP Diffie-Hellman exchange. Curve25519 and Curve448 are already defined in Section 5.2.1 of , using the HIP-DEX CKDF. Here they are defined for using the new KMAC NIST SP 800-185 derived KDF in .

The DIFFIE_HELLMAN parameter may be included in selected HIP packets based on the DH Group ID selected. The DIFFIE_HELLMAN parameter is defined in Section 5.2.7 of . The following Elliptic Curves are defined here:

Group KDF Value Curve25519 [RFC7748] KKDF 13 Curve448 [RFC7748] KKDF 14 A new KDF for KEYMAT, Section 6.5 of and Section 6.3 of using Keccak is defined in .

Edwards-Curve Digital Signature Algorithm (EdDSA) (RFC 8032) are specified here for use as Host Identities (HIs).

The HOST_ID parameter specifies the public key algorithm, and for elliptic curves, a name. The HOST_ID parameter is defined in Section 5.2.19 of .

Algorithm profiles Values EdDSA 13 [RFC8032] (RECOMMENDED) For hosts that implement EdDSA as the algorithm, the following ECC curves are available:

Algorithm Curve Values EdDSA RESERVED 0 EdDSA EdDSA25519 1 [RFC8032] EdDSA EdDSA25519ph 2 [RFC8032] EdDSA EdDSA448 3 [RFC8032] EdDSA EdDSA448ph 4 [RFC8032]

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 ID is defined, 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 RESERVED 0 0x00 EdDSA/SHAKE128 5 0x50 (RECOMMENDED) The following table provides more detail on the above HIT Suite combinations. The input for each generation algorithm is the encoding of the HI as defined in . The output is 96 bits long and is directly used in the ORCHID. Index Hash function HMAC Signature algorithm family Description 5 SHAKE128 KMAC128 EdDSA EdDSA HI hashed with cSHAKE128, output is 96 bits

The Keccak sponge function is the basis for the new SHA-3, standard NIST FIPS 202, and the customized XOF functions in NIST SP 800-185. These are used here as an alternative to all the hashing functions in HIP. Hardware implementation of Keccak in VHDL is available from Keccak.

Keccak is described as a sponge function. The analogy to a sponge is that an arbitrary number of input bits are "absorbed" into the state of the function, after which an arbitrary number of output bits are "squeezed" out of its state. The Keccak function is defined to have a width of b bits. Where b is the capacity (c) + rate (r). The rate is the number of bits "fed" into the sponge at a time. The capacity is twice the desired hash "strength" and part of the sponge width. b is one of the set {25, 50, 100, 200, 400, 800, 1600}. In FIPS 202, b=1600. Thus a hash strength of 128 bits can be delivered with c=256 and r=1344, or 168 byte segment input to the sponge. Keccak can also provide a hash strength of 128 bit with b=800 (r=544 or 68 bytes) and b=400 (r=144 or 18 bytes). 256 bit strength can only be provided with b=1600 or 800. FIPS 202 does not specify use of these smaller values for b which may be preferred in memory constrained devices, processing relatively short input strings. Future work will determine if the smaller values for b result in a significant performance/memory improvement to warrant their use.

The RHASH is the general term used throughout to refer to the hash used for a specific HIT suite. For this addendum SHAKE128 is used, even for HIs of EdDSA448. Unless otherwise specified, L of SHAKE128 is 256, resulting in a similar output to SHA256. Any truncation used for, older, fixed output hashes is still used. This is to simplify code integration. One exception to this is in .

The HIP_MAC and HIP_MAC2 parameters in use HMAC . This performs two hashes on a string with a key for a keyed hash the length of the underlying hash. Here, KMAC from NIST SP 800-185 is used. This is a single pass using the underlying cSHAKE function. The function call is:

KMAC128(Key, Input String, 256, "")

HIP encrypted parameters use the HIP_CIPHER, Section 5.2.8 of . The Keccak Keyak cipher, , is recommended. Keyak is a candidate in the NIST Lightweight Cryptography competition and is consistent with the overall approach in this addendum to use Keccak functions for simplicity in design and implementation.

The HIP_CIPHER parameter values for Keyak are:

hip_cipher Suite ID Value RIVER KEYAK 6 (Keyak) LAKE KEYAK 7 (Keyak) For use as the HIP Cipher, the TAG generated in Keyak is length 0. The Keyak SUV is the key plus IV specified for the encrypted parameter. River Keyak MAY be used for , in place of AES-CTR. Lake Keyak can provide 256 bits of security by following the recommendations for the Keyak cipher.

The EdDSA/cSHAKE based HITs vary slightly the ORCHID generation method described in section 3.2 of . The XOF functionality of cSHAKE produces an output of L bits. This replaces the Encode_96 function in the ORCHID generation. For identities that are EdDSA public keys, ORCHIDs will be generated per the process defined in Using cSHAKE in ORCHIDs

The KMAC function provides a new, more efficient, key derivation function over HKDF . This will be referred to as KKDF. The choice of KMAC128 or KMAC256 is based on the strength of the output key material. For 256 bits of strength equivalent to HMAC-SHA256, use KMAC256. Per NIST SP 800-56Cr1, Section 4.1, Option 3:

OKM = KMAC[128|256](salt | info, IKM, L, S) L is the derived key bit length. Since 4 HIP keys are "drawn" from this output, the length is 4 * HIP_key_size. Per ASIACRYPT 2017, pp. 606-637 each of these derived keys will have the same strength as the Diffie-Hellman shared secret. S is the byte string 01001011 || 01000100 || 01000110, which represents the sequence of characters “K”, “D”, and “F” in 8-bit ASCII. Salt and info are derived as defined in or . There are special security considerations for IKM per . The two HIs MUST be used in constructing IKM as follows:

IKM = Diffie-Hellman secret | HI-R | HI-I These are separately DER encoded.

Appendix B of NIST SP 800-185 defines how to use SHAKE, cSHAKE, or KMAC as a PRF.

IANA will need to make the following changes to the "Host Identity Protocol (HIP) Parameters" registries:

Diffie Hellman:: This document defines the new Curve25519 and Curve448 for the Diffie-Hellman exchange (see ).
Host ID:: This document defines the new EdDSA Host ID (see ).
HIT Suite ID:: This document defines the new HIT Suite of EdDSA/cSHAKE (see ).
HIP Cipher:: This document defines the new Keyak ciphers for HIP encrypted parameters (see ).

warns about using Curve25519 and Curve448 in Diffie-Hellman for key derivation: Designers using these curves should be aware that for each public key, there are several publicly computable public keys that are equivalent to it, i.e., they produce the same shared secrets. Thus using a public key as an identifier and knowledge of a shared secret as proof of ownership (without including the public keys in the key derivation) might lead to subtle vulnerabilities. This applies to , but may have broader consequences. Thus the two Host IDs are included with the Diffie-Hellman secret.

Quynh Dang of NIST gave considerable guidance on using Keccak and the NIST supporting documents. Joan Deamen of the Keccak team was especially helpful in many aspects of using Keccak, particularly with the KEYMAT section and the strength of the derived keys.

Full-State Keyed Duplex with Built-In Multi-user Support The Keccak Function

Radboud University

STMicroelectronics

The Keyak Cipher

Radboud University

STMicroelectronics

--------------8D2C7DD5D4E7A8D3C5ED74D1 Content-Type: text/xml; charset=UTF-8; name="draft-moskowitz-orchid-cshake-01.xml" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="draft-moskowitz-orchid-cshake-01.xml" Using cSHAKE in ORCHIDs HTT Consulting

Oak Park MI 48237 USA rgm@labs.htt-consult.com

AX Enterprize

4947 Commercial Drive Yorkville NY 13495 USA stu.card@axenterprize.com

AX Enterprize

4947 Commercial Drive Yorkville NY 13495 USA adam.wiethuechter@axenterprize.com

Internet HIP RFC Request for Comments I-D Internet-Draft HIP This document specifies how to use the cSHAKE hash for ORCHID generation and allows for varying sized hashes in the ORCHID along with additional information within the ORCHID. It is an addendum to ORCHIDv2.

This document adds the Keccak based cSHAKE XOF hash function from NIST SP 800-185 to ORCHIDv2. cSHAKE is a variable output length hash function. As such it does not need the truncation operation that other hashes need. The invocation of cSHAKE specifies the desired number of bits in the hash output. cSHAKE is used, rather than SHAKE from NIST FIPS 202, as cSHAKE has a parameter 'S' as a customization bit string. This parameter will be used for including the ORCHID Context Identifier in a standard fashion. An additional change to ORCHID construction will allow for shorter hash output lengths to permit inclusion of additional information like Hierarchical HITs into the ORCHID.

Signifies concatenation of information - e.g., X | Y is the concatenation of X and Y.

Keccak (KECCAK Message Authentication Code):: The family of all sponge functions with a KECCAK-f permutation as the underlying function and multi-rate padding as the padding rule.
cSHAKE (The customizable SHAKE function):: Extends the SHAKE scheme to allow users to customize their use of the function.
SHAKE (Secure Hash Algorithm KECCAK):: A secure hash that allows for an arbitrary output length.
XOF (eXtendable-Output Function):: A function on bit strings (also called messages) in which the output can be extended to any desired length.

ORCHIDv2 is currently defined as consisting of three components:

This addendum will be constructed as follows:

The 96 bits currently allocated to the Encode_96 function can be divided in any manner between the additional information and the hash output. Care must be taken in determining the size of the hash portion, taking into account risks like pre-image attacks. Thus 64 bits as used in Hierarchical HITs may be as small as is acceptable.

With this addendum, the decoding of an ORCHID is determined by the Prefix and OGA ID. ORCHIDv2 decoding is selected when the Prefix is: 2001:20::/28. For Heirarchical HITs, the decoding is determined by the presence of the HHIT Prefix as specified in the HHIT document.

ORCHIDv2 has a number of inputs including a Context ID, some header bits, the hash algorithm, and the input bitstream, normally just the public key. The output is a 96 bit value. This addendum adds a different encoding process to that currently used. The input to the hash function explicitly includes all the fixed header content plus the Context ID. The fixed header content consists of the Prefix, OGA ID, and the Additional Information. Secondly, the length of the resulting hash is set by the rules set by the Prefix/OGA ID. In the case of Hierarchical HITs, this is 64 bits. To achieve the variable length output in a consistent manner, the cSHAKE hash is used. For this purpose, cSHAKE128 is appropriate. The the cSHAKE function call for this addendum is:

cSHAKE128(Input, L, "", Context ID) Input := Prefix | OGA ID | Additional Information | HOST_ID L := Length in bits of hash portion of ORCHID Hierarchical HIT uses the same context as all other HIPv2 HIT Suites as they are clearly separated by the distinct HIT Suite ID.

The EdDSA/cSHAKE based HITs in New Cryptographic Algorithms for HIP is the first HIP Suite to use cSHAKE, thus using this addendum.

Hierarchical HITs (HHITs) is the first HIT construct that specifies the need of dividing the 96 bits available to ORCHID into its Hierarchy ID (HID) and HI Hash, thus using this addendum. HHITs use a unique Context ID as well as a Prefix different from HIPv2. The different Prefix enables receivers to properly decode the HID out of the HIT and validate the HIT, given the HI.

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 "Additional Information" value. Some registration process should be used to reject a collision, forcing the client to generate a new HI and thus HIT and reapplying to the registration process.

TBD.

A 64 bit hash space presents a real risk of second pre-image attacks. A Registry service effectively block attempts to "take over" such a HIT. It does not stop a rogue attempting to impersonate a known HIT. This attack can be mitigated by the Responder using DNS to find the HI for the HIT or the RVS for the HIT that then provides the registered HI.

Quynh Dang of NIST gave considerable guidance on using Keccak and the NIST supporting documents. Joan Deamen of the Keccak team was especially helpful in many aspects of using Keccak.

The Keccak Function

Radboud University

STMicroelectronics

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

--------------8D2C7DD5D4E7A8D3C5ED74D1-- From nobody Fri Dec 13 05:47: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 391D11200FE for ; Fri, 13 Dec 2019 05:47:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bY4AAulf4dWY for ; Fri, 13 Dec 2019 05:47:32 -0800 (PST) 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 0A84012003E for ; Fri, 13 Dec 2019 05:47:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 5F34F62122; Fri, 13 Dec 2019 08:47:31 -0500 (EST) 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 Kw9H-kNevuWt; Fri, 13 Dec 2019 08:47:28 -0500 (EST) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id CA5AB6211F; Fri, 13 Dec 2019 08:47:27 -0500 (EST) To: Julian Reschke , "xml2rfc@ietf.org" References:

<10d33dfd-411c-14cf-51ae-79e28b91fa0c@gmx.de> From: Robert Moskowitz Message-ID: <17e91dbb-66ef-7294-5f38-4e055c88af21@htt-consult.com> Date: Fri, 13 Dec 2019 08:47:25 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <10d33dfd-411c-14cf-51ae-79e28b91fa0c@gmx.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [xml2rfc] tag DL errors on draft submission 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, 13 Dec 2019 13:47:33 -0000 OH, I have not submitted draft-moskowitz-orchid-cshake-01 yet. I only made the changes to the definition section in preparation for making other changes. So the submit rejection is only on the new-crypto xml. Both passed the xml2rfc script. On 12/13/19 6:03 AM, Julian Reschke wrote: > On 13.12.2019 11:30, Robert Moskowitz wrote: >> ... >> OK. I will make the change, but it worked just fine in: >> >> draft-moskowitz-orchid-cshake-01 >> >> And in both cases xml2rfc --v3 had no problem with it. >> ... > > Please provide the sources for both files, and I can have a look what's > different. > > Best regards, Julian From nobody Fri Dec 13 06:04: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 EB22112084A for ; Fri, 13 Dec 2019 06:04:36 -0800 (PST) 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 sqiyRznkMCYt for ; Fri, 13 Dec 2019 06:04:35 -0800 (PST) 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 B20B8120058 for ; Fri, 13 Dec 2019 06:04:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1576245866; bh=eFdwm8F4+JX57pEzLLbK1OkNNUKgqvNgdRnBRp1EyZQ=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=E17AfbveYxibYrlWtFpHYZrX/1Sk0VJ6J3JVVwkskbvaW3oujmUKmaJMHo8GPM5nc JoYEl7xoN/0O/7aURhxim60G7QLWqlyA9S5q6wv4mYk53eEAnw0F0V/qM4P3ritOsD Zod0zYIxaSIDM7fe4TUiuoVGX/Yyl1k5vovacMWI= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MzyuS-1hl2J215WA-00x2Id; Fri, 13 Dec 2019 15:04:26 +0100 To: Robert Moskowitz , "xml2rfc@ietf.org" References:

<10d33dfd-411c-14cf-51ae-79e28b91fa0c@gmx.de> <17e91dbb-66ef-7294-5f38-4e055c88af21@htt-consult.com> From: Julian Reschke Message-ID: Date: Fri, 13 Dec 2019 15:04:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <17e91dbb-66ef-7294-5f38-4e055c88af21@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:oiXp3qvlwFdRZ0ZyOVmZe9dOqSne9VEjloljIqp7NPFmxIgpyVD iloA8GzZZHSbxOK7oFPzEAyfqdjl0/KHVtfVZoDAPwh/dqYSxgQaPTWiAgMq3f2IBw3HoKl JkMHxuV+gJXArpAv+rXkWGJnX8j5midcEl2XV8+2JDFMSGBeumgRrkAMJWA710EChiAr8Sr T/8w3YnhzEY5db169YVbQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:X+h7rvOLl6Y=:WylhWfj6UfyTl6Bq+0m/bP jkra817igPtaqcOCFUMCdAGCBcNyGBR7C0562Nr+4fhnJAw5NTBJ825pVwVRjtRI4GRyNvnMJ SD0MUD+o8hVuTxsogl0jP+H3Y6cgo/sNMapMThd4RztgceomUAeeJNKMKUzINdjTizfs6LZfJ 0X9pc9xsRnvI1K5aG/CxN7zH4QXSJphyoQnYQDL1BeenSllr7YS30BPLH+2PO/2xrPXY3iPNP iledYDQG/5mmkeG6XW7GFfFHLYxLfP9wPmkUOgkte2ySwEqk8/DPk4iNq6q4bn77U+ktDPAYt 2KjjSFhr1QHYzrDB9Yi2mTCIqtgyv8AeOAVZYUR9BWoqviGHQeEWZGKCW8ee7kxFf5yXahdkV EclOU2GxR+D1rhmO2DI9VTBbaw/BFv+vFjViu+lNEHf26g7VmPTw6wk2WqJZfBimkbwSWh6Bn s+qly+wBLpVqGMJFme/ADVzH2/B1PjjtJGrZm0UsbGEylhZoADeAV5FHCyBs2/NgF7vyr4aNY mL3F3/lBqouOEm0OX87h/3rt27qAOjn55rKQSItBMV4tld1yc+BdnWj5S1j2Pxu0AfJe6529x hjkRDsUdWetoR25MZ8v4dehiQbt4NFbCRaOYhV2jTHBOSrIQGz4Y5/uvjxgeb8418oQO3ZG1O clpEMk/I/cvQMucNv0w3Clgno2vcxteJbW9GNdx5w0g6xw/udojRNePnJHMs3FVlqc4LEcYy8 Ykldth7rNYFaF4G8Wi2Eoq5N/GJF2GEiNaYpfTz/K04pXWHVdzBl6NgP4lKcq6TE/gzjS6hTa 5mlN+DXKUMcju18RXT/dZTzc3HdCaeNJ82r+rPc1fC/1pzfwBmN9y/SUsI1mrCaKuxoF2+F5O 5/WJ3pMGmRRUIQMbcaDJpVdx6M9ZibBi7AuWJZHOYp4x8Hi4t1domUVtaIb1d5ycZGlYpURWh 3J67RN3EwywELLJdkRzdkSdAXen/LPZOWKvW8bioAo6s3I4c2s/m9oJ5PLP0zRhhj6DrV4DS8 mlbYQDSzFQtMBCoKuTymT5uZXBsziOMErqTFN4J8UoMzQBglh3xJQKXQYllgXGaDpFgcqPO/D 1d6XsMPbTBDxmGD5yLBfyoQImPfOrwHY092jp7OvnOhbvfkX3X3oN4fxgGCYPqzIbAYa2Sl5T w12FnUIDUagBsI/5jpNYj+KKqxiZSK1b/EIG6f0hKwuUZnrZ9a0Ad3vmMH/h2cdENFhWv1iiM GwwgR/u7Wlp9YtltHPqZWuUBeePu3t7EC9tLBTr6UtpuLDSDNEm38/tQBdZg= Archived-At: Subject: Re: [xml2rfc] tag DL errors on draft submission 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, 13 Dec 2019 14:04:37 -0000 On 13.12.2019 14:47, Robert Moskowitz wrote: > OH, I have not submitted draft-moskowitz-orchid-cshake-01 yet.=C2=A0 I o= nly > made the changes to the definition section=C2=A0 in preparation for maki= ng > other changes. > > So the submit rejection is only on the new-crypto xml.=C2=A0 Both passed= the > xml2rfc script. > ... Interesting. Both pass for me with "--v3"; both fail for me without. The fact that

is accepted as a child node of seems to be a bug in xml2rfc; you should report it at . Best regards, Julian From nobody Fri Dec 13 06:10: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 7A190120854 for