Re: [xml2rfc-dev] xml2rfc would not be able to render RFC 7997
Tom Pusateri <pusateri@bangj.com> Tue, 15 October 2019 18:51 UTC
Return-Path: <pusateri@bangj.com>
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 3F12312080B for <xml2rfc-dev@ietfa.amsl.com>; Tue, 15 Oct 2019 11:51:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bangj.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXDuJ7Uu3odg for <xml2rfc-dev@ietfa.amsl.com>; Tue, 15 Oct 2019 11:51:15 -0700 (PDT)
Received: from oj.bangj.com (69-77-154-174.static.skybest.com [69.77.154.174]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA9CD12080A for <xml2rfc-dev@ietf.org>; Tue, 15 Oct 2019 11:51:15 -0700 (PDT)
Received: from [172.16.25.104] (69-77-155-155.static.skybest.com [69.77.155.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 9F5EC2B8C7; Tue, 15 Oct 2019 14:51:14 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bangj.com; s=201907; t=1571165474; bh=LaE8pBoJ44JpiCDMM6met/Zdvro9y0neasQr5ihtSyA=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=EGAgFRVNneBh4cJkHHGbt1WN78JMHrgpa1s+fCrA2rB5mIAfTy6urWrhpt3C9Afoi xo1AdjLhW5t+OKB0WmblWzaVCRd0I6P3CMm9sIR4x2AuYAla0yAnhYkz/daXGEHohn DO6A9OoQ5m+ql0ch7w/0r6vhZZryOBEUFNveSOzisH6QraCMLIm9XLjeGPFkJXB3Ud Z4vMAN/QypizdH1e8E9SSkEbP1xvB3M0SJjVJmQ0IQFT9zrtkY7yEydu4J3G/e/tHp BIMrWEyj4MtKy53fD1xiN8jINv4KZcIBAEhVnZeNTgwsHJl7xMCNC96N2HpGpb68zT h68YHECCIQ7Jg==
From: Tom Pusateri <pusateri@bangj.com>
Message-Id: <ED2DB58A-AAAB-4A5D-964C-5FC597C96248@bangj.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3480A2B7-90F4-49F6-9107-9C7A5BDBEFE3"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\))
Date: Tue, 15 Oct 2019 14:51:14 -0400
In-Reply-To: <702D203A-2900-4290-8377-182F4AE2C359@rfc-editor.org>
Cc: Julian Reschke <julian.reschke@gmx.de>, XML Developer List <xml2rfc-dev@ietf.org>
To: Heather Flanagan <rse@rfc-editor.org>
References: <06116eaa-4dbb-1f35-6a76-d770e5775c12@gmx.de> <702D203A-2900-4290-8377-182F4AE2C359@rfc-editor.org>
X-Mailer: Apple Mail (2.3594.4.19)
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/Fm4RZZhyxYT2gFaPefVp-jyCe6Q>
Subject: Re: [xml2rfc-dev] xml2rfc would not be able to render RFC 7997
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." <xml2rfc-dev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/>
List-Post: <mailto:xml2rfc-dev@ietf.org>
List-Help: <mailto:xml2rfc-dev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Oct 2019 18:51:19 -0000
If you’re to change the use of non-ascii characters in RFCs, there’s been many requests for unicode math symbols in paragraph text. I feel like someone is going to shoot me for saying this but really, it’s 2019. We should be able to do ≤ instead of <= Tom > On Oct 15, 2019, at 2:35 PM, Heather Flanagan <rse@rfc-editor.org> wrote: > > > >> On Oct 14, 2019, at 11:58 PM, Julian Reschke <julian.reschke@gmx.de> wrote: >> >> So, >> >> RFC 7997 is "The Use of Non-ASCII Characters in RFCs". In >> <https://www.greenbytes.de/tech/webdav/rfc7997.html#rfc.section.3.2> it >> says: >> >>> Example Acknowledgements section: >>> >>> OLD: >>> >>> The following people contributed significant text to early versions of this draft: Patrik Faltstrom, William Chan, and Fred Baker. >>> >>> PROPOSED/NEW: >>> >>> The following people contributed significant text to early versions of this draft: Patrik Fältström (Faltstrom), 陈智昌 (William Chan), and Fred Baker. >> >> However, >> <https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-notes-09#appendix-A.1> >> states: >> >>> A.1. <u> >>> >>> In xml2rfc vocabulary version 3, the elements <author>, >>> <organisation>, <street>, <city>, <region>, <code>, <country>, >>> <postalLine>, <email>, <seriesInfo>, and <title> may contain non- >>> ascii characters for the purpose of rendering author names, >>> addresses, and reference titles correctly. They also have an >>> additional "ascii" attribute for the purpose of proper rendering in >>> ascii-only media. >>> >>> In order to insert Unicode characters in any other context, xml2rfc >>> vocabulary v3 requires that the Unicode string be enclosed within an >>> <u> element. The element will be expanded inline based on the value >>> of a "format" attribute. This provides a generalised means of >>> generating the 6 methods of Unicode renderings listed in [RFC7997], >>> Section 3.4, and also several others found in for instance the RFC >>> Format Tools example rendering of RFC 7700, at https://rfc- >>> format.github.io/draft-iab-rfc-css-bis/sample2-v2.html. >>> >>> The "format" attribute accepts either a simplified format >>> specification, or a full format string with placeholders for the >>> various possible Unicode expansions. >>> >>> A.1.1. Expansion of simplified <u> format specifications >>> >>> The simplified format consists of dash-separated keywords, where each >>> keyword represents a possible expansion of the Unicode character or >>> string; use for example "<u "lit-num-name">foo</u>" to expand the >>> text to its literal value, code point values, and code point names. >>> >>> A combination of up to 3 of the following keywords may be used, >>> separated by dashes: "num", "lit", "name", "ascii", "char". The >>> keywords are expanded as follows and combined, with the second and >>> third enclosed in parentheses (if present): >>> >>> "num" The numeric value(s) of the element text, in U+1234 >>> notation >>> >>> "name" The Unicode name(s) of the element text >>> >>> "lit" The literal element text, enclosed in quotes >>> >>> "char" The literal element text, without quotes >>> >>> "ascii" The value of the 'ascii' attribute on the <u> element >>> >>> In order to ensure that no specification mistakes can result for >>> rendering methods that cannot render all Unicode code points, "num" >>> MUST always be part of the specified format. >>> >>> The default value of the "format" attribute is "lit-name-num". >> >> So, unless I'm missing something, the only way to get non-ASCII >> characters into regular prose is using <u>, and using <u> implies >> automatic expansion of characters to numerical representations of the >> codepoints. >> >> Possible solutions: >> >> 1) In RFC 7997bis, remove the suggestion to allow non-ASCII names in >> Acknowledgements etc. >> >> 2) Relax the requirements for <u> so that it doesn't *need* to be used >> in prose. >> >> 3) Relax the requirement about output formats for <u>. >> >> My preference would be 2) or 3). > > I agree that 1) is not ideal - won’t go that route. > > I like 3) over 2) because the point of <u> is to help be clear in text that might be semantically important for the spec about what characters are being used. If we just say “any prose”, I feel like that might open us up to the confusion we’re trying to avoid. Does that make sense? > > I haven’t added <u> to the 7991bis doc. I’m currently looking at reverting <seriesInfo> as per https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/7 <https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/7>, so I’m not far away from <u>. > > -Heather > >> >> Best regards, Julian >> >> PS: tracked for now at >> <https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/416 <https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/416>> >> >> _______________________________________________ >> xml2rfc-dev mailing list >> xml2rfc-dev@ietf.org <mailto:xml2rfc-dev@ietf.org> >> https://www.ietf.org/mailman/listinfo/xml2rfc-dev <https://www.ietf.org/mailman/listinfo/xml2rfc-dev> > > _______________________________________________ > xml2rfc-dev mailing list > xml2rfc-dev@ietf.org <mailto:xml2rfc-dev@ietf.org> > https://www.ietf.org/mailman/listinfo/xml2rfc-dev <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>
- [xml2rfc-dev] xml2rfc would not be able to render… Julian Reschke
- Re: [xml2rfc-dev] xml2rfc would not be able to re… Heather Flanagan
- Re: [xml2rfc-dev] xml2rfc would not be able to re… Tom Pusateri
- Re: [xml2rfc-dev] xml2rfc would not be able to re… Heather Flanagan
- Re: [xml2rfc-dev] xml2rfc would not be able to re… Henrik Levkowetz
- Re: [xml2rfc-dev] xml2rfc would not be able to re… Tom Pusateri
- Re: [xml2rfc-dev] xml2rfc would not be able to re… Henrik Levkowetz
- Re: [xml2rfc-dev] xml2rfc would not be able to re… Andrew G. Malis
- Re: [xml2rfc-dev] xml2rfc would not be able to re… Tom Pusateri
- Re: [xml2rfc-dev] xml2rfc would not be able to re… Heather Flanagan
- Re: [xml2rfc-dev] xml2rfc would not be able to re… Henrik Levkowetz
- Re: [xml2rfc-dev] xml2rfc would not be able to re… Tom Pusateri
- Re: [xml2rfc-dev] xml2rfc would not be able to re… Julian Reschke
- Re: [xml2rfc-dev] xml2rfc would not be able to re… Julian Reschke
- Re: [xml2rfc-dev] xml2rfc would not be able to re… Carsten Bormann
- Re: [xml2rfc-dev] xml2rfc would not be able to re… Heather Flanagan
- Re: [xml2rfc-dev] xml2rfc would not be able to re… Carsten Bormann
- Re: [xml2rfc-dev] xml2rfc would not be able to re… Daniel Kahn Gillmor
- Re: [xml2rfc-dev] [Ext] Re: xml2rfc would not be … Paul Hoffman
- Re: [xml2rfc-dev] [Ext] Re: xml2rfc would not be … Carsten Bormann
- Re: [xml2rfc-dev] xml2rfc would not be able to re… Tom Pusateri
- Re: [xml2rfc-dev] xml2rfc would not be able to re… Carsten Bormann
- Re: [xml2rfc-dev] [Ext] Re: xml2rfc would not be … Daniel Kahn Gillmor
- Re: [xml2rfc-dev] [Ext] Re: xml2rfc would not be … Carsten Bormann
- Re: [xml2rfc-dev] xml2rfc would not be able to re… Julian Reschke
- Re: [xml2rfc-dev] xml2rfc would not be able to re… Daniel Kahn Gillmor
- Re: [xml2rfc-dev] xml2rfc would not be able to re… Henrik Levkowetz
- Re: [xml2rfc-dev] xml2rfc would not be able to re… Daniel Kahn Gillmor