Re: [xml2rfc-dev] xml2rfc would not be able to render RFC 7997
Tom Pusateri <pusateri@bangj.com> Tue, 15 October 2019 19:11 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 B563C120832 for <xml2rfc-dev@ietfa.amsl.com>; Tue, 15 Oct 2019 12:11:31 -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 1B5xpYVzQGiC for <xml2rfc-dev@ietfa.amsl.com>; Tue, 15 Oct 2019 12:11:27 -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 E8ABD120816 for <xml2rfc-dev@ietf.org>; Tue, 15 Oct 2019 12:11:26 -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 F26C82B8D4; Tue, 15 Oct 2019 15:11:25 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bangj.com; s=201907; t=1571166686; bh=ZqkS68Z/JBzsmDeXpsqjCbwPxNp2Wql7id1BcRwO/g8=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=INlIrEjkTqRL/2WRA86Bc9Huyc0R2vJbaGhwEaiIKZRnnFTSkJCGy/WfG6uFeTm3Z QcJbJiHNIbBqd+iI/Cglh2q0gNs5Q/ThM2lH+0skR/NMc4qAaiW8vkkwDMdJAiIuy6 PP6SQ5rgWr9g49kHjRmwbB692phZI/8LHOoDVP8SXoqiY850NGj+ngC3SieYun35Qx U21pVHJa69JlFynABUL6MccWaABtUXPJvlKmBOnbUNMQOV2llaeGnXoRaX6Eo1dvnD SnPS6IsM503fB0+42aSovmIVgRTr8tgoE8XPDhXTA4Yv5+N4j6odU6Z/TwaXa38Zij q41Sn2jKiHn6Q==
From: Tom Pusateri <pusateri@bangj.com>
Message-Id: <87FC795A-DC55-405B-AFC8-81285F5D605D@bangj.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_67D435CC-042C-466C-86EA-E94DF7A53FF0"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\))
Date: Tue, 15 Oct 2019 15:11:25 -0400
In-Reply-To: <9DDF1A2E-0287-4F73-9794-CB567EF4D5A6@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> <ED2DB58A-AAAB-4A5D-964C-5FC597C96248@bangj.com> <9DDF1A2E-0287-4F73-9794-CB567EF4D5A6@rfc-editor.org>
X-Mailer: Apple Mail (2.3594.4.19)
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/H-4IMrAdQWt4cjq7iRdN-e-W0e4>
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 19:11:32 -0000
I don’t think math needs separate handling. It is just an example of why you would want non-ASCII characters in paragraph text. But as I was recently told during IESG review, it’s currently not allowed and that is unfortunate when all the work is being done to allow non-ASCII characters in other parts of the document. Thanks, Tom > On Oct 15, 2019, at 2:57 PM, Heather Flanagan <rse@rfc-editor.org> wrote: > > Hi Tom, > >> On Oct 15, 2019, at 11:51 AM, Tom Pusateri <pusateri@bangj.com <mailto:pusateri@bangj.com>> wrote: >> >> 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 <= > > Sure. I don’t mention math symbols explicitly in 7997; do you think they need separate handling from other non-ASCII characters? Or does 7997 need a special section just on Math? > > -Heather > >> >> Tom >> >>> On Oct 15, 2019, at 2:35 PM, Heather Flanagan <rse@rfc-editor.org <mailto:rse@rfc-editor.org>> wrote: >>> >>> >>> >>>> On Oct 14, 2019, at 11:58 PM, Julian Reschke <julian.reschke@gmx.de <mailto: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 <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 <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- <https://rfc-/> >>>>> format.github.io/draft-iab-rfc-css-bis/sample2-v2.html <http://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