[rfc-i] RFC Series publishes first RFC with non-ASCII characters

Julian Reschke julian.reschke at gmx.de
Fri Sep 22 10:14:14 PDT 2017

On 2017-09-22 18:54, Heather Flanagan (RFC Series Editor) wrote:
> On 9/22/17 5:51 AM, Julian Reschke wrote:
>> On 2017-09-14 23:07, Heather Flanagan (RFC Series Editor) wrote:
>>> ...
>>> The RPC and the Tools Team has identified several areas that need to be
>>> modified to support these characters. Some of those areas will
>>> ultimately be handled with the new format tools; others have been
>>> modified as part of the more general work to prepare for the new RFC
>>> format. For the documents being used to test the toolchain, a
>>> significant amount of manual processing is required to publish the
>>> RFCs with non-ASCII characters in the final text. In order to keep
>>> ...
>> Out of curiosity: as the current version of xml2rfc produces the UTF-8
>> plain text just fine (*), what additional processing are you referring
>> to?
> There are the manual checks to determine if everything renders exactly
> as expected. There are a number of discussions as we learn how to deal


> with half- and full-width characters in the same document, and try to
> determine the best path forward to make such characters in tables to
> line up properly. There are even more discussions as we learn more about

Seriously: don't bother.

> invisible space characters outside of the ASCII realm and try to
> understand if those are something we need to write scripts to identify.

If this is understood to be a problem, let's have a script that checks 
for these characters.

> xml2rfc is just one component of getting these documents published.

 > ...
>> Understood.
>> Now what does this mean for drafts being written right now, and which
>> are not expected to be ready for publication in the next, let's say,
>> 12 months? Can we start submitting I-Ds with non-ASCII characters
>> right now (without getting stopped by id-nits...)?
> That's an excellent question. I think this is something to discuss with
> both the IESG and the Tools Team, though I am fairly confident that
> "right now" isn't possible. An idnits update is one of the tools
> contracted for, and is not yet complete (see the expected timeline here:
> https://trac.tools.ietf.org/tools/ietfdb/wiki/FormatToolsPlan). Also,

Well, idnits s just advisory. All it can block is automatic submission. 
(I wish it did not).

> we've seen that the datatracker isn't rendering non-ASCII characters
> correctly in the PDF automatically generated from RFC 8187
> (https://trac.tools.ietf.org/tools/ietfdb/ticket/2370). So, there is
> still some work to do before this will all work.

Looking at the PDF linked from the datatracker 
(<https://www.rfc-editor.org/rfc/pdfrfc/rfc8187.txt.pdf>), I don't see a 

That said: I don't think that a minor bug in a conversion tool for a 
supplemental output format is sufficient reason to block progress...

Best regards, Julian

More information about the rfc-interest mailing list