From nobody Mon Feb 1 06:38:44 2021 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF903A11D4; Mon, 1 Feb 2021 06:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=RKjZmGUM; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=KI69CEWV 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 7Os4o_8NBv0K; Mon, 1 Feb 2021 06:38:36 -0800 (PST) Received: from che.mayfirst.org (unknown [162.247.75.117]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B033D3A11D5; Mon, 1 Feb 2021 06:38:36 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1612190314; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=+MDl/vPODzECNZovkFQMOMTeZcGhbK2Ch4PVuFM0acU=; b=RKjZmGUMgMOwLH/tgeORj7x434jt5DFVYIvGFZuJ4VtGq13p1Z6bIpRAbs1+0zjNvUhqa CiQuLyP49HLMBBTDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1612190314; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=+MDl/vPODzECNZovkFQMOMTeZcGhbK2Ch4PVuFM0acU=; b=KI69CEWVZyJ9giqHVH8dJ0mnvPwFYKORwW0ZUCb1S85DWNWJE63P5LZ17TTSu/GfzOtSJ WdESoGuVLVUxTUwr+OooJgKShhGc45On/o1QGqb6C2eieNhJcYK0iFXrw7iDyzbNlek+/2K sIE6LyxaVMftUVChc6OBM39TRbCIWu5067XryFFTfGRbA/IJbQXKQ7gPNL2pT0pQcq0aXt0 Bh66ukwfwhwD8h6i41aNIorpSq6WLUsAajXI+W5dKppEDquSRwtdaVSeXiRIdTLrapGDNaT RTUIsexSJnncPDE9LBw0lSOjp8mjslkE8lu/qigonAXggLmwRtA0gn7tFoGA== Received: from fifthhorseman.net (lair.fifthhorseman.net [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id B15C1F9A7; Mon, 1 Feb 2021 09:38:34 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 9958F20478; Sat, 30 Jan 2021 11:06:40 -0500 (EST) From: Daniel Kahn Gillmor To: Lars Eggert Cc: xml2rfc-dev@ietf.org, xml2rfc@ietf.org In-Reply-To: <342339E7-A47C-4C51-8852-7FFBB6A8C750@eggert.org> References: <8735yje4kt.fsf@fifthhorseman.net> <342339E7-A47C-4C51-8852-7FFBB6A8C750@eggert.org> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH Date: Sat, 30 Jan 2021 11:06:38 -0500 Message-ID: <87lfcacstt.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [xml2rfc-dev] Unicode box-drawing for a new --table-borders value? X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2021 14:38:38 -0000 --=-=-= Content-Type: text/plain On Sat 2021-01-30 07:22:43 +0200, Lars Eggert wrote: > I think that would be excellent, but AFAIK Unicode can (still) only be > used in contact names (see the recent "Unicode in xml2rfc v3" thread > over on rfc-interest@). I really hope we can just get to an agreement > to allow Unicode anywhere in the document. whoops, i've been using unicode (in particular, the box-drawing characters and a few fancy arrows) to pretty good effect (imho) in several I-Ds already, for example: https://www.ietf.org/archive/id/draft-dkg-lamps-e2e-mail-guidance-00.html#name-multilayer-cryptographic-en That document would be much harder to read and understand (and probably much longer) without the compact representations of MIME message structure. Reading the thread you reference suggests that those characters are probably acceptable within an "artwork" or verbatim block, but maybe not in the regular text. That would mean unicode *can* show up in other places in the .txt versions of the RFC, which is the only context where --table-borders really matters, afaict. So it seems like the constraints on unicode in the normal text shouldn't be any formal problem with the .txt translation. Does that seem like a plausible analysis? Hopefully this change would just be a "simple matter of programming" in xml2rfc itself, and not some sort of policy quagmire. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQttUkcnfDcj0MoY88+nXFzcd5WXAUCYBWEEAAKCRA+nXFzcd5W XIe+AQC3ZrafiZimeZKtbBNelCZVCago7KL0MVYNt7+0TIjh1QD/aU3yyecDUuUv wmoGeQx7P7rLH9G2GluZwwxvXqMZyQw= =nTeO -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Feb 1 06:53:47 2021 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDBF23A11EE; Mon, 1 Feb 2021 06:53:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=eggert.org 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 D4Lg-XD35rpU; Mon, 1 Feb 2021 06:53:44 -0800 (PST) Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (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 CBA3A3A11ED; Mon, 1 Feb 2021 06:53:43 -0800 (PST) Received: from [IPv6:2a00:ac00:4000:400:acf1:c447:f5f0:6aa9] (unknown [IPv6:2a00:ac00:4000:400:acf1:c447:f5f0:6aa9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 26F2F600057; Mon, 1 Feb 2021 16:53:34 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1612191214; bh=FEFoWdQZTedqCJULJ1Fa9sk8UH98YULZLT6C4MF3KzM=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=xqdWK1rG9gWO9ugIezOlMzTSnew+FWQ+gnioOL1YSEcLTjYO0agJPNlgOTBijV5/5 rciL4HHreEWkmis6PmlRD0NBcta4llm/qEYAvUCXfG0rTQ1SBJVPXlZw5/iIbWuiyV HzpD0rqkkb1RXHZ0zX4FhR/p3VJ6aK2GlEthWfPM= From: Lars Eggert Message-Id: <450E303F-B4E3-451E-B1BC-FA92DBC29063@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_9EA3E781-9965-4768-B3E3-EDD94B82B541"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Mon, 1 Feb 2021 16:53:33 +0200 In-Reply-To: <87lfcacstt.fsf@fifthhorseman.net> Cc: xml2rfc-dev@ietf.org, xml2rfc@ietf.org To: Daniel Kahn Gillmor References: <8735yje4kt.fsf@fifthhorseman.net> <342339E7-A47C-4C51-8852-7FFBB6A8C750@eggert.org> <87lfcacstt.fsf@fifthhorseman.net> X-MailScanner-ID: 26F2F600057.AF294 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [xml2rfc-dev] Unicode box-drawing for a new --table-borders value? X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2021 14:53:46 -0000 --Apple-Mail=_9EA3E781-9965-4768-B3E3-EDD94B82B541 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2021-1-30, at 18:06, Daniel Kahn Gillmor = wrote: > On Sat 2021-01-30 07:22:43 +0200, Lars Eggert wrote: >> I think that would be excellent, but AFAIK Unicode can (still) only = be >> used in contact names (see the recent "Unicode in xml2rfc v3" thread >> over on rfc-interest@). I really hope we can just get to an agreement >> to allow Unicode anywhere in the document. >=20 > whoops, i've been using unicode (in particular, the box-drawing > characters and a few fancy arrows) to pretty good effect (imho) in > several I-Ds already, for example: >=20 > = https://www.ietf.org/archive/id/draft-dkg-lamps-e2e-mail-guidance-00.html#= name-multilayer-cryptographic-en Ah! You're right, in artwork, there is no issue. I was trying to use Unicode in the text, which has the restriction I = mentioned. Lars --Apple-Mail=_9EA3E781-9965-4768-B3E3-EDD94B82B541 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmAYFe0ACgkQVLXDCb9w wVcvehAAt0a3dG9LDkQ8GMEN9PJaEN/p5bhQRLQCm/wzBfKgfvvKdPjh5b/SS6U6 dI2goNzX9Z+94FB5umWOUm/VbZkg01orodw+7faSh68EAgU9wfOmTh2B/xuLtn95 Eaqb+yOuIKW2Tk3qxWS0NE4lLjICCUjV0aaK4UNLgZkV+VK8EEJQKR1MsBgWUaUQ v2V7xD8lYm6Nw7CLg+nQsX4qK05wqA76HjNyyBZQeZ15Dm9YyFOa+A9PvxE2EDGr 2QESeJSfyLt+6f82NA/hcmbgZjMjH337Zt7X//sja1NRybbTcsGd+TWAUXKbOMAl 2ANXaP8LUG4d1AMV3lssNNZGtnAihtTWCvor0pI+SfUvvdAtDDrDDCINM6ucWHes 604kWm3HPhlC8lAzebYujD/XdNRm8P1YKF750+y5oM2IajdHeiJ935YYzMjiLkAS 6bPfdqsnM+sNrOTKHppazCzOVgOBFFADNwbWgjYYZbbOzFQqKfyOlJuNaRoops0b QmOtQYBaS20RA9jRsdvviZLqofb6hSdQPWOlw6PL0+8l/aHJbSMi+FXlawuKBXmS QVw62VzOR/IgnswQpzGXtRvj+x9vFTYijFnk6ZY7n5JfTbbu+OtPDqB0Pn10PI2K PgzYmP0WO0pbPGhcpV1KXYpSE27YRPpqb3R/dNcrHO1eesLJc1U= =mcfY -----END PGP SIGNATURE----- --Apple-Mail=_9EA3E781-9965-4768-B3E3-EDD94B82B541-- From nobody Mon Feb 1 07:01:23 2021 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6544C3A11F4; Mon, 1 Feb 2021 07:01:21 -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, RCVD_IN_DNSWL_BLOCKED=0.001, 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 Ef4r9vcZ3omA; Mon, 1 Feb 2021 07:01:19 -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 08DFC3A11F2; Mon, 1 Feb 2021 07:01:18 -0800 (PST) Received: from [192.168.217.118] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (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 4DTrk46f2Rz10Bg; Mon, 1 Feb 2021 16:01:16 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: <87lfcacstt.fsf@fifthhorseman.net> Date: Mon, 1 Feb 2021 16:01:16 +0100 Cc: Lars Eggert , xml2rfc@ietf.org, xml2rfc-dev@ietf.org X-Mao-Original-Outgoing-Id: 633884476.273326-5ca77b8bed33e332fc3da64802d6fe2b Content-Transfer-Encoding: quoted-printable Message-Id: References: <8735yje4kt.fsf@fifthhorseman.net> <342339E7-A47C-4C51-8852-7FFBB6A8C750@eggert.org> <87lfcacstt.fsf@fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [xml2rfc-dev] Unicode box-drawing for a new --table-borders value? X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2021 15:01:21 -0000 On 2021-01-30, at 17:06, Daniel Kahn Gillmor = wrote: >=20 > Signed PGP part > On Sat 2021-01-30 07:22:43 +0200, Lars Eggert wrote: >> I think that would be excellent, but AFAIK Unicode can (still) only = be >> used in contact names (see the recent "Unicode in xml2rfc v3" thread >> over on rfc-interest@). I really hope we can just get to an agreement >> to allow Unicode anywhere in the document. >=20 > whoops, i've been using unicode (in particular, the box-drawing > characters and a few fancy arrows) to pretty good effect (imho) in > several I-Ds already, for example: >=20 > = https://www.ietf.org/archive/id/draft-dkg-lamps-e2e-mail-guidance-00.html#= name-multilayer-cryptographic-en >=20 > That document would be much harder to read and understand (and = probably > much longer) without the compact representations of MIME message > structure. >=20 > Reading the thread you reference suggests that those characters are > probably acceptable within an "artwork" or verbatim block, but maybe = not > in the regular text. That is how xml2rfc is currently programmed. This is fine for box-drawing, but not so great for =CE=B1 and =CE=B2, = which need to be referenceable in the text. (A quick fix to get a preview of what will be possible with an updated = policy is in http://www.tzi.de/~cabo/contact-hack.sh =E2=80=94 you can = simply reinstall xml2rfc if that screws up things for you. This fix is = necessary to build Lars=E2=80=99s 8132bis draft.) > That would mean unicode *can* show up in other places in the .txt > versions of the RFC, which is the only context where --table-borders > really matters, afaict. So it seems like the constraints on unicode = in > the normal text shouldn't be any formal problem with the .txt > translation. Does that seem like a plausible analysis? >=20 > Hopefully this change would just be a "simple matter of programming" = in > xml2rfc itself, and not some sort of policy quagmire. I don=E2=80=99t think there is a change needed to support the artwork in = the above-mentioned draft. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Feb 1 07:17:09 2021 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7FD3A1207 for ; Mon, 1 Feb 2021 07:17:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 lgm_iTAH6HRS for ; Mon, 1 Feb 2021 07:17:07 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 11F783A1201 for ; Mon, 1 Feb 2021 07:17:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1612192622; bh=LIL2E/Negse0rOMb0zZXwFdMVNHx3OaaLRDnTdn5YO4=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=d82zU+0SSPhULQeFCQ/gM0dXgbUWhVoJ+WDAyHyJe1uPXKlbqP9V6vAazjgII61no 3yk8AOs8MjMM2jEonOQOYj5BPrhc7kGv8IpbiO+9X2uSlnuqEAd3L4nxNxlxSiZhwa jzAvJ62uemfEPyfhl6R34DtZodrAHDhV8rqzQYv0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.236] ([217.91.35.233]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M3DJl-1l5lco26X7-003dMf for ; Mon, 01 Feb 2021 15:52:55 +0100 To: xml2rfc-dev@ietf.org References: <8735yje4kt.fsf@fifthhorseman.net> <342339E7-A47C-4C51-8852-7FFBB6A8C750@eggert.org> <87lfcacstt.fsf@fifthhorseman.net> From: Julian Reschke Message-ID: <078f11bc-2adf-5126-a9b6-20cf3167d554@gmx.de> Date: Mon, 1 Feb 2021 15:52:54 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <87lfcacstt.fsf@fifthhorseman.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:g6Xzz/SdSYAbz+Bia5rgZF3QtbkdpQJ9VI24hsyV+dembQEdmQG pxlAIesAxqCvAzvBKH9o97rQHdIDb9/NYO9orZEP/b+VIEpoO/k9Qs82Hqn6YiUSdt4CGoK W+poa1HU1XUidNaSoghc5EMaUvw0LI1Bwx3sb91ahHqYLpKdXo8TWYJji2f8mJ7VSygukfk H8CceZ/AsEqMD2mpHHp7g== X-UI-Out-Filterresults: notjunk:1;V03:K0:lWPph3eh+vs=:KgEKvVaO5Q8CqDK/Fu7/xz Ai52KzmJizRmKGjVs/nYOy7o/K0Aklnbh4ALlNu/TDSXPKF0iSA+dWiFf/njSxyqnY71U+DNw D+ZnMO6mkAIXlXjWplUprUyEo2/84CbxOGXzi9HhnlrvrDjgiWXtkGhzSt0VbdTeKEEjiKI71 u1t2tmHrxMpR6j1QRSTlLmJ/Db39tgfzkwsj7o/aNauTay94Qv0Fv3eko3dmAnIZD9JcEFSv0 M4Z8n7elO+NbUDwYH6MsUYIxtSL2UNYAKfVDp9xmOuN0sJBcmsQwE0hzvlPr5fiILEbjkq7cF Zdq6CgwZab53bigpr1g28qehktrCbhvVfZg5PhRYknofGxL9rKWKy0ibc5Prht/Dla8MSP3Dp Z0QIymrZtXzuuXja5yaGc3zBCJImF9AoG7LFvuOfWq1VlNCu9SsT0Mzq+K9x9BGHz5LZ7EzsM 9qMC1axpJGF3ekPr2FlzCCpMr7gn5sh22IRPL8NifB2HaCGrPCSg/AeFTOIHtmph5folPUIC1 69yIbAgQxbIXpPsuufdZSjJfuAbJpBX38YZSp73Fc+ubo+TRqh8WUbcdqZZr3dzdac8rB90rd RsSSanB21OIuV+teKYgeyaauqXEymSJcA7LgNzt1bYStLacs4957QY1IweilCu7rVW1w1tplo DfunpWjZXepdFEM1whDNNB35Id11NZ+KARuhj7mGID8z0dZtvNNHrMmIlLT63n+dJOP5oXbYI sicaiFcq+CXx9eF0pkdj9AFmBNiTmxqLCKRPbzDOZuLn4YFMohmRCunMAocrHSCUpWqU8+CKB 87joNUPDUrwWELNOOEnKLfsUhW86jdCuEvgGRpBLtS64m2AwYWcrkKpOAcmtYO/hcQeZkPbqr xf83tgk0H1JaBJKfOfQw== Archived-At: Subject: Re: [xml2rfc-dev] Unicode box-drawing for a new --table-borders value? X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2021 15:17:09 -0000 Am 30.01.2021 um 17:06 schrieb Daniel Kahn Gillmor: > On Sat 2021-01-30 07:22:43 +0200, Lars Eggert wrote: >> I think that would be excellent, but AFAIK Unicode can (still) only be >> used in contact names (see the recent "Unicode in xml2rfc v3" thread >> over on rfc-interest@). I really hope we can just get to an agreement >> to allow Unicode anywhere in the document. > > whoops, i've been using unicode (in particular, the box-drawing > characters and a few fancy arrows) to pretty good effect (imho) in > several I-Ds already, for example: > > https://www.ietf.org/archive/id/draft-dkg-lamps-e2e-mail-guidance-0= 0.html#name-multilayer-cryptographic-en > > That document would be much harder to read and understand (and probably > much longer) without the compact representations of MIME message > structure. > > Reading the thread you reference suggests that those characters are > probably acceptable within an "artwork" or verbatim block, but maybe not > in the regular text. Right. This is intended mainly for examples that require use of non-ASCII characters, not for drawing symbols (for which the recommendation might be "use SVG instead"). > That would mean unicode *can* show up in other places in the .txt > versions of the RFC, which is the only context where --table-borders > really matters, afaict. So it seems like the constraints on unicode in > the normal text shouldn't be any formal problem with the .txt > translation. Does that seem like a plausible analysis? > > Hopefully this change would just be a "simple matter of programming" in > xml2rfc itself, and not some sort of policy quagmire. It depends on how you read RFC 7997 - and yes, I believe it intends to describe the *output* of the text generation step, thus a change of that document would be needed (and believe me, it was really hard to agree on *that*). Best regards, Julian From nobody Mon Feb 1 12:13:55 2021 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD3B23A1432 for ; Mon, 1 Feb 2021 12:13:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=dIGbyFzX; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=gTtcKeJg 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 ir0YSYpk_MSX for ; Mon, 1 Feb 2021 12:13:51 -0800 (PST) Received: from che.mayfirst.org (unknown [162.247.75.117]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D15A3A1431 for ; Mon, 1 Feb 2021 12:13:51 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1612210429; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=Ta4YJrF6t17kCZK/iKC9N6rmqnb1N0mYmYCWj1FXtpM=; b=dIGbyFzXK+LWdQDAAl3l5T9j3/hx2Z1DMAxbaYVwJfcmuM/j7OxV0PzbMdQRnXl01e69M pj7HgfHZC2fksanDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1612210429; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=Ta4YJrF6t17kCZK/iKC9N6rmqnb1N0mYmYCWj1FXtpM=; b=gTtcKeJgCwBMxBUbKg4DOZqDb2bA6rbVn6clzYrstRVFBNv1jtMn7Vdb2Q6Oxz7ZzqcbZ QkcUbOFWzJt5wYQNeL9M8zNIzM3IjWQA+X3CRF4xU9J1oAU4klpKzMjku1mmfB4YeWZ9SGU rECKNpUG6vsOeg9klvfh3lGM60OaYjIhXHVJhzBUFbyfAY4rn5ayMh++VmhYUuu8f0W78In Etq6lR6MZcmT3MjAoGXd+vwZoaLUTiiSZLUkVaKbKU0CHa09Ud/+24aS1bMhdA6xaMQ5vC0 Uq3+IYbzWry3BQRfaZM0t+u8gdxNjop/GyhMzpq0DxQXS2Ps+sMkMp29IvQw== Received: from fifthhorseman.net (lair.fifthhorseman.net [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id E7CFFF9A5; Mon, 1 Feb 2021 15:13:48 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 5F94C201FA; Mon, 1 Feb 2021 15:13:46 -0500 (EST) From: Daniel Kahn Gillmor To: Julian Reschke , xml2rfc-dev@ietf.org In-Reply-To: <078f11bc-2adf-5126-a9b6-20cf3167d554@gmx.de> References: <8735yje4kt.fsf@fifthhorseman.net> <342339E7-A47C-4C51-8852-7FFBB6A8C750@eggert.org> <87lfcacstt.fsf@fifthhorseman.net> <078f11bc-2adf-5126-a9b6-20cf3167d554@gmx.de> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH Date: Mon, 01 Feb 2021 15:13:45 -0500 Message-ID: <87zh0nbl6u.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [xml2rfc-dev] Unicode box-drawing for a new --table-borders value? X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2021 20:13:54 -0000 --=-=-= Content-Type: text/plain On Mon 2021-02-01 15:52:54 +0100, Julian Reschke wrote: > Right. This is intended mainly for examples that require use of > non-ASCII characters, not for drawing symbols (for which the > recommendation might be "use SVG instead"). Use svg for a table? Or for a linear, structured representation of a MIME tree? SVG won't be rendered at all in the text document, making it actively *less* useful and effective than the non-text variant. Is the goal to have improved legibility and ease of consumption in different formats, including plain text? Or is the goal to drive people away from the plain text format entirely? > It depends on how you read RFC 7997 - and yes, I believe it intends to > describe the *output* of the text generation step, thus a change of that > document would be needed (and believe me, it was really hard to agree on > *that*). It sounds to me like you're saying the existing drafts i've been working on (like [0]) are somehow skirting the IETF consensus on what makes a legitimate document by "abusing" the artwork mechanism. I really hope that's not the case, as the documents would be significantly worse (and probably harder to maintain) if i had to revert to ASCII line art or convert to embedded SVG. I'm grateful that the current publication process doesn't block them, at any rate. --dkg [0] https://datatracker.ietf.org/doc/draft-dkg-lamps-e2e-mail-guidance/ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQttUkcnfDcj0MoY88+nXFzcd5WXAUCYBhg+gAKCRA+nXFzcd5W XN0IAP49gtNulmJQ5hD0/wAj2WrqhOc+pZ+lCjjz1I4IK1kEGQEA4ppDoAC3t9d+ hvezL49hmRVZk1z8l4UYvUM8sXazyws= =QqlF -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Feb 1 12:16:24 2021 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B00D3A143D for ; Mon, 1 Feb 2021 12:16:23 -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 xf8KqD1NoswF for ; Mon, 1 Feb 2021 12:16:20 -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 32C333A143A for ; Mon, 1 Feb 2021 12:16:19 -0800 (PST) Received: from [192.168.217.118] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (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 4DTzjY2GsNzybP; Mon, 1 Feb 2021 21:16:17 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: <87zh0nbl6u.fsf@fifthhorseman.net> Date: Mon, 1 Feb 2021 21:16:16 +0100 Cc: Julian Reschke , xml2rfc-dev@ietf.org X-Mao-Original-Outgoing-Id: 633903376.824671-239023e8fa3d6fa0a4eebfde79efe3a6 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8735yje4kt.fsf@fifthhorseman.net> <342339E7-A47C-4C51-8852-7FFBB6A8C750@eggert.org> <87lfcacstt.fsf@fifthhorseman.net> <078f11bc-2adf-5126-a9b6-20cf3167d554@gmx.de> <87zh0nbl6u.fsf@fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [xml2rfc-dev] Unicode box-drawing for a new --table-borders value? X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2021 20:16:23 -0000 On 2021-02-01, at 21:13, Daniel Kahn Gillmor = wrote: >=20 > I really hope that's not the case, as the documents would be > significantly worse (and probably harder to maintain) if i had to = revert > to ASCII line art or convert to embedded SVG. I'm grateful that the > current publication process doesn't block them, at any rate. I don=E2=80=99t think anybody wants to turn the clock back on = beyond-ASCII in artwork. I do want to see some forward movement of the clock on beyond-ASCII in = non-artwork text. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Feb 1 13:04:09 2021 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B373A1490 for ; Mon, 1 Feb 2021 13:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 F7eZUG5ko0Rf for ; Mon, 1 Feb 2021 13:04:05 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 DBC453A148F for ; Mon, 1 Feb 2021 13:04:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1612213437; bh=kQYZi+ZwGe/ZWBcJ69nrk9wMEnXDldMHjNzaZSjuJ7c=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=JmRr9RKIVsSOOJRtLmwQ16J8FItHahibTtMSoFQ6k6xMiLU11MBk+vZOCjx9L5aX0 myJcyuFMi3pvzdkTcjbMplO4CTr9NJrjeBO2ZB8aPuB1+gQzm3aalayTdQgWdIc4ia 7NR7mI3664iVltgf1tlDYebrA9u6Du+HsB+BsMgA= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.20] ([84.171.151.220]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N5mKP-1m0Y7i1dQR-017Dwm; Mon, 01 Feb 2021 22:03:57 +0100 To: Daniel Kahn Gillmor , xml2rfc-dev@ietf.org References: <8735yje4kt.fsf@fifthhorseman.net> <342339E7-A47C-4C51-8852-7FFBB6A8C750@eggert.org> <87lfcacstt.fsf@fifthhorseman.net> <078f11bc-2adf-5126-a9b6-20cf3167d554@gmx.de> <87zh0nbl6u.fsf@fifthhorseman.net> From: Julian Reschke Message-ID: Date: Mon, 1 Feb 2021 22:03:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <87zh0nbl6u.fsf@fifthhorseman.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:23E662d0AArb5Mj7wgNEL3CCZGxRJqk3m9eHyAtzgpC+MJrtbMB x0DeUKl0V/NFIguco25zNgij4VjQ1MJYgAVngdVfyVk6uUogwuyn7QHk4kLtOff1bLRBEIu Ouj3DK5CLnx6laoVWI/cZrdwcc3sJGfijJeITCeyyf6HOuZg3Nu6iEjR6i0DbJbz/wXm65S 0Z5tlsfNXCFn8hzOM/eXA== X-UI-Out-Filterresults: notjunk:1;V03:K0:MZ524OD+Agc=:se9t9CLVKRBmkVW0SFieqp C0DMqZFElzIoDMJBb/YiMUcBCHIjFCKt2nOVoHB/TRTLgK+HxF/dFbk+facyiQfLJV6awadKR nuD6Z3QHeMR/HgctZmIDZ+UNapHyJQ5lALgaqP9nfGfpZj1DCzrXf03XgNZ4DEGFSynfxl5d7 I5edOBqD6OYXHxe7yQiIzFDzsxVyvFmOvyXD6ZQuFOdkiBXFOMSogYzzRSDKPNCAJqHTzwRfp gipyduAnVMlImpt2q0Uvoo8zb2/C2QX6gNChmLfHapys6nZwRuDCwhGfGs8k4iK4hzWHSzxlO +vC5GRj/3NpBodOGd1BMYRAeUQ1A+uKPSaqZzfZzJTw21dw90xQS7rdJORnswxqnPW6INFPET repV0ApgkV7KG7hPPtvHeloFAjCuG8cTDuhwl0tw3tZLZD1vHC6cNYasHOipxVNrGKKh2SJou /a99Oimg1G9fJrT/zT51GkCJGd6Lqf7n3hCAShCapJvrAWlNBr2UrCNZQmZnx+TDRpsfaa2kc GirnulwRviPjgKC6+cRoTqvuZaYkNJVE6j9Nib3l2aNxaQebP3Mmzn8SyRsJh4H8myW2ahojQ eKLoVj2yXsWPMmT8dpiCRlVh5819tMlQQS+9bZpzr6TtCM3g+7BqC17bCWWm7lgpgngVP/CE7 Mm2ts/Hk1CYO3IqSTgLzAkrrdvJ6Zj/Vj5sENwpkIA6PxPMKGdIuooBUA3dNZO8pr/ZE7E2ot xbkXIwDNBl+452gFJObvfwOwJGNX5rxSnlKJuofUfpkXiFnsfHffPw32BfhsYC9rBW3olk/5y CKedFGvgI3syhdtRZk+pXdCK+H7psWt4e4rNCKq02lPNYehfpGia6ShqCyftGed3JyWyMWTvi ZWEN8uMmGsNzIWQSUkYg== Archived-At: Subject: Re: [xml2rfc-dev] Unicode box-drawing for a new --table-borders value? X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2021 21:04:08 -0000 Am 01.02.2021 um 21:13 schrieb Daniel Kahn Gillmor: > On Mon 2021-02-01 15:52:54 +0100, Julian Reschke wrote: >> Right. This is intended mainly for examples that require use of >> non-ASCII characters, not for drawing symbols (for which the >> recommendation might be "use SVG instead"). > > Use svg for a table? Or for a linear, structured representation of a For a table, a table should be used. Not SVG, not artwork. > MIME tree? SVG won't be rendered at all in the text document, making it > actively *less* useful and effective than the non-text variant. > > Is the goal to have improved legibility and ease of consumption in > different formats, including plain text? Or is the goal to drive people > away from the plain text format entirely? IHMO, if the plain text is in the way of progress, then yes, we should drive people away from it. >> It depends on how you read RFC 7997 - and yes, I believe it intends to >> describe the *output* of the text generation step, thus a change of tha= t >> document would be needed (and believe me, it was really hard to agree o= n >> *that*). > > It sounds to me like you're saying the existing drafts i've been working > on (like [0]) are somehow skirting the IETF consensus on what makes a > legitimate document by "abusing" the artwork mechanism. IMHO: non-ASCII characters in artwork were allowed to express examples where non-ASCII characters are *required*. This does not seem to be the case here. See the rules in . (These are not my rules, and I might not even support them, but these are the rules currently). > I really hope that's not the case, as the documents would be > significantly worse (and probably harder to maintain) if i had to revert > to ASCII line art or convert to embedded SVG. I'm grateful that the > current publication process doesn't block them, at any rate. It might be blocked during AUTH48. Or not. Best regards, Julian From nobody Mon Feb 1 13:18:38 2021 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65FE83A14B5 for ; Mon, 1 Feb 2021 13:18:37 -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 paWu3dFDnTcB for ; Mon, 1 Feb 2021 13:18:33 -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 7B57F3A14B4 for ; Mon, 1 Feb 2021 13:18:32 -0800 (PST) Received: from [192.168.217.118] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (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 4DV15L3D46zyWc; Mon, 1 Feb 2021 22:18:30 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: Date: Mon, 1 Feb 2021 22:18:30 +0100 Cc: Daniel Kahn Gillmor , xml2rfc-dev@ietf.org X-Mao-Original-Outgoing-Id: 633907109.971806-b704a5796117ffb9c720ab00128ef33c Content-Transfer-Encoding: quoted-printable Message-Id: References: <8735yje4kt.fsf@fifthhorseman.net> <342339E7-A47C-4C51-8852-7FFBB6A8C750@eggert.org> <87lfcacstt.fsf@fifthhorseman.net> <078f11bc-2adf-5126-a9b6-20cf3167d554@gmx.de> <87zh0nbl6u.fsf@fifthhorseman.net> To: Julian Reschke X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [xml2rfc-dev] Unicode box-drawing for a new --table-borders value? X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2021 21:18:37 -0000 On 2021-02-01, at 22:03, Julian Reschke wrote: >=20 >> It sounds to me like you're saying the existing drafts i've been = working >> on (like [0]) are somehow skirting the IETF consensus on what makes a >> legitimate document by "abusing" the artwork mechanism. >=20 > IMHO: non-ASCII characters in artwork were allowed to express examples > where non-ASCII characters are *required*. This does not seem to be = the > case here. See the rules in > = . >=20 > (These are not my rules, and I might not even support them, but these > are the rules currently). One of the qualifications for a German professor is that you need to be = able to make up a valid argument for anything, in particular when = talking to university administration (which is trained in making up = arguments *against* anything). In this case, of course, RFC 7997 does support this usage as it makes an = allowance for the rules of a programming language [1]. The author = clearly has defined a new (visual) programming language here and uses = that in his artwork. Gr=C3=BC=C3=9Fe, Carsten [1]: 3.6 code components: https://tools.ietf.org/html/rfc7997#section-3.6 From nobody Thu Feb 18 13:40:32 2021 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC9333A18BB for ; Thu, 18 Feb 2021 13:40:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=x6LJyiAg; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=h0jm68DM 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 ovspQQTwZq0F for ; Thu, 18 Feb 2021 13:40:29 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9CEE3A18B8 for ; Thu, 18 Feb 2021 13:40:29 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1613684428; h=from : to : subject : date : message-id : mime-version : content-type : from; bh=aQKhucWxUsPYxScm2HRyLsuNQhoFCi33OqNJ4tfLScU=; b=x6LJyiAgZ4S1omZI3m8H4lgHHmov1enjkm8IUB+enE+H2HvUEfoMxut/Fw2/k82eZ50l1 b+NCJ3IlkqTwoqmCg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1613684428; h=from : to : subject : date : message-id : mime-version : content-type : from; bh=aQKhucWxUsPYxScm2HRyLsuNQhoFCi33OqNJ4tfLScU=; b=h0jm68DMt+PB6nokVD1gtlSaIVYIo0xydnPqrmohSYfYn/IFWcBVIm/GHNk+K3ljNSSzr +aqkn6TFcSXjT4X3Cb1aitWLo7x88J3O9cd+mD83VJ7m3dqj3FS6Q43idVxb8cn80M5hxz/ RwmV3ty8N6t5//0bzj4klQly246YvCutkAWFia50P7+eUA/l6Q8j622L+t6/sfb7sZDBVQ0 Lp05kaPpjwDJlLYrH53/HoJQFIGh27dKKbCMwH1a0czilhFz3dwBOkpbLVMP51SzsRzP52X 94Rrq/yJg4WkD4BFQxqeqFei4Ol8Je1RqWwewN2HhTjaumZgBTr9pY44jYgA== Received: from fifthhorseman.net (lair.fifthhorseman.net [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 90BA9F9A6 for ; Thu, 18 Feb 2021 16:40:28 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 83894204BF; Thu, 18 Feb 2021 16:40:10 -0500 (EST) From: Daniel Kahn Gillmor To: xml2rfc-dev@ietf.org Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH Date: Thu, 18 Feb 2021 16:40:09 -0500 Message-ID: <87y2flrr5y.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: [xml2rfc-dev] cryptographic signatures over xml2rfc releases should not be made with SHA1 X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2021 21:40:32 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi folks-- I'm looking at the latest xml2rfc tarball and its OpenPGP signature: https://files.pythonhosted.org/packages/c0/81/21281e78fd2afb8f5dfcb92b78c9d= cd621081277304e0f25df0ee7c89c64/xml2rfc-3.5.0.tar.gz https://files.pythonhosted.org/packages/c0/81/21281e78fd2afb8f5dfcb92b78c9d= cd621081277304e0f25df0ee7c89c64/xml2rfc-3.5.0.tar.gz.asc The signature file (the *.asc) is made using SHA-1 for the signature: $ pgpdump < xml2rfc-3.5.0.tar.gz.asc=20 Old: Signature Packet(tag 2)(540 bytes) Ver 4 - new Sig type - Signature of a binary document(0x00). Pub alg - RSA Encrypt or Sign(pub 1) Hash alg - SHA1(hash 2) Hashed Sub: signature creation time(sub 2)(4 bytes) Time - Wed Nov 18 05:20:56 EST 2020 Sub: issuer key ID(sub 16)(8 bytes) Key ID - 0x4E9B574B8FBB171A Hash left 2 bytes - d2 9f=20 RSA m^d mod n(4094 bits) - ... -> PKCS-1 $ Signatures using SHA-1 have been deprecated for over a decade now. No modern tool should generate them. From=20the Version: comment in the .asc file, it looks to me like these signatures are being generated from the old, deprecated "classic" version of GnuPG ("Version: GnuPG v1"). Henrik (or whoever else might make a future release of xml2rfc), is there something blocking you from updating to a more modern OpenPGP implementation for making these signatures? The GnuPG 2.2.x series ("modern") should make signatures with sha256 (or better) by default, as should pretty much any other OpenPGP implementation (sequoia, openpgp.js, gopenpgp, rnp, pgpainless, etc). There's probably also a way to coax better-than-SHA-1 signatures out of GnuPG 1.x as well, but that toolkit is unable to deal with modern tooling like ECC keys so i recommend upgrading anyway. The irony here is that i'm trying to work on the RFC for OpenPGP itself to refresh the cryptographic requirements in that standard, and i'm working with modern tooling that deprecates SHA-1 signatures appropriately; and to update the xml2rfc package i want to check the OpenPGP signature, etc. a nice little loop! I figure it's probably neither possible nor advisable to re-issue a signature over xml2rfc version 3.5.0, but if you can line it up so that signatures of future releases avoid using SHA1, that'd be great. --dkg PS The files i've fetched from the above URLs have this content (just in case anyone wants to replicate, they can confirm that they're getting the same thing): $ sha256sum * 3ec836a9545f549707a8c8176038160185b9d08c1dd80304a906527da21bff68 xml2rfc-3= .5.0.tar.gz ef652fda6c1f7b63f22765e7df48d627ce529155f1bcb45a01e566687b4fd4eb xml2rfc-3= .5.0.tar.gz.asc $ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQttUkcnfDcj0MoY88+nXFzcd5WXAUCYC7eugAKCRA+nXFzcd5W XCXuAP90AXTxsci6CfFU1oH6I9qahGqkMcmSxUrcVgNkHQqNvAD/WpZmb0BOzw1v rCPe2l2RIESBKMlOW5BNqVLAuYfB6gM= =Cw5v -----END PGP SIGNATURE----- --=-=-=--